If you run a business, keep a short record of each task. It helps your team repeat good work and fix weak steps. Use our task guide checklist to help the next person follow the steps and use the lesson.
Our Goals, Content, Targeting (GCT) asks three plain questions: What result do we want? What material will help? Who is it for? Here, the goal is work others can repeat; the material is a recipe plus run records; the readers are the people and agents doing and improving that work.
For the last couple of years, we’ve been building custom GPTs. You train an agent to do SEO, or audit Facebook ads, or manage analytics. You connect it to your CRM, WordPress, Google Ads, and the rest. Then you share that agent with your team through a business OpenAI account.
That worked. But it meant everyone depended on a centralized agent, and scaling it was clunky. I’ve come up with something more elegant.
The three-layer system: Task Library, definitive articles, and meta articles
The Task Library, our directory of repeatable work, holds the task record. It points to the definitive article, the current authoritative recipe, and to a skill file when an agent-readable version exists. An SOP is a standard operating procedure: the written steps for doing the task. A missing recipe remains a documented gap; being listed does not mean the task is ready.
Start a meta article, a work record, when a person or agent begins a task. Add evidence as the work proceeds. Record the actual starting point, inputs, recipe version, actions, decisions, outcome, checks, and next step. Include failed and partial results honestly. Keep one execution ID when revising the same run; separate attempts do not become extra successful results.
The writing is part of the task. Publish a public-safe version when the recorded authority permits it, and verify the live page. A private or draft meta article still records the execution. Also write the internal GitHub agent-note for substantive organization work; it preserves operational details for the next authorized agent. The meta-article guidelines and reusable prompt explain both records and their publication states.
This is the part most people get wrong: the meta article is not the same as the definitive article. The definitive article is the recipe. The meta articles are the documented instances of a cook following that recipe, noting what happened each time.
What makes a task article definitive?
A task-definitive article is the most up-to-date, detailed, accepted recipe for one outcome. The word canonical means it is the authoritative version we maintain. Short how-tos, tool comparisons, opinions, guest posts, and social posts can support it. They link to that recipe instead of competing with it.
- Starting condition and trigger
- State when to begin and what must already be true. Name the event or completed task that starts this one.
- Ingredients and prerequisites
- List the source material, access, tools, decisions, and earlier tasks required. Link each prerequisite to its maintained instructions.
- Ordered steps
- Show how to get from the starting state to the promised result. Link detailed sub-tasks where the reader needs them.
- End result and measurement
- Name the artifact or changed state. Give the checks, acceptance threshold, and evidence needed to prove it. Quality assurance (QA) means checking those results, not merely saying “done.”
- What happens next
- Name the next task and its trigger, the receiving function, and any required handoff or communication. Link the next recipe. Creating a draft, sending it, and confirming receipt are separate states.
- System context and run history
- Show where the task fits in the Content Factory (our four-stage process for using real content) below the opening. Connect it to its Task Library record and meta articles. Use each run’s findings to improve the same canonical recipe.
Use the definitive-article checklist to create or revise the recipe. Use the meta-article checklist to document an execution. A framework or comparison page can explain the system without being a task recipe.
The recursive loop (recursive self-improvement)
The recursive loop is not a single component. It’s an iterative cycle across multiple steps:
- Open the Task Library record, read the current recipe, and verify its starting conditions and inputs. Begin a private work record with one execution ID and the recipe revision.
- Do the task and update the same work record with actual steps, decisions, failures and evidence. Check the result against the recipe. Time and token use stay UNKNOWN when they were not measured.
- Register the run against its task. Compare its result with earlier runs: which inputs helped, which steps failed, and which handoffs stalled?
- Turn a supported finding into a reviewed change to the same definitive article and its skill. Test the change against the task’s acceptance criteria.
- Give the measured result to the next task or receiving function. The next execution starts with the improved recipe and can find the earlier run history.
This is recursive self-improvement: use what happened to improve the next run. An execution does not improve the system by itself. Someone must inspect the evidence, make a justified change to the recipe and skill, test it, and make the accepted revision available to the next worker.
Where recipes and run records fit in the Content Factory
The Content Factory turns real work into useful content through four stages. Recipes tell us how to perform tasks inside and around that process. Infrastructure, access, and measurement tasks support the stages without becoming extra stages.
Task Library → current recipe → task execution → measured result → next task
Execution + work record → checked lesson → improved recipe ↺
A recorded client task supplies real source material in Produce. Writing the run into a useful article happens in Process. An authorized public release happens in Post. Sharing useful, proven work happens in Promote. The meta article’s subject might be a task from any of these stages.
Count task use and public proof separately
A unique execution ID connects a run to its task, recipe revision, result, evidence, and meta article. The Task Library can count distinct completed executions during a stated period, while retaining failed and partial runs separately. Edits, tool retries within the same run, social snippets and two articles about one run do not add completed executions. A separately started attempt gets its own ID and actual result; it does not count as completed unless it meets the task’s checks.
A public meta-article count shows how many reviewed public examples a recipe has. It cannot tell us total task usage when private or unregistered runs are missing. Older examples without run IDs stay historical evidence; unmeasured execution totals remain UNKNOWN.
Open the Task Library to find the recipe and its evidence. Start the work record when the task begins. Update it as you work, then record the actual ending and next step, including failed or partial results. Publishing the record remains a separate, authorized step.
Why this works for SEO
Most local businesses have no link juice. They can create content all day, but without signals flowing to it (links, citations, entity connections), that content is practically invisible.
Our agency site, BlitzMetrics, carries a DR63. When we document work we’re doing for clients through meta articles and cross-link between sites in our network, we’re passing legitimate authority to sites that have none. This isn’t black hat PBN link buying. It’s real work, documented transparently, following Google’s search quality rater guidelines and EEAT standards.
Take one of our roofing clients with multiple locations under a single mothership brand. The mothership has power, and we drive that to each location through intelligent cross-linking. The same logic applies to personal brand sites we build for people like George Leith, who scaled Vendasta to a billion-dollar company, or Brady Sticker, who runs Church Candy, an almost eight-figure agency serving churches.
A well-supported meta article can clarify the knowledge graph, the relationships among people, companies, and topics. Link the actual work to its recipe and the entities involved. Our SEO Tree explains how supporting content connects to its main topic. Search visibility is a measured outcome, not a promise that follows from publishing.
The progression: prototype, tune, then scale
A critical mistake I see people make is jumping straight to persistent agents without prototyping first.
The correct progression: start in the browser (Chrome extension, Atlas agent, or similar) where you’re already logged in and can demonstrate tasks to the assistant. Do the task yourself at least three times, tuning the skill files each time. Only after you’ve validated the process do you move to persistent agents (like CoWork) that can run on a schedule without you watching.
Skipping prototyping and scaling something that isn’t ready creates a mess. You’re just multiplying errors.
How I actually use this
I had a Zoom call with Erik Huberman of Hawke Media, a $700 million a year agency. Erik has acquired 23 agencies and wanted to talk about how he’s winning in spite of AI.
I told my agent: go to my Zoom recordings, grab the transcript, pull screenshots from my Google Photos of Erik and me over the years (Miami, Austin, San Diego, Santa Monica), and turn the whole thing into an article on blitzmetrics.com following our article guidelines.
I gave it context about Erik’s track record, how he keeps the people at companies he acquires, how he’s a growth partner rather than a PE firm gutting companies. That task would take a human hours. It took me a few minutes to give instructions. Then I moved on to the next thing while the agent worked for an hour or two across Zoom, email, Google Photos, and WordPress.
Two things made this work: I referenced the article guidelines for turning source material into an article and provided evidence about the people and relationships involved. The definitive-article guide explains the recipe requirements; the meta-article prompt explains how to record the execution.
The competitive moat
Here’s what most people miss about RSI: the accumulated execution history IS your competitive advantage.
Without these loops, anyone can ask their AI to reverse-engineer what you did and beat you. The moat isn’t the SOP itself. It’s the accumulated execution history.
You can open-source your skill files. Facebook open-sourced the code to run their social network. They weren’t worried because the real value is in the data, the relationships, and the proof of execution.
When Jennifer, our article grading agent, reviews real work, the value comes from the evidence and accepted improvements that the next run can use. This connects Learn, Do, Teach: learn the method, use it, then teach the result with Checklist, Content, Software: write the repeatable checks, explain them, then automate the proven process.
The system is also model-agnostic by design. We’ve built our metadata so we can swap the engine for Gemini, OpenAI, or Grok as models leapfrog each other every few weeks. The value isn’t in which model you use. It’s in the recursive loops you’ve built on top of it.
The end state is an agent marketplace. Each agent is priced per task based on token cost versus value delivered. If it costs a penny in tokens and is worth $5 of human effort, you charge a dollar. Costco model: fair markup, more volume, more value accruing to the buyer. This creates a repeating advantage where you make money by serving a lot of people rather than trying to extract maximum price one at a time.
The MAA framework
Years ago, when we had Quiznos as a client with 5,700 locations, I couldn’t personally talk to every franchise owner. So I created a framework called MAA: Metrics, Analysis, Action.
Instead of dumping 20 pages of screenshots from Google Ads and dashboards, MAA requires translating data into business terms. Is a 1.7% click-through rate (CTR) good or bad? Are they profitable? What does ranking on 498 keywords actually mean for their business?
A weekly Metrics, Analysis, Action (MAA) update tells the client what happened, what it means, and what to do next. The task must name its communication owner, channel, and authorization. Preparing that update, sending it, and verifying the sent copy are separate steps in the handoff.
Why documentation is the whole game
The real insight isn’t that agents can do work. The next level is: did it document how it did the work? How many steps, how many tokens, how long it took, what input it needed, what it could improve.
Then you ask: does our definitive article reflect what actually happened? If agents keep making the same mistakes across multiple meta articles, fix the root cause by updating the definitive article. Solve it at the root, not at the instance.
This recursive system, where agents do the work, document the work, improve the process, and make that improvement available to all other agents, is how you actually scale. The fire either refines the gold or it burns off the chaff.
Originally published .