How We Build and Maintain AI Agents

Already in the room? Point your agents here. Share this URL or scan the QR. They can run the system from this page.

blitzmetrics.com/build-agents/

Building an agent starts with a clear task recipe: its trigger, inputs, steps, and checks. An AI worker can use that recipe when it has the required tools and access. Saving a recipe does not create a running worker, a schedule, or memory; each requires its own setup and proof.

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

At Local Service Spotlight, the written task method is a skill. It follows the definitive article standard and can have a companion SKILL.md. An agent is the named AI worker role that uses that skill with the required context, tools, access, and checks. We build the method first:

• Frontmatter — permanent name, category, Content Factory (our four-stage process for using real content) 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

We improve each task method through the same five-part review loop:

1. Do. Start from the real source and, when the job is authorized and its required access is available, run one bounded attempt. If a real run is not available, keep the guide in draft, label teaching examples, and record the evidence gap.
2. Document. Write the SKILL.md from the owned procedure, reliable source evidence, and observed run. Keep unsupported steps and outcomes marked as gaps.
3. QA. Check the file and the output against the Definition of done with evidence. A worker’s self-check helps find defects; it does not replace required independent or human acceptance.
4. Example. Write a meta article (a record of one task run) for every execution, linked to the canonical task, run ID, result, and evidence. Substantive organization work also gets the private receipt. Publication follows the existing authority and privacy boundary; required writing does not make private work public.
5. Improve. Propose what the run taught you as a source change, following Knowledge System Maintenance. The next run uses it only after the change is reviewed, saved, distributed, and activated where needed.

A configured agent job can carry out parts of this loop and propose improvements. Each part still needs the worker, tools, access, trigger, saved state, and write boundary that the job requires. A self-check or proposed edit is evidence for review, not proof that the method updated itself.

Good documentation gives the next authorized worker a clear starting point. The next round happens only when a real job runs it and leaves evidence.

How we keep agents current

A maintained system checks whether a new runtime capability changes a real job. Persistence, memory, tools, and background work depend on the chosen product, host, account, limits, and setup; they are not traits that a skill file gives every model. We update a method or runtime wrapper only after the capability is documented and a bounded test shows it helps.

Garry Tan’s “Boil the Ocean” essay argues that lower implementation costs can make broader completion worthwhile. Apply that idea to the whole agreed job: finish the useful work and its material checks, and measure the actual cost. Use the project’s scope, authority, time, and retry limits to decide when an unresolved issue needs a new decision.

And because “we keep agents current” is a claim anyone can make, we date everything. Every execution leaves a written meta article with its task link and evidence. Substantive organization work also leaves a private receipt; publish the meta article only when authorized and appropriate. 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.

Historical installation evidence: August 14, 2026. The following 27-skill receipts describe that release. The current maintained marketplace lists 32 skills in version 1.4.0; its source inventory does not prove that any account has installed or tested the new release.

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?

In the dated August 14 snapshot, 27 released skill names mapped one-to-one. This does not establish current installed parity or runtime capability. 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.

Historical bundle and installation snapshot, August 14, 2026; not the current package inventory.

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. lss-everything is the smaller curated pack in the current Local Service Spotlight marketplace. The BlitzMetrics Everything name in the receipts above belongs to that older installation. 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. A Grok Build recurring prompt is a different runtime feature; this review did not re-verify its current expiry or production guarantees. Confirm the intended host, access, and an observed firing for the actual job. 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. Choose a documented host for the job and test its access, trigger, result, and failure handling. A recurring prompt alone is not deployment proof. 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.

The agent adds the execution layer: an owner, a trigger, the necessary tools and access, a destination, an objective definition of done, and a receipt. That is why a skill is the method while an agent is the worker role. One-off jobs need a real trigger; recurring persistent agents also need a configured schedule, durable working files, and a checked first firing.

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 may live in your head and your best people’s heads. Documented to this standard, a repeatable method becomes a skill. A named agent can use that skill after its context, tools, access, and checks are set up. Start on bounded internal work, measure the output, and expand only after it passes the real acceptance rule. The method can then travel without pretending that the file alone did the work.

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

Historical DealCon workshop example. The workshop plan used a QR code at dennisyu.com/dealcon for a 10-skill personal-brand selection covering strategy, proof, entity work, Dollar a Day, Content Factory, and QA. Its setup target was 60 seconds; actual setup depends on the user’s app and access. For today’s pack, follow the owned installation guide for your app, supply the needed files and access, and check one skill’s result.

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 one bounded job. Give the named agent the required context, tools, access, and stop conditions. Check the output and evidence; fix specific failures within the retry limit, then hand unresolved work to the named owner.
5. Write the execution’s meta article with its task link, run ID, and evidence, and keep the private internal receipt for substantive organization work. Publish only within the existing authority and privacy boundary.
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.

Use the WordPress door the job requires

WordPress browser sessions and REST API credentials serve different jobs. An Application Password cannot open wp-admin; it may support a REST workflow when that site, user, route, and job permit it. Some publishing work still needs the supported editor or another owned path.

Use existing access already authorized for the job. Create, rotate, or delete an Application Password only when access management is explicitly in scope and the site owner or authorized user can do it. Store any secret in the project’s approved credential system; .credentials.json and wp_sites[domain].app_pass are one local implementation, not a universal path. Record which supported publish route was actually used.

If you are an agent reading this, check the approved access record before reporting a blocker, without exposing a secret. A missing browser session does not prove that an API credential exists, and an API credential does not prove editor access. Do not mint a key from an open session unless the current job explicitly authorizes that access change. When required access is absent, name the exact account, role, and owner needed; continue safe authorized work that does not depend on it.

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.