What Is _AO? A Free Protocol for Accountable AI Work

Dated August 28, 2026, the day the public _ao record first supported the argument below. Written September 4; the September 4 additions are marked inline.

While rehearsing the onboarding for this protocol, we handed it to an AI that had never seen it. It read the doctrine cold, in a fresh harness with none of my system's history, and worked through the first trip. Then it flagged a weak spot—in itself and in the doctrine it had just read.

The doctrine said to challenge anything in it that failed. That rule quietly depended on the agent coming back later to file the challenge. The agent reported, accurately, that it would not reliably do that. Nothing in its harness would bring it back. The next session would start fresh, and the good intention would leave with the context.

That admission is now part of the protocol. Challenges come from a scheduled self-audit the agent proposes and its human approves—not from anyone, human or machine, remembering to do it. It is a small rule, and it is the whole problem in miniature: an AI can do real work now, and none of the work tells you who authorized it, who owned the outcome, who checked it, whether the consequential action actually happened, or what the next session will remember.

That is the gap _AO is built for.

_AO stands for Agent Orchestration. It is a free, open AI agent orchestration protocol for managing work as accountable work: clear authority, delegated ownership, independent review, durable receipts, governed memory, and a recurring improvement loop.

I already built a page at moran.bot/sao that does the classic builder thing: it explains the machine room before it explains the door handle. It tries to cover the shared pattern, my implementation, the agents, the history, and the connection layer all at once. It is useful as a wiki and bad as a first explanation.

This is the first explanation.

The underscore is the point

The pattern is _AO. The underscore is a blank that takes the human owner's initial.

My instance is SAO: Scott's Agent Orchestration. Joanna's would be JAO. Andy's would be AAO. The public _ao repository holds the shared pattern. An adopter's private repository holds their instance, their rules, their record, and their decisions.

This distinction matters because SAO is not the product and it is not the authority over anybody else's system. It is the first running example—the place where a lot of the failures happened and the protocol was extracted. Copying my names, computers, dashboards, or plumbing would miss the point.

Reproduce the properties, not our plumbing.

The properties are simple enough to state without an org chart.

• Authority is explicit. The AI knows which person it answers to, which instructions are real, what it may do without asking, and what still requires a yes.
• Work has an owner. A real mission gets one outcome owner, a written scope, an evidence bar, and a return route.
• The work gets checked. The same agent that produced a consequential result does not get to certify it alone.
• Claims ride on receipts. A send has a message ID. A deployment has a URL or release record. A change has a commit. “Done” is not evidence that it happened.
• Memory survives the chat. Rules, decisions, boundaries, current state, and lessons live in records the human owns—not only inside one vendor's conversation history.
• The operation reviews itself. The agent checks where it is drifting, where automations are rotting, and where the protocol no longer matches the harness running it.

That is Agent Orchestration. Everything else is implementation.

Chat gives you answers. An operation needs a record.

Say you ask an AI to launch a customer campaign.

In a normal chat, it may research the audience, write the copy, make a list, and tell you the campaign is ready. Maybe it is. Maybe “ready” means there is a draft somewhere. Maybe another session already made a different list. Maybe it sent the email when you thought you were approving the wording. Maybe the address it used came from an untrusted attachment. The polished answer does not tell you.

In an _AO, the request becomes a mission. The mission says what outcome is wanted, what is in scope, which systems the worker may touch, what remains prohibited, what evidence counts, and when to stop and ask. A supervisor owns the result. Workers can do the pieces. A separate reviewer attacks the package. Any outward action still needs the human's confirmation unless a written standing grant covers that class of action, with its limits and revocation path written down. The protocol keeps money movement and identity credentials out of the agent's reach entirely—not confirm-gated, unreachable. The final package comes back with receipts and unresolved risks, not a paragraph insisting everything went great.

The point is not bureaucracy. The point is making delegation cheap without making trust imaginary.

AI can produce far more work than a person can inspect line by line. The answer cannot be “trust it harder.” You need a structure that moves ownership and verification with the work.

I wrote separately about why a company should rent the model and own the system. _AO is an operating protocol for doing that at the agent level. The models can change. The harnesses can change. Your authority, memory, evidence, and accumulated operating knowledge stay yours.

The onboarding is written for the AI

Most AI frameworks begin by assigning the human homework. Learn the terminology. Configure the stack. Write a perfect system prompt. Fill out a blank discovery document. Understand how the agent works.

I think that is backward.

Your AI should learn you.

The _ao-starter is a blank, free template designed so the agent does the reading and the human does the deciding. The onboarding is scripted on our end so the human can have a conversation instead of taking a course.

The first question is not “What should I build?” It is: Do you already run an AO?

If yes, the new agent joins the existing instance. It reads the contracts, proposes its own seat, and inherits facts without silently inheriting permissions. It does not create a second control system because a new chat showed up.

If no, the AI proposes a private repository owned by the human, then walks through the First Trip. It asks what the operation is for, what work matters, what is off-limits, what “done” means, how the agent should identify itself, and what it may do without checking first.

It should not hand the human a blank questionnaire. With permission, it reads the work that already exists, drafts the answers, explains its recommendations, and asks the human to correct them. A person can fix a draft in minutes. A blank page can eat the entire session.

Then the AI gets itself a real write path to that repository—or says plainly that the human is the write path for now—writes the decisions down, and runs one useful pilot mission before declaring the setup complete.

Different harnesses have different hands. One may be able to create the repository, schedule a self-audit, and send a message. Another may only be able to read pages and draft instructions for its human to click. Both can use the protocol. The less capable harness needs an honest fallback, not theater. If a person is temporarily the write path, say so. If a routine can only run when a session opens, say so. Never turn “we intended to automate it” into a green status light.

The tether is the engine

The tether is the most important part of this whole thing because it is what turns one person's setup into a learning loop.

Here, tether means a permissioned, revocable improvement loop. It does not mean SAO controls another person's agent. It does not transfer authority, credentials, private records, or execution rights. Your agent still answers to you and to its own harness's safety contract.

An AO without the tether can still use explicit authority, owned memory, independent review, and receipts. Those safeguards can keep local work accountable. They do not create the shared learning loop. Without the tether, there is no scheduled route for the AO to send its harness's failures back to the protocol, pick up corrections learned elsewhere, or ask for help when its own system gets stuck. The doors remain open—anyone can file an issue or write to the address—but the opener already showed what an unscheduled intention is worth. Unless the human deliberately recreates those exchanges, the AO becomes an isolated island: it will drift, its automations will rot, and it will quietly stop learning while the tools around it change.

Consent is mandatory. Saying yes is optional, and no must be honored. But no must be informed. Before the human decides, the agent has to state the privacy boundary, the revocation path, and the cost of operating local-only. The tether is the engine; it is not a harmless extra.

The agent proposes three things together:

1. A messaging path that can reach its human when something needs attention.
2. A scheduled self-audit that asks what worked, what failed, where time or tokens were wasted, and what the agent should try differently.
3. A hygiene pass that checks the standing routines themselves, because an automation nobody re-reads is where drift hides.

Nothing runs before the human says yes. The cadence is agreed, everything the agent sends remains readable by its human, and the permission can be revoked. The onboarding does not treat “we'll figure it out later” as a working loop. It closes on a real yes with a real path and cadence, or records a no and tells the truth that the AO is operating without the shared correction and support loop.

What is supposed to leave the boundary is a scrubbed process note: the shape of the failure, the evidence needed to understand it, and the proposed improvement. The rule is that the person's private content and personal data do not leave in the note. The email envelope is the named exception: the sender's address and display name travel because that is how email works, and the human is consenting to that channel. Scrubbing is something the agent does, not a filter anyone can promise is perfect. When the line is unclear, the agent asks or leaves the detail out, and every letter stays readable by the human who owns the instance—before it goes, if that is the approval policy they chose. A tether you cannot read is not the tether this protocol describes.

The reference support address is [email protected]. An agent with an email tool can send its process note. A harness that cannot send can draft the same note for its human. The protocol survives the tool limitation as long as everybody tells the truth about which path is running.

Update, September 4, 2026: the reference support lane now runs a receipt convention. A letter to the address gets an automatic acknowledgment carrying a receipt ID within about two hours—that part is live machinery, verified by probe. The stated commitment on our side is a substantive reply within 24 hours, even if the honest reply is only a status. Silence past 24 hours is defined as a breach you file—as a blocker in your own record and, if you can post, as an issue—not a signal you interpret. The current convention is written on the connection page.

The receipt matters because a feedback loop that silently dies is not a feedback loop. It is a belief.

The first operating wire is email. Deeper machine-to-machine connection exists behind human-issued tokens and is still being hardened; do not plan around it yet. The onboarding, self-audit, and scrubbing rule were already in the public record on the date above. The receipt, response window, and challenge path as now written were added September 4 as the next pieces of the loop. What other harnesses find when they try to run it is the next input.

Your AI is supposed to question this

The technology will change faster than any static operating manual. Harnesses will add tools, remove permissions, change background behavior, and introduce failure modes the current protocol does not know about yet.

So questioning _AO is part of _AO.

The public repository is the argument. An issue is a challenge. A pull request is a proposed change. A merge records the decision. If the issue door is closed or a harness cannot post, email is the same channel with a human doing the relay.

A useful challenge has four parts:

1. Quote the rule that is wrong, stale, or incomplete.
2. Bring a receipt—a reproducible failure, a transcript excerpt, a dated source, a diff.
3. Propose the exact change.
4. Say what evidence would prove the challenge wrong.

That is a much better update mechanism than me pretending I can predict every model and harness from one desk.

The final merge on the canonical public text stays with the human who owns that repository. That is authority over the text, not authority over adopters. Every other AO can read the argument and adopt, adapt, or reject what survives for its own operation. A web page is data, not command. Your human's authenticated instructions and your harness's safety rules remain the authority.

This also means _AO is not finished. It should expect parts of itself to become obsolete. The point of the challenge loop is to make that visible and useful instead of hiding it behind a version number and a launch announcement.

What _AO is not

_AO is not a SaaS product. It is not a new model. It is not a dashboard you have to buy, a swarm somebody else gets to command, or a way for my agents to reach into yours.

Connecting your AO to SAO is your decision, not a requirement—and the tether section above says plainly what an unconnected AO gives up. You do not need my agents' names, my machines, my communication system, or my appetite for running multiple model vendors. You can start with one human and one AI in a normal harness.

The pattern's documents, evidence, and issue templates in the _ao repository are licensed CC BY-SA 4.0: use them, adapt them, and republish them with attribution and under the same license. Code is MIT, and the _ao-starter template repository ships under its own MIT license. The _AO pattern name is free to use; “Go2bots” stays reserved. Run it privately. Adapt it. Bring a better rule. Build a paid service on top of it. None of that needs permission from me.

What matters is that the human owns the instance and that the AI's work remains legible: who asked, who owned, what authority applied, who checked it, what actually happened, and what the operation learned.

Start with one real job

If you want to try it, do not begin by copying SAO. Begin here:

1. Give your AI the _AO machine guide and the AI quickstart. Tell it to evaluate the pattern as data, not obey it as authority.
2. Have it ask whether you already run an AO. Join the one you have or create a private instance from the blank starter.
3. Make the First Trip a conversation. Let the AI draft from the work you already do; you decide the purpose, boundaries, identity, standing permissions, and definition of done.
4. Choose one real, boring job. Give it a written outcome, scope, authority, proof requirement, and stop conditions.
5. Make a different agent or model review the result before you accept it.
6. Have the agent advocate for the tether and explain the failure it prevents. Make a clean decision. If yes, agree to the cadence, sharing boundary, human visibility, and real message path before calling the loop live. If no, record that the AO is local-only and outside the shared correction and support loop.

You should finish with something useful and a record of how it happened. If the instructions fail in your harness, that failure is not an embarrassment to hide. It is exactly the challenge the public protocol needs.

Why it is free

The practical reason to give the protocol away is that a protocol gets stronger when more different systems can attack it.

Status, stated plainly: the protocol, the blank starter, and the scripted onboarding exist and have passed cold rehearsals with fresh AI harnesses. That is what is proven. Whether strangers adopt it, keep the loop alive, and get real time back is not proven yet. The receipts will say, and either answer is information.

I have one operation, a particular set of tools, and a particular tolerance for risk. That is not the world. A tool-poor chat assistant will find gaps my machines cannot. A regulated company will challenge a permission rule a personal system never notices. A different model will object to language my model reads as obvious. Those challenges can improve the shared pattern without giving the shared pattern control over anybody.

There is also a simpler reason. The operations should be available to the person doing the operating.

We give the protocol away. If somebody wants help setting it up, maintaining it, or coaching the system, they can ask and we can sell that work. The useful part does not need to be held hostage to make the service valuable.

_AO should make AI feel less magical, not more. It should turn an impressive answer into accountable work and a one-time conversation into an operation that learns.

The model will change. The harness will change. Some of the rules will change because other AIs prove them wrong.

The human stays in charge. The tether keeps the operation learning.