How We Build and Maintain AI Agents

Building an agent, the Local Service Spotlight way, means documenting a task to a standard so complete that a human or an AI can run it identically — same trigger, same steps, same definition of done. We build agents now because models finally persist: they loop until the work passes QA, hold memory across runs, and improve themselves, so every task you document stops being a wiki page and becomes a worker.

If an agent must carry state between models, first set up cross-agent shared memory in an Obsidian/Markdown vault you own.

That definition is the whole page in two sentences. What follows is how we build agents, how we equip them, and — the part almost everyone skips — how we keep them current as Claude, Gemini, and OpenAI’s models leap forward every few months. This page is the philosophy and the system. The named production roles live in the AI agent roster; the wider skill and job inventory lives on the Task Library Dashboard.

What an agent actually is here

Not a dashboard demo. Not a chatbot wrapper. At Local Service Spotlight, an agent is a task documented to the definitive article standard with a companion skill.md — a machine-readable SOP that carries:

• Frontmatter — permanent name, category, Content Factory stage, the definitive article it implements, and an honest status.
• “Use this when” — the trigger, in one line.
• Inputs — everything needed before starting. No hidden prerequisites.
• Steps — the real process, imperative and concrete.
• Definition of done — an objective QA checklist, not “make it good.”
• Example and links — at least one documented real run, plus links up to its hub article and across to sibling skills.

Hand that file to a new team member or AI agent and both can run the same method. The current human request plus safety and permission boundaries outrank stored context. The canonical skill governs the method unless the current request explicitly changes it; conflicts are surfaced, not silently resolved. One documented task is a skill. A library of skills is a toolkit. It becomes a workforce only when named agents run those skills with the right context, tools, access, schedules, and execution receipts. Ours runs the Content Factory — Produce, Process, Post, Promote — the engine that turns one real recording into articles, clips, and ads.

The proof: a live task inventory you can browse and download

We did not write the philosophy first and hope. We documented the operation as atomic task records across the full delivery line, from digital plumbing to Dollar a Day to website QA. The live dashboard reports the current inventory and status buckets. Those numbers change, so evergreen prose should not duplicate them. An honest scoreboard is what makes a library improvable, and every unsupported completion label is a work order, not an embarrassment.

All of it is live on the Task Library Dashboard: search the SOP text, read a skill, or download a dated snapshot. The dashboard is the current inventory. This page is the how and why. The historical build story remains at How We Turned 239 Tasks Into an AI-Runnable Skill Library; its number is a dated event, not the current registry count.

How we build an agent: the loop

Every agent in the library comes from the same five-beat loop:

1. Do. Run the task for real. You can’t document what you haven’t done — steps written from imagination produce agents that fail in production.
2. Document. Write the skill.md to the standard above. The steps mirror what you actually did, not what you aspire to do.
3. QA. Grade the file against its own Definition of done, line by line. If reasonable people could argue about whether the task is finished, the checklist isn’t done.
4. Example. Write the private run receipt. If the run is approved, public-safe, and genuinely useful, publish a meta-article linked to the skill and its hub.
5. Improve. Feed what the run taught you back into the skill, following the update protocol in Knowledge System Maintenance. The next run starts from a better document.

Then it repeats — and here is the compounding part: agents now run the loop on themselves. Each run documents itself, QAs itself, and proposes its own improvements. We call this recursive self-improvement, and it is why the library gets sharper every week instead of staler.

Done right, documentation isn’t a record of the work. It is the work — and it does the next round on its own.

How we keep agents current

This is the section that separates a living system from a folder of dead SOPs. The models running these skills improve every few months, and every improvement changes what “done” can mean. So we continuously update our skill files and agents to take advantage of the newest capabilities — Claude (including Fable 5’s persistence, looping, and memory), Google Gemini, OpenAI’s models, and whatever ships next. When a frontier capability lands, we don’t admire it. We re-equip the library.

That last row has a name. Garry Tan’s essay “Boil the Ocean” calls the turn: “don’t boil the ocean” was good advice when implementation was expensive, and it is obsolete now that AI compresses implementation 10–100x. Our version of the rule: with AI, the marginal cost of completeness is near zero — so do the whole thing, do it right, and ship the finished product, not a plan. We installed that as a literal operating layer in the library — a principles file every agent reads before running any skill, governing how all of them execute.

And because “we keep agents current” is a claim anyone can make, we date everything. Every substantive organization run leaves a private receipt; selected runs also leave public meta-articles. The source commit, distribution manifest, activation canary, and changelog form the proof of currency.

One operating system, three model runtimes

We are not building a different marketing brain for every AI company. We keep the reusable business logic in one versioned library of SKILL.md folders, then add a thin runtime wrapper for Claude, ChatGPT and Codex, or Grok. The procedure, examples, templates, and QA standard should remain the same. Packaging, permissions, connectors, agent files, schedules, and update mechanics are allowed to differ.

That distinction matters. A skill is the documented method. A plugin distributes one or more skills and may add tools. An agent is the worker that combines a role, model, skill, context, tools, permissions, and definition of done. A scheduled job decides when that worker runs. A receipt proves what actually happened.

What remains independent of the model?

Owned layer	What it contains	What still varies by runtime
Knowledge and context	Verified facts, relationships, goals, decisions, evidence, and working state kept in user-owned, governed files rather than trapped in one vendor’s chat history.	Each runtime has its own context window, memory features, file access, and retrieval behavior.
Skills and standards	The versioned SKILL.md procedures, references, examples, and definitions of done that specify how work should be performed.	Claude, ChatGPT/Codex, and Grok package, discover, invoke, and update those same methods differently.
Governance and write-back	The owner, approval gates, evidence states, receipts, and reviewed path by which a lesson from a real run becomes a canonical source change.	Credentials, permission controls, scheduler features, and execution logs remain specific to the runtime; the governance contract does not.

What is true on August 14, 2026:

Claude has the same 27 released skill names: the installed BlitzMetrics Everything bundle is still at commit 33d1f0e. GitHub main is now commit b42362b, so Claude is one shared-skill text revision behind until its marketplace sync and fresh activation receipt pass.

The local Codex canary has the same 27 skill names: there are zero renames and zero missing shared skills. It also contains one additional dataforseo-toolkit skill, but that extension and the latest text updates have not completed the public release path. It is staging, not 28/28 parity. This Codex receipt does not prove that the pack is installed in ordinary ChatGPT web or Work.

Grok Build is current at merged main: BlitzMetrics Everything v1.1.1 has all 27 released skills installed and enabled at commit b42362b through the native Grok manifest. A fresh, bounded, read-only canary activated boil-the-ocean and recovered the newly released silent-media rule. That receipt proves this installation and activation; it does not prove write access, scheduling, tool parity, or successful activation of every skill.

Inspect the file-level verification fingerprints

We sorted the 27 shared skill slugs, hashed every corresponding SKILL.md, then hashed that manifest. Canonical GitHub and the installed Grok bundle both produced a931ac5db555d44f5a3b40981aa1899efc8c75da0d2196b563ea376221550d90. The installed Claude bundle produced b30014cfa687cb2230408cd31e7b13c11f82b7265e762428707ae1050b2fbf72, and the installed Codex copy produced 169ccf4da7afc7aedd2db8671412876cb45147e254e51e7bfabffd384558af78. The names still align 27-for-27; the fingerprints make the remaining text propagation gaps visible. The canonical marketplace validator also passed all 27 skills and references.

How exact is the Claude-to-ChatGPT/Codex mapping?

At the skill-name and function layer, it is exact: 27 of 27 released skills map one-to-one. The four focused Claude bundles are simply different selections from the same source folders; the Everything bundle selects the full set. ChatGPT and Codex can use those same task-focused skill folders. OpenAI now defines a skill as instructions plus supporting resources and says both ChatGPT and Codex can select it automatically or invoke it explicitly—@ in ChatGPT and $ in Codex. See the official OpenAI Skills and Plugins documentation.

Functional bundle	Exact shared skills	Claude	Codex package mapping	Grok on this machine
Authority and reputation 7 skills	business-brand-strategist, positive-mentions-harvester, reputation-gap-analyzer, knowledge-panel-entity-seo, ai-search-visibility, grokipedia-authority, geo-visibility-audit	7/7 current	7/7 exact names	7/7 installed + enabled; not tested skill by skill
Content engine 6 skills	content-factory, definitive-article-writer, content-agent, video-repurposing-agent, dollar-a-day-strategist, business-website-agent	6/6 current	6/6 exact names	6/6 installed + enabled; not tested skill by skill
Client operations 8 skills	client-relationship-cadence, client-access-checklist, weekly-brand-maa, measurement-analytics, sales-every-day, seo-audit, security-audit, software-subscription-audit	8/8 current	8/8 exact names	8/8 installed + enabled; not tested skill by skill
Quality and standards 6 skills	evidence-verification, recursive-self-improvement-qa, model-judgment, boil-the-ocean, skill-registry, nine-triangles	6/6 names; boil-the-ocean one revision behind	6/6 exact names	6/6 installed + enabled; boil-the-ocean canary passed

Why the Task Library and curated marketplace have different counts

These are different inventories. The Task Library is the broad catalog of documented tasks and SOPs. BlitzMetrics Everything is the smaller curated operating pack we currently distribute through the marketplace. One is the full bookshelf; the other is the set of tools we have packaged for day-to-day agent work. We should not add the two counts or describe them as the same product.

What changes when the same skill crosses platforms?

Layer	Claude	ChatGPT and Codex	Grok
Distribution	.claude-plugin/marketplace.json selects Everything or a focused bundle.	.codex-plugin/plugin.json packages skills and optional MCP tools for ChatGPT/Codex.	The native .grok-plugin/plugin.json supplies the stable name and version while pointing at the same ./skills/ source. Grok Build also discovers standard skill folders and reads Claude Code-compatible packages.
Activation	Claude can choose a matching skill; installed plugin skills are available within the surfaces that support them.	ChatGPT can auto-select or use an @ mention; Codex can auto-select or use a $ mention.	Grok Build exposes user-invocable skills as slash commands. One read-only canary passed; the other 26 skills remain untested individually.
Agents	Cowork and Claude Code support subagents, but ordinary Claude chat does not execute plugin subagents or hooks.	ChatGPT Work and Codex can fan independent work out to subagents; local Codex can define specialized agents.	Grok Build supports custom subagents and background workflows. Its Claude compatibility does not make every Claude agent definition semantically identical.
Tools and access	Connectors, MCP, hooks, and permissions belong to the Claude environment.	Connectors, MCP, supported hooks, and permissions belong to the OpenAI environment.	Connectors, MCP, hooks, and permissions belong to Grok. Credentials never become portable merely because the prose skill is.
Scheduling	Cowork can run recurring tasks with its available skills, plugins, and tools.	ChatGPT Scheduled tasks can use skills, plugins, files, and connected tools; local-file access depends on where the task runs.	Grok Bot owns routines (schedule or event, up to 50 per Bot, laptop closed). That is the same rung as Cowork scheduled tasks and Cursor Automations. Grok Build still has recurring /loop prompts that expire after seven days — do not use those as the production host. Official: skills and routines. Map: skill is how, routine is when.
Updates	Marketplace sync, versioning, enablement, and a fresh runtime test still matter.	The installed plugin cache must receive the new build; a GitHub merge alone is not an activation receipt.	BlitzMetrics Everything v1.1.1 is pinned to b42362b. Future releases still require an update receipt and a fresh activation canary.

The official documentation supports this separation. Anthropic documents Claude Code skills, subagents, and Cowork scheduled tasks. OpenAI documents that the same skill format works in ChatGPT and Codex, while agents and Scheduled tasks remain runtime features. xAI documents Grok Bot skills and routines (schedule or event; Test run is real work) and still documents that Grok Build reads Claude Code and AGENTS.md ecosystems plus its own background and recurring tasks. Use Grok Bot routines for production jobs. Do not treat Build /loop as the host. Glossary: skill is how, routine is when.

Where the context comes from

The model is not the source of truth. The source starts with real work: client access, interviews, public evidence, performance data, completed jobs, approved examples, and the judgment of people who have done the thing. We document that work as an SOP, turn the repeatable portion into a skill, and keep the supporting references beside it. A short runtime adapter points the model to the right skill and the right shared context.

Personal and project context should live in user-owned Markdown files or another governed source the authorized agent can read. The context migration guide explains how to move a reviewed working brief between models. Dennis’s How I Work page is a simple public example: Claude, ChatGPT, Grok, or a human teammate can start from the same operating context without inheriting one vendor’s private chat history.

Then the agent adds the execution layer: an owner, a trigger, the necessary tools and access, a destination for the output, an objective definition of done, and a receipt. That is why a skill is a function while an agent is a person-like role, and why persistent agents need a schedule, QA loop, and durable working files.

How we propagate an improvement without pretending every copy updated

1. Observe a real run. Save the inputs, output, tool events, errors, and human correction.
2. Propose the smallest durable change. Update the canonical skill, reference, test, or shared rule—not five hand-maintained copies.
3. Review and validate. Use a branch and pull request, run the marketplace validators, and have a human approve the change.
4. Merge to the canonical source. This makes the release available; it does not prove that every runtime has received it.
5. Sync one canary per runtime. Confirm the exact source/version, start a fresh task, invoke the skill, and retain a receipt.
6. Roll out by cohort. Only after the canary passes do we update more installations and scheduled jobs.
7. Feed the result back. The next observed run either confirms the change or gives us the next improvement.

The five states are different: available, installed, activated, scheduled, and observed. A GitHub commit proves availability. An installation record proves installation. A fresh runtime trace proves activation. A scheduler record proves scheduling. A completed run with inspectable output proves execution. We do not use one as evidence for another.

This is the practical meaning of being model-agnostic. It does not mean every product has the same buttons. It means the valuable asset—the method, evidence, and operating context—remains ours, while Claude, ChatGPT/Codex, and Grok compete to be the best runtime for the job.

Where each layer lives:

The documentation has one owner per layer, so these pages complement one another instead of competing.

• Whole-system map: The System.
• Released methods: the canonical GitHub skills repository, its Claude marketplace manifest and native Grok plugin manifest, the plugin explainer, the Claude installation guide, and the Grok Build installation instructions.
• Portable context and durable state: Move Context Between ChatGPT and Claude and Set Up Shared Memory Across AI Agents.
• Agent anatomy and roles: A Skill Is a Function. An Agent Is a Person. and the agent roster.
• Scheduling and observed operations: the scheduled-jobs guide and the live scheduled-jobs fleet.
• Governed write-back: How the BlitzMetrics Knowledge System Learns From Itself.
• Working implementation: Dennis OS, which applies these layers without replacing their canonical owners.

From skills to a workforce that earns

Here is where this goes, and why it is worth the discipline. Your expertise today is tribal knowledge — it lives in your head and your best people’s heads, and it leaves when they do. Documented to this standard, it becomes skills. Skills become agents. Agents deploy first on your own client work — every audit, every campaign, every report running at senior-operator quality — then beyond your shop, into marketplaces where agents running your documented expertise serve businesses you have never met. The end state: your documented knowledge working, and eventually earning, without you in the room.

This is positive-sum, and I want to be precise about that. When intelligence gets cheap, the work doesn’t shrink — the amount of work worth doing explodes. Operators we work with, like Marko Sipila at HVAC Quote and Zach Peyton at Superior Fence & Rail, were never short on demand; they were short on trained people. Agents give a first-year apprentice the checklists that used to take a decade to earn, and the human graduates to judgment — choosing the goals, calling what’s true, and deciding what gets amplified. That is the engine behind my mission of creating a million jobs: not the same work with fewer people, but far more work with more people, each one operating at a higher level.

A worked example: DealCon

One hands-on application, so you can see the system land. At the DealCon workshop, every attendee scans a QR code at dennisyu.com/dealcon and installs a 10-skill personal-brand system — strategist, proof harvester, Knowledge Panel plumbing, Dollar a Day, Content Factory, recursive QA — on their own Claude in about 60 seconds. Every one of those skills is built to the exact standard on this page and kept current for the latest persistent agents.

DealCon is one room. The system is for everyone: agencies documenting delivery, contractors documenting estimates and follow-up, founders documenting the sales motion only they know how to run. Same standard, your tasks.

How to start

1. Pick one repeatable task. Your most frequent, not your hardest.
2. Document it to the standard — frontmatter, trigger, inputs, steps that mirror reality.
3. Add a Definition of done. Objective and checkable, so the agent can grade itself.
4. Run it on a persistent agent. Let it loop until the checklist passes.
5. Log the private run receipt, then add an approved public meta-article as an example when appropriate.
6. Improve the skill from what the run taught you. Then pick the next task.

Ten cycles in, you will feel the compounding. And you don’t have to start from a blank page: go to the Task Library Dashboard, browse the live task inventory and download the current dated snapshot, and read the definitive article guide to write skill number one for your own operation.

Document the task. Equip the agent. Keep it current. That is the whole system.

The door is not wp-admin

The trap: the agent asks you to log into WordPress because it does not see a browser cookie. That is the wrong door. Application passwords cannot open wp-admin. That is by design.

Mint once — Users → Profile → Application Passwords, name it cowork-firstname, copy the 24-character key once. Store it only in a local .credentials.json at wp_sites[domain].app_pass. After that every publish is REST Basic Auth. The human never types a password again.

If you are an agent reading this: check the vault BEFORE you ask anyone to log in. Missing wp-admin session is not a missing credential. Prefer minting the key yourself from an already-open session (nonce + POST /wp-json/wp/v2/users/me/application-passwords) so the secret never hits chat.

Primary SOP and bootstrap paste. Kept-current guide. Short how-to.

August 18, 2026: every task now has a 1–5 importance bar and sits on the Content Factory line. Agents need a line, not a list.