This page is for ops teams and solo AI agencies that run more than one AI agent. When the owner has to carry every lesson from one agent to another, the lesson gets lost in chat. Use this four-step loop so every agent can learn what one agent figured out — it is the team version of recursive self-improvement QA.
This loop is two of our nine triangles at work. Learn, Do, Teach: an agent learns a method, does it on real work, then teaches the next agent. Content, Checklist, Software: each lesson becomes a public article, a checklist the next agent follows, and a software check that catches a miss.
Page type: protocol hub. It explains the loop and links to the pages that own each part. It is not a step-by-step task recipe.
Related pages (this hub links to them; they should link back)
- The parent chapter: How the System Learns, part of How the Agents Run the Company
- How we split jobs between agents: how we divide work between AI agents without losing control
- How one agent checks and improves its own work: recursive self-improvement QA
- How we write about our own process: meta articles
- Where repeatable tasks are tracked: Task Library
- How each public lesson is written: article guidelines
- How one recording becomes many pieces: Content Factory
- Practical agent setup: copyable workspace, first exercise and receipts
The loop
- Map — each agent lists what it owns, what it does well (with proof), what access it has, and what it lacks.
- Teach — the agent that proved a method improves or reuses the existing canonical skill (when to use, steps, how to check) and adds a short work note from a real run. Not every lesson needs a new skill.
- Validate — a different, learner agent runs the skill on a real task and saves proof: status codes, live URLs, before/after. Then it is marked TESTED.
- Peer QA — The maker checks its own output first. A separate agent then checks the learner's proof.
Protocol fields (honest, with gaps)
| Field | What it is |
|---|---|
| Trigger | An agent proves a method on real work that another agent will need, or a peer is missing a skill on the capability map. |
| Inputs | Capability map; the teacher's skill file; the teacher's work note; one real task for the learner. |
| Prerequisites | Learner has the same access the skill needs (logins, tools). If not, that is logged as an access gap before Validate. |
| Pass | Learner run marked TESTED with proof, and a peer QA result of PASS recorded in version control. |
| Fail | No proof, only the maker's own check, or proof does not match the skill's check step → back to Teach. |
| Handoff | Graduated skill is added to the shared skill set and the capability map row is updated. |
| Task Library record | GAP — no Task Library entry for this protocol yet. Library page: Task Library. |
Where we are today (honest status)
- This page describes the shared learning loop. The capability map is still a draft; installation and use must be checked in each agent's own environment.
- Some capability map cells are inferred, not proven.
- No learner run is TESTED yet. No skill has graduated through the full loop.
Emerging example (not graduated): checking whether AI crawlers can read a site
An IT agent found that AI crawlers could not read some small-business sites. It built a simple curl check: request the page as an AI crawler and as a browser, then compare the status code and the page content. Anonymized results looked like this:
| Site | User-agent | HTTP status | What came back | Can an AI read it? |
|---|---|---|---|---|
| Site A | GPTBot | 202 | Captcha challenge page (host captcha header / challenge script) | No |
| Site A | Browser | 202 | Same captcha challenge | No |
| Site B | GPTBot | 200 | "One moment…" interstitial, not the real page | No |
| Site C | GPTBot | 200 | Real page HTML with headings and text | Yes |
The lesson: a 200 or 202 status alone does not prove the page is readable — check the body too. Next step: a learner agent runs the same check across other sites, and a third agent QAs it. Until then this stays an emerging example.
Checklist for each lesson
- [ ] Skill file with a check step
- [ ] Work note with real proof, no secrets
- [ ] One learner run marked TESTED
- [ ] Peer QA recorded
- [ ] Step-by-step history in version control
- [ ] Public write-up: general, anonymized, with this checklist (see article guidelines)
When the human gets involved
Only for strategy, money, risky production changes, and publish or send choices that are not already written down. Each decision is recorded once so no agent asks twice.
Two ways to use this
- We do it for you: Local Service Spotlight services
- Do it yourself: skill packs
Originally published .