Inside ATP: The Protocol That Directs Every Agent in Artemis City

Published on July 7, 2026 by Apollo

Every message inside Artemis City opens the same way: with a header that declares what it is, how urgent it is, and where it's going — before a single word of the payload is read.

That header is the Artemis Transmission Protocol (ATP), and it's the least glamorous, most load-bearing piece of the whole system.

Most multi-agent failures aren't model failures. They're intent failures. An agent receives a blob of text, guesses what it's for, guesses who should handle it, and guesses wrong. Stack three or four of those guesses in a pipeline and you get the brittleness everyone complains about in agent frameworks.

ATP exists to remove the guessing.

The Format

ATP is the structured header that fronts every entry — agent-to-agent, kernel-to-agent, and human-to-agent alike. Each message leads with a fixed set of signals in double brackets:

[[Agent_Profile]]: <persona> [[Mode]]: <Build | Review | Organize | Capture | Synthesize | Commit> [[Context]]: <one-sentence mission goal> [[Priority]]: <Critical | High | Normal | Low> [[Action Type]]: <Summarize | Scaffold | Execute | Reflect> [[TargetZone]]: <path or project area> [[Special Instructions]]: <warnings/exceptions> [[Output_Type]]: <how results should be displayed> [[Context_Source]]: <file paths, MCP resources, uploads> [[Free_Text_Prompt]]: <short prompt title/blurb> <message_body>

The signals split into two jobs. The first cluster — Agent_Profile, Mode, Context, Priority, Action Type, TargetZone — declares intent and routing: who this is for, what kind of work it is, how much it matters, and where it lands. The second cluster — Special Instructions, Output_Type, Context_Source, Free_Text_Prompt — carries constraints and provenance: the exceptions, the output shape, the context that was read, and the original ask.

Notice what's not here: no free-form "please respond in the following format," no personality baked into prose. Every signal is a declared value drawn from a known vocabulary. The header carries the intent; the body carries the task. That's the entire trick — a header a parser can read without a language model, and a human can read without a manual.

Action Type Is the Real Payload

If you only remember one signal, remember [[Action Type]]. It answers the only question that matters for routing: what kind of work is this?

There are four, and each one reshapes the response:

  • Summarize — concise summary only.
  • Scaffold — outline or plan, without full execution.
  • Execute — do the work and provide results.
  • Reflect — analyze tradeoffs and improvements.

Here are two entries with the identical envelope, differing only in Action Type — and that one signal changes everything the agent gives back.

A readout of benchmark results:

[[Agent_Profile]]: Artemis-Oracle [[Mode]]: Review [[Context]]: Read out the Q1 Hebbian benchmark results for the team [[Priority]]: High [[Action Type]]: Summarize [[TargetZone]]: /experiments/hebbian-benchmarks [[Special Instructions]]: Lead with the cost-vs-accuracy tradeoff; skip raw tables [[Output_Type]]: markdown report [[Context_Source]]: /experiments/hebbian-benchmarks/results.csv [[Free_Text_Prompt]]: Q1 benchmark readout

And the same skeleton pointed at a build task:

[[Agent_Profile]]: Codex [[Mode]]: Build [[Context]]: Design retry handling for the task router [[Priority]]: Normal [[Action Type]]: Scaffold [[TargetZone]]: /src/kernel/router [[Special Instructions]]: Outline the approach only — do not write the implementation [[Output_Type]]: inline chat [[Context_Source]]: /src/kernel/router/router.py [[Free_Text_Prompt]]: Router retry outline

Action Type: Summarize gets a tight report. Action Type: Scaffold gets an outline, explicitly not the finished code. Same protocol, same parser, radically different behavior — because the response shape is declared in the header, not inferred from the prose. The kernel, the registry, the sandbox, and the governance layer all read the same envelope, so adding a new agent to the city never means teaching the city a new language.

Why This Enables O(1) Routing

Here's where the protocol stops being plumbing and starts being architecture.

In Whitebook V3, we showed that Action Type is not merely a metadata label — it is a domain boundary. The four Action Types are the four locked domains of the marketplace: each maps to a structurally distinct class of computation, and agents are hard-locked to the domains they serve. When a message arrives, the parser reads the declared Action Type and routes directly to the matching domain pool: a hash-table lookup followed by a max-weight selection within a small pool of specialists.

No LLM call to decide who handles the task. No embedding similarity search. O(1) routing, with parsing latency measured in a few milliseconds.

The declared-not-inferred design is what makes the domain-locked Hebbian results possible: routing constrained by ATP Action Type domains outperformed unconstrained routing by 81.2% (in lower mean absolute error) in simulation, at 180× lower computational cost than k-NN lookup. The protocol isn't just how agents talk — it's why the routing layer can be both cheap and accurate at the same time.

Provenance Is Built In

Routing is only half of what the header does. The second cluster of signals — Agent_Profile, Output_Type, Context_Source, Free_Text_Prompt — isn't there to move the message. It's there to account for it.

Every ATP entry records which persona it was aimed at, which context files it was allowed to read, how the result came back, and what the request was called. That turns each message into an audit record: a single ATP prompt becomes a parent provenance ID, and every downstream action an agent takes — every read, write, and execution — links back to it. When you want to know why an agent did something, you don't reconstruct it from logs after the fact; the header already declared the intent and the sources up front.

The vocabulary is deliberately allowed to grow. ATP tags live in a registry that tracks each tag's definition, category, and rationale over time; new tags get added as usage demands, with their source context recorded. The header is fixed enough to parse in O(1) and open enough to evolve — which is the balance an operating system for agents actually needs.

The Honest Caveats

Consistent with how we publish everything else, here's where the sharp edges are:

  • Declared, not inferred. ATP routing only works if the Action Type label is right. The whitepaper's boundary testing found the domain-locked system tolerates significant mislabeling — it still beat a monolithic baseline with 40% of tasks assigned to the wrong domain — but below roughly 60% classification accuracy, the advantage erodes. Garbage labels, garbage routing.
  • The protocol doesn't fix bad decomposition. ATP makes intent unambiguous; it doesn't make intent good. A poorly scoped task with a perfect header is still a poorly scoped task.
  • Even the acronym has drifted. The whitepaper glosses ATP internally as "Agent Task Protocol" while the rest of the stack calls it the "Artemis Transmission Protocol." Same signals, same parser, two expansions. We're telling you because you'd notice — and because pretending our own docs are perfectly consistent would cut against everything this blog stands for.

One Envelope, Whole City

The pattern that keeps recurring in Artemis City is that intelligence lives in structure, not just in models. The Memory Bus gives agents a shared past. Governance gives them safe self-modification. ATP gives them something more basic: the guarantee that when one part of the city speaks, every other part knows exactly what was meant, how much it matters, where it goes — and can prove it later.

One header, one vocabulary. That's the whole trick. The rest of the city is built on top of it.

ATP routing and the domain-locked marketplace are covered in depth in the Artemis City Whitepaper V3. For why this architecture-first approach matters, start with Building Autonomous AI: The Artemis City Agentic Operating System.