Claude builds. Codex checks. Grok works the same rails from outside the live room. Cursor is the desk I sit in with them. ChatGPT is a rented chat until it leaves a receipt. They coordinate in four places: GitHub remembers, Basecamp has the client, Buzz is the live handoff, and scheduled tasks run when nobody is there. If it only happened in a chat window, it did not happen.

Goal: hand a stranger, or their agent, a recipe they can copy: which model sits in which chair, where the work is written down, and what counts as done.
Content: five desks (Claude, Codex, Grok, Cursor, ChatGPT), four surfaces (GitHub, Basecamp, Buzz, scheduled tasks), a ten-step setup, and one week of the Social Amplification Engine as the worked example.
Targeting: operators already running more than one model who want a SOP, not a vendor pitch.

Who sits in which chair

Name the job, then pick the model. Nicknames on my Buzz board (Engineer, Fizz, Honey, Pollen) are labels for jobs, not a product you have to copy. Your builder, writer, and checker can be named anything. The rule that matters is this: the agent that checks the work is not the same model that did the work.

May the best idea win. The newest model does not win by default. The idea with a receipt wins.

The one question

Before you or your agent writes anything, anywhere, ask one thing:

Who has to find this, when, and what do they need to do with it?

That question sorts everything, because each of the four places has exactly one thing it can do that none of the others can. Pick the wrong one and you do not get a small mess. You get a specific, predictable failure.

GitHub is the only one that remembers

An agent three months from now can open a GitHub repo and reconstruct what happened, who did it, and what it touched. It can read the diff. It can see the date. It can see what the last agent said it did not check.

Nothing else on this list can do that. A chat message is gone the moment the window scrolls. A Basecamp thread is readable but not diffable. Buzz keeps almost nothing.

So GitHub carries the record: what ran, what it read, what changed, what passed, what was not checked, and what is blocked and on whom. Every agent on my team writes a note there at the end of every real job — the same template, every time. That is how a stranger’s agent can pick up work my agent started. It is the same loop I described in how skills propagate.

The public methods live in the Local Service Spotlight skills repo. The team ledger is a private repo. Do not treat a private URL as the recipe. If a stranger cannot open it, it is not the public SOP.

It is never wrong to also write to GitHub. The failure is not writing there, which quietly turns finished work into rumour.

Basecamp is the only one with the client in the room

That single fact sets the whole standard for it. Everything you put in Basecamp is read by a human who is paying you, has not read your repo, and did not follow your reasoning.

So Basecamp carries decisions and client-visible statements. It does not carry thinking out loud. It does not carry a claim you cannot back with a receipt. And it does not carry a link that works for you and returns a permission error for them — which happens more often than anyone admits, because you are logged in and they are not.

One hard rule my agents have, learned the expensive way: never reply to a Basecamp notification email. Email replies drop the routing token, the comment never lands on the thread, and you get a bounce that reads like a system error rather than “your client never saw this.” Post in Basecamp. Then verify the comment is there by opening it, not by looking at your sent folder.

Buzz is the only one where two different models are in the same room

Buzz runs agents as real processes that connect to a relay and sit in channels, like a team chat where some of the members are software. What makes it different from every other chat tool is that the agents do not all have to be the same model. Mine has Claude on three seats and OpenAI’s Codex on the fourth, in the same conversation, at the same moment, with me able to watch and interrupt.

Nothing else I use does that. GitHub is asynchronous. Basecamp moves at human speed. Buzz is the handoff — “I am done, you are up, here is the link” — across models that otherwise cannot see each other at all.

So use it for exactly that, and nothing else. Not status. Not thinking out loud. Not encouragement. If it is worth writing down, it goes in the repo. If it exists only in a Buzz channel, it did not happen.

Scheduled tasks are the only one that runs when nobody is there

The fourth surface is the clock. A scheduled task fires at six in the morning with no human present, does the work, and writes its receipt.

The trap here is subtle and I have watched smart people fall into it. A schedule is not an outcome. “It is scheduled” and “it ran” and “I saw the result” are three different states, and the gap between them is where a month of silently failing jobs hides. My agents are not allowed to report one as the other.

Do not invent a second clock for a new idea. Fold the checkpoint into a clock you already have. We learned that the loud way on Social Amplification: the weekly heartbeat is the existing MAA run, not a second SAE timer.

The copyable recipe

1. Search before you mint a URL. One concept, one public page. Skins and case studies link up. They do not fork a second master.
2. Write GCT in three lines before the draft. If you skip it, you get a generic article that could sit on anyone’s site.
3. Claim the work on a visible board so a second agent does not start a second copy. On our team that board is a private NOW list. Yours can be a GitHub issue. The point is a lock, not our filename.
4. Pick the chair by the job. Builder and writer may share a model. The checker should not.
5. Do the work where a human can see the diff when the job can break a site or a client sentence. That is why Cursor exists in this picture.
6. Write the receipt in the repo before you tell anyone it is done. Template, every time: what was asked, what you found, what you changed, what you got wrong, what is blocked, the next click.
7. Client-visible decisions go in the client tool. Never Gmail-reply to a Basecamp notification. Changing the From line does not fix the routing.
8. Use the live room only when two models must talk now. Post links, not contents. Every agent answers the human, not the other agents.
9. Attach the job to an existing clock if it has to run again. “We should schedule that” is not a receipt.
10. Public pages follow the article guidelines until the checklist is green. First person on a personal site. WordPress author is the person, not admin. Lead visual is article-specific, above the fold, not a generic framework card. Entity links: people to their site, our concepts to the definitive page, 3–6 word anchors, no “click here.”

If you want the architecture under this recipe — three rooms and a credential safe, one authority per record class — read How Our AI Agents Share Memory and Coordinate Work. If you want a dated worked example of standing up that memory, read Give Your AI Team One Shared Brain. Those pages are not this page. This page is who sits where, and in which room.

A week of this, in public

The worked example is the agentic Social Amplification Engine. Amplify reputation, proof, and trust that already exist. Do not manufacture authority. Screen with GCT before you amplify. The commercial pointer is Local Service Spotlight’s GCT qualify page. The course that teaches the six phases to humans stays at its own URL. We did not mint /sae-2/.

What the agents actually did, split by chair:

• Codex built the evidence gates so UNKNOWN is not zero and nobody invents a 0–100 score. A public self-report cannot mint verified evidence.
• Claude wrote the four-surfaces article you are reading the first version of, and the Buzz house rules so agents do not burn tokens thanking each other.
• Grok in Cursor published the operating hub, filled the screen skill, and is the desk enhancing this page so it also answers “who does what.”
• Grok Bot opened a standards pull request on the public skills repo. A stamp pass truncated a skill file to one byte. Cursor restored it. That is the point of a second model: it catches the first.
• Humans still own send, publish, spend, and merge. A “qualified pending review” badge is a candidate. It is not a client, not a roster row, and not permission to run ads.

Content still moves Produce → Process → Post → Promote. Paid math in Promote is Dollar a Day. The weekly heartbeat is Metrics → Analysis → Action. Factory and ads plug into those functions. They do not fork a second engine.

The build record for that week is How We Built the Agentic SAE. Read it after this page, not instead of it.

The rule that keeps the bill down

Here is the thing nobody warns you about when you put several agents in one room. They will talk to each other. Not usefully — politely. “Great point.” “On it.” “Let me know if you need anything else.” Each of those is a full model turn that you paid for and that moved no work forward.

When I opened my own Buzz configuration and actually read it instead of assuming, here is what I found. One agent was set to answer only me. The other two were set to answer that agent. So one message from me produced three turns: the first agent answered me, and then the other two each answered the first agent. Two out of three turns were an agent replying to an agent with no work in hand.

That is not the model behaving badly. That is a default nobody chose. The concurrency setting was also sitting at ten on every agent, with no ceiling at all on how long a single turn could run.

The fix is one line of policy and four settings:

• Every agent answers only you. Not each other. An agent posting near you is not a reason to speak.
• Every message carries one of four things — a deliverable, a decision, a blocker with a named owner, or a question only a human can answer. If it carries none of those, say nothing. Silence is a valid output and usually the right one.
• Post links, not contents. A wall of pasted output in a chat room is unreadable by the next agent and costs everyone who loads the thread.
• Nothing gets sent, published, or paid for unless a human said go in that thread. The agent stages it. A person clicks.

I keep those rules in one file and point every agent’s instructions at the file rather than pasting the rules into each agent. Paste them four times and your next edit reaches one of them. That is the same reason we keep one concept on one page instead of four slightly different copies.

A second Claude is not a second opinion

When I set this up, all four of my Buzz agents were Claude. They are excellent. They also tend to be wrong in the same direction, because they are the same model reading the same context.

So the researcher seat — the one whose whole job is checking assumptions — now runs on Codex instead. The agent that checks the work is deliberately not the model that did the work.

Grok is not in that room yet, and I want to be precise about why rather than vague. There is no adapter published that lets the Grok command-line tool speak the protocol Buzz uses. That is not a setting I have wrong. The piece does not exist. So my Grok desk hands off the way any outside contributor does — through the repo and through Basecamp.

What broke, and why I am telling you

I tightened those Buzz settings and reported it done. It was not done. I had set two timeout values the wrong way round — the idle timer above the maximum turn length — and the platform rejects that combination outright. My main engineering agent failed every single start for seventeen minutes and would have stayed down indefinitely, because the only symptom is an agent that quietly does not come up. Three more agents had the same broken setting waiting for them and looked fine only because nobody had started them yet.

I found it because I went and read the log instead of trusting my own change. The real lesson is not “check your work,” which everybody says and nobody operationalises. It is this: the check has to test the property you care about, not the thing you just did. My original check confirmed I had written the values I intended to write. It never asked whether an agent could start.

So the fix is not that I now remember the rule. The tool refuses to save a configuration that breaks it, and it will tell you why. A rule you have to remember is a rule you will eventually forget. Make the wrong value impossible to save and you never have to be careful again.

I write these up in public on purpose. If you only ever see the wins, you learn nothing you can use. Your first hundred are supposed to be rough — that is true of agent setups too.

If you are setting this up tomorrow

You do not need four surfaces on day one. Most people need two: somewhere the work is recorded, and somewhere the client is. Add the others when you feel the specific pain they solve.

1. Pick your record first. A private GitHub repo, one note per job, one template. Not a chat history. Not your memory.
2. Make the client surface separate from the working surface. The thing your client reads should never be where your agents think out loud.
3. Only add a live agent room when you have two different models to put in it. If everything you run is the same model, a shared room mostly buys you agents agreeing with each other at your expense.
4. Set every agent to answer only you before you set anything else. Do that on the first day, not after the first bill.
5. Write down what each surface is not. That sentence is worth more than the description of what it is, and it is the sentence everyone skips.
6. Publish the recipe on a personal-brand URL in first person, then put a short company pointer that links up. Do not write the master twice. Follow the article guidelines until every box is closed. If you use Cursor for the desk, how we use Cursor for marketing is the companion, not a second coordination master.

If you want the shape of the whole system rather than just this piece of it, start at new agents start here, then install the skill packs so your agents run the same methods mine do. If you would rather see it working before you build anything, watch one of my desks do real work and read what it wrote down afterwards.

Questions people actually ask

Is this the architecture spec?

No. The spec is set up cross-agent shared memory. This page is the roster and the routing rule in plain language.

Do I need Buzz on day one?

No. Add a live cross-model room when you have two different models that must hand off in the same minute. Until then, GitHub plus the client tool is enough.

Can Grok sit in the live room?

Not today, on my stack. No published ACP adapter. It still writes receipts and Basecamp the same way every other out-of-band desk does.

Does a public qualify page let agents onboard a client?

No. A public inventory is a self-report. Independent review, accepted scope, and an Ops roster decision come first. Default execution is stage-only. That rule is on the operating hub.

Where should a company-site version live?

As a short pointer that links up, in third person, with the WordPress author set to a named person, not admin. The Local Service Spotlight pointer is how agents coordinate.

The one line to keep

Nothing becomes true because it was said. Not in a chat room, not in a client thread, not in a meeting. It becomes true when it lands in the system that owns it, with a receipt someone else can open.

Every one of these four surfaces is just a different way of pointing at that. Get that straight and the complexity stops mattering, because the question stops being “which tool” and becomes “who needs to find this, and when.”

And if your agent tells you a job is done, ask it for the link. A run with no receipt did not happen.