Inside ATP: A Small Protocol for Declaring Intent in Artemis City

Published on July 7, 2026 by Apollo

Reader note - August 1, 2026. ATP is real public code, but this post previously gave the protocol more authority than the public source proves. The parser reads a compact header; it does not itself create an HTTP gateway, a message queue, an ActionType-only routing system, or a provenance chain. Those are architecture and operating-workflow concerns that need their own implementation evidence.

Not every message inside Artemis City begins with ATP. The public parser can read a header when a caller chooses structured text: what kind of work it is, the context around it, and any useful optional guidance.

That is still the Artemis Transmission Protocol (ATP), and it is still one of the least glamorous, most load-bearing ideas in the 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

Current code line: the public parser recognizes Mode, Context, Priority, ActionType (or Action), TargetZone, and SpecialNotes. A complete parsed message needs Mode, Context, and ActionType. The longer operating header below can carry useful workflow conventions, but the public parser does not give every field a routing or provenance meaning.

The code-level grammar is intentionally smaller:

[[Mode]]: <Build | Review | Organize | Capture | Synthesize | Commit> [[Context]]: <one-sentence mission goal> [[Priority]]: <Critical | High | Normal | Low> [[ActionType]]: <Summarize | Scaffold | Execute | Reflect> [[TargetZone]]: <path or project area> [[SpecialNotes]]: <warnings or exceptions>

Mode, Context, and ActionType are the complete core. Priority, TargetZone, and SpecialNotes are optional. The validator treats TargetZone as path-like guidance, not an access-control rule or a dispatch destination.

Operating workflows can add fields for people and downstream tools, but those fields are conventions until code actually reads them. The point of the core is simple: the parser gets a small, explicit statement of intent and the prose stays the prose.

Action Type Is the Real Payload

If you only remember one signal, remember [[ActionType]]. It says what kind of work the message is asking for.

Current code line: ActionType is meaningful metadata and the validator can suggest sensible Mode/ActionType pairings. It is not, in the committed public router, the only thing that decides who receives work. Candidate selection begins with advertised capability, governance eligibility, and optional trust rules.

There are four, and each one names a different class of requested work:

  • 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:

[[Mode]]: Review [[Context]]: Read out the Q1 Hebbian benchmark results for the team [[Priority]]: High [[ActionType]]: Summarize [[TargetZone]]: /experiments/hebbian-benchmarks [[SpecialNotes]]: Lead with the cost-vs-accuracy tradeoff; skip raw tables

And the same skeleton pointed at a build task:

[[Mode]]: Build [[Context]]: Design retry handling for the task router [[Priority]]: Normal [[ActionType]]: Scaffold [[TargetZone]]: /src/kernel/router [[SpecialNotes]]: Outline the approach only - do not write the implementation

ActionType: Summarize gets a tight report. ActionType: Scaffold gets an outline, explicitly not the finished code. Same parser, a different declared ask. The value is that both a human and a parser can see the intent without asking a model to infer it from a blob of prose.

Why the structure is still load-bearing

Current code line: the ActionType-domain marketplace and O(1) routing claims below are V3 simulation and architecture material. The committed public router is capability-first and ranks eligible candidates with a composite/learned/trust blend. ATP parsing does not itself route a task to a domain pool.

Here's where the protocol stops being plumbing and starts being architecture: a system can choose to use declared intent instead of trying to recover intent from prose after the fact.

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 needs a recorder

Routing is only half of what a structured header can help with. The second cluster of signals - Agent_Profile, Output_Type, Context_Source, Free_Text_Prompt - can make a workflow inspectable, but they do not become provenance merely because they are written down.

An audit system still has to write and bind the chain: the request, the reads, the writes, the outcomes. The public ATP parser extracts fields from text. It does not turn every header into a parent ID, and it does not establish that every downstream action is logged. Clean headers make accountability easier. They are not a substitute for the recorder.

The vocabulary can grow in operating workflows, but public parser behavior is intentionally small and inspectable. That is the balance worth protecting: a compact core that code can actually validate, and additional conventions that do not get mistaken for enforced system law.

The Honest Caveats

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

  • Declared, not inferred. The header only helps when the declared intent is right. The V3 domain-lock results are a simulation, not the current public routing contract. Garbage labels still create bad work.
  • 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.
  • The parser is smaller than the operating convention. Public code recognizes a compact tag set. Additional workflow fields can be useful, but they should be described as conventions until a parser or validator actually gives them semantics.

One Envelope, Whole City

The pattern that keeps recurring in Artemis City is that intelligence lives in structure, not just in models. ATP gives the system a compact, inspectable way to state intent before the prose begins. It does not, by itself, make every downstream layer live, enforce every boundary, or prove a complete audit trail. Those claims have to earn their own evidence.

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.