How We Build and Maintain AI Agents

New here and not technical? Start at blitzmetrics.com/start — the forty-minute setup, written in plain English. Come back to this page afterward.

Building an agent, the BlitzMetrics 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. For a plumber that is the estimate follow-up. For HVAC it is the seasonal tune-up campaign. For a roofer it is the storm-lead response. 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.

What an agent actually is here

Not a dashboard demo. Not a chatbot wrapper. 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 CSR and they can run the follow-up. Hand it to an AI agent and it runs the task the same way. The instructions outrank the operator — which is exactly what makes the output consistent.

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 job into articles, clips, and ads.

The proof: 239 tasks you can browse and download

We didn’t write the philosophy first and hope. We documented our entire operation: 239 tasks across 13 categories — from digital plumbing to Dollar a Day to website QA — mapping to 22 definitive articles. As of the master’s last published count, 119 are complete, 97 need work, and 23 are gaps. Those statuses are public on purpose: an honest scoreboard is what makes a library improvable, and every red gap is a work order, not an embarrassment.

All of it is live on the Task Library Dashboard: search the full SOP text, read any skill, copy it, or download all 239 in one free zip. The dashboard is the what. The master hub is the how and the why. The local-service on-ramp is the Skill Pack Library on this site — Business Authority and Entrepreneur packs hosted here, plus the vertical editions.

Kept current on the master — updated August 12, 2026 for the latest persistent agents (Claude Fable 5, OpenAI, Google). Rebuilt from the source skills through a controlled release path. If a number on this page and a number on the master disagree, the master wins.

How we build an agent: the loop

Every agent in the library comes from the same five-beat loop. A local-service example, so it is not abstract: the Friday “who did we serve this week, and who still needs a review ask?” pass.

1. Do. Run the task for real. Sit with the CSR or the owner. Watch how they actually pull the week’s jobs, which customers they text, and what they skip. 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. Publish a meta-article documenting one real run — proof, not promises — linked back 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. When a frontier capability lands, we don’t admire it. We re-equip the library.

What changed in the models	What we changed in the agents
Long-horizon persistence	Agents loop until the Definition of done passes. Ninety percent finished is a draft, not a deliverable — the same way a half-written estimate is not a sent estimate.
Memory across runs	Skills instruct the agent to read prior runs and upstream outputs first. Never start from scratch twice. Last Friday’s review list is an input, not a memory test.
Self-verification	The agent grades its own output against the skill’s QA checklist, line by line, before reporting done.
Near-zero cost of completeness	Full coverage by default: edge cases, error paths, the test, the doc — the whole thing.

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.

And because “we keep agents current” is a claim anyone can make, we date everything. Every update is logged, every run leaves a meta-article, and the dashboard carries the changelog. The proof of currency is a paper trail, not a promise. The live runtime scoreboard — Claude vs Codex vs Grok, the 27-skill marketplace pack, the hash fingerprints — lives on the master. This page does not duplicate those receipts.

One operating system, three model runtimes

We are not building a different marketing brain for every AI company, and we are not building a different brain for every trade. 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.

A plumber in Phoenix and an HVAC shop in Minnesota can run the same Content Factory skill. The context changes — the customer names, the job photos, the Google Business Profile — the method does not.

Three owned layers stay 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.

The model is not the source of truth. The source starts with real work: job photos, invoices, reviews, Google Business Profile access, interviews, 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.

Personal and project context should live in user-owned Markdown files or another governed source the authorized agent can read. 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.

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.

How a new skill lands

Saving a skill in a chat does not put it on the path. I have watched this happen enough times that the reminder itself became the bug: a workflow exists on one machine, and everyone else — human or agent — keeps getting told it is “already a skill.” It is not, not until it has a folder in the canonical repo, a public page, and a canary receipt.

The loop above is how we propagate an improvement without pretending every copy updated. This section is the missing checklist for a brand-new skill: the concrete surfaces it has to hit. Humans and agents read this same page. Agent detail is at the bottom, not on a second URL.

The Task Library is 239 documented SOPs. The marketplace pack is the smaller curated set we distribute through the plugin. Those are different inventories. Do not add the counts and do not describe them as the same product.

The surfaces, in order

1. Canonical repo. A chat skill is local until it lives in dennisyu/blitzmetrics-skills. Add or update skills/<slug>/SKILL.md on a branch. Directory name and frontmatter name must match.
2. Review, then merge. Pull request, marketplace validators, a human approve, then merge. Merge makes the skill available. It does not install it anywhere.
3. Point siblings at it. Related skills get a one-line pointer. Do not paste the same rule into five files.
4. Public skill page. Same pattern as the other skills on the Skill Pack Library — one URL per skill, with a last-updated date. Generate it from the skill file. Do not hand-write a second description.
5. Packs and plugin, only if it belongs. The plugin explainer is the box the curated skills ship in. A writing-voice rule or a one-off SOP does not automatically join that box. If it is not yet curated, file it in the Task Library and say so.
6. Canary, then cohort. Do not tell anyone the skill is in Claude, ChatGPT, or Grok until a fresh task on that runtime invoked it and left a receipt. Then roll out by cohort. That is step 5 on The System — Propagated everywhere — done honestly.

BlitzMetrics stays up for SEO. New public work lands here and on the Skill Pack Library, not on a second competing hub.

For agents

If a human sent you here after creating or updating a skill, this checklist is yours. Do not open a new article on this topic.

1. Read this whole page, then The System. The map already exists.
2. Inspect the canonical skills repo with gh or the GitHub API. Do not clone it onto the operator’s machine.
3. Add or update skills/<slug>/SKILL.md on a branch. Open a PR. Run the marketplace validators. Wait for a human to approve.
4. Add a one-line pointer from each sibling skill. Do not duplicate the rule.
5. Add the slug to pack and plugin manifests only when that is the existing pattern for this kind of rule. Otherwise add the folder plus a Task Library / registry pointer. House rules that every skill must obey often belong in standards/ so they stamp into every skill — that is not the same as joining the curated pack.
6. Give it a public page on the Skill Pack Library, generated from the skill file, same pattern as definitive-article-writer.
7. Live-check every new href. Cite the URL that returns 200, not a redirect hop.
8. Do not report the skill as installed, activated, scheduled, or observed. Do not say it is in Claude, ChatGPT, or Grok until a fresh canary on that runtime invoked it.
9. Publish edits to this page, as the person, when you have a WordPress Application Password. If you cannot publish, write the HTML and name the exact blocker. Never create a competing hub.

From skills to a workforce that earns

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 customer work — every audit, every campaign, every report running at senior-operator quality — then beyond your shop.

This is positive-sum. 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. Those two names are from the master, not a new claim. 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 the 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 from the master, so you can see the system land. We do not have a separate local-service workshop receipt to substitute, so we keep the documented one and say so.

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 the master 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. For this network the install door is your vertical’s Set Up Claude page and the Skill Pack Library.

How to start

1. Pick one repeatable task. Your most frequent, not your hardest — the estimate follow-up, the review ask, the Friday report.
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 a meta-article of the run as the skill’s first example.
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 all 239 skills, download the whole library free, or install the Business Authority pack from this site.

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

To publish to WordPress without handing an agent your real password, use an Application Password. The agent never gets the login or the 2FA, and you can revoke the key in one click.

Where this sits in the system

Context is what the worker knows. A skill is the method it follows. A pack is a folder of methods. None of them does any work alone. Work happens when a job runs the right skill against the right context on a schedule, checks its output, and leaves a receipt the next worker can inspect.

1. 1. Context The verified facts, goals, evidence, decisions, and working state kept in user-owned Markdown, Obsidian, Drive, or Git so any authorized model can pick up the same work.
2. 2. Skill One task, written down to a standard, so an agent can run it without you in the room. There are 239 of them.
3. 3. Pack Those skills bundled into a download you install in one paste. On this site: the Skill Pack Library.
4. 4. Agent — you are here A named role with a job description — not a chat window you retype every morning. Master: blitzmetrics.com/build-agents/.
5. 5. Job A schedule, a QA cycle, and somewhere to keep working files. Miss any of the three and nothing runs twice.
6. 6. Proof Every finished run written up in public, and the lesson pushed back into the skill. The registry of public pieces is the Asset Tracker.

The map: The System · every asset: Asset Tracker · the sites: Spotlight Network · next door: Persistent agents.

Local Service Spotlight edition of the BlitzMetrics master. Same doctrine. Vertical examples. Links up, never sideways as a competing hub. If you need the live model-runtime scoreboard, the 27-skill marketplace pack, or the hash fingerprints, read the master.