Overview of concept architecture
The Multi-Agent Systems
The most interesting feature of current agent ecosystems that should be explored is do your agents actually understand each other, or do they simply just share a corpus? They look like they do. Two agents pass JSON back and forth, one generates a plan, the other executes it, and the output lands in your inbox looking polished and intentional. But under the hood? It’s barely-controlled chaos. The planner agent didn’t tell the executor why it chose that approach. The executor didn’t confirm it understood the constraints. And when something breaks at 3 AM in production, there’s no record of the conversation that led to the failure. Writing a new prompt for each agent to understand their role and maintaining Agent cards becomes tedious. How do you maintain prompt intent across context windows and Agents without human overload.
These are some of the problem we set out to solve when we built the Agentic Transmission Protocol ATP as the backbone of Artemis City’s multi-agent orchestration platform. This protocol first applied to prompts directed at Artemis directly and through testing discovered it can be used across various agents and hence the acronym is dual serving. And after months of building, breaking, and rebuilding agent communication systems, we’re ready to make our case: every serious multi-agent system needs a transmission protocol, and here’s how to approach building one.
What Even Is a “Transmission Protocol” for Agents?
If you’ve ever worked with HTTP, gRPC, or even MQTT, you already understand the concept. A transmission protocol defines how messages are structured, routed, and interpreted between communicating parties. For web servers, that’s straightforward request/response pairs with headers, status codes, and payloads. For AI agents, it’s dramatically more complex and is hindered by conflicts in translation vs transliteration, also rendering, reading, and printing. These may seem like unrelated aspects but are the main points of lossy noise, and opens door for complex acttack vectors aided by AI. Agents aren’t stateless web servers. They carry context. They make judgment calls. They interpret ambiguity. And crucially, they operate in environments where the “right answer” depends on who’s asking, what they already know, and what they’re trying to accomplish. Without a structured communication layer, you get what we call semantic drift the gradual divergence between what one agent meant* and what another agent understood. ATP solves this by wrapping every agent-to-agent communication in a structured envelope that carries not just the message, but the intent, context, priority, and expected response type alongside it. The envelope is meant to grow along with the need of the domain it is applied.
The Foundational Signals
The core of ATP is deceptively simple: six signal tags that travel with every message between agents. These aren’t optional metadata they’re mandatory headers that define the communication contract.
#Mode defines the overall intent of the transmission. Is this a Build operation where code needs to be written?
A Review where existing work needs critique?
An Organize pass where the knowledge base is being restructured?
A Capture where raw thoughts are being logged?
A Synthesize where multiple inputs need to be merged?
Or a
Commit where finalized work is being saved?
The mode tells the receiving agent how to think not just what to do.
#Context anchors the transmission to a specific mission or goal. This isn’t a full project description it’s a one-line compass heading. “Initial CLI Trigger Script.” “Q3 Compliance Audit Trail.” “User onboarding flow redesign.”
It keeps every agent oriented toward the same north star, even when they’re operating asynchronously and independently.
#Priority signals urgency. Critical means drop everything. High means prioritize over default work. Normal is standard queue processing. Low means handle when idle. This is essential for production systems where not every task has equal weight, and where an agent burning tokens on a low-priority research task while a critical deployment is stalled is a real failure mode. This extends to which agent you allow to attempt this task. Through domain specialization agents will dominate specific portions of task, information retrieval needs may vary.
#ActionType specifies what kind of response the sender expects. Summarize means compress and distill. Scaffold means create a structural foundation. Execute means build the thing. Reflect means analyze what happened and provide insight. This tag prevents one of the most common failures in agent systems: the agent that was asked to “look into authentication options” and returns a 50-page implementation instead of a three-paragraph summary. A workflow can straddle multiple actiontypes and agents, this field is most valuable when used with a central orchestrator. The Mode is the overall output, the actiontype is what is expected of recieving agent. A build step could involve large reasearch that should be summarized and contextualized with database, summarized to match the Mode.
#TargetZone maps the transmission to a physical location in the project architecture or workflow output location, reduces the data crawl scope. This does two things: it scopes the agent’s attention to the relevant part of the codebase, and it provides an auditable record of where changes are being directed. When you’re running dozens of agents across a monorepo, this isn’t optional it’s the difference between your compiled code running and three repo that now uses UV, pipenv, Yarn, NPM in the same src/ calls.
#SpecialNotes is the escape hatch. “Must be compatible with Git safe-commit checks.” “Do not modify the .env file.” “This is a dry run no actual writes.” Every edge case, every exception, every “by the way” lands here.
And critically, it’s a formal field, not a casual aside buried in a prompt. Agents parse it. Governance systems log it. Nothing gets lost in the noise.
How Artemis City Routes Tasks
In Artemis City, ATP isn’t just a nice-to-have formatting standard it’s the language the kernel speaks.
When a task enters the system, the kernel’s ATPParser module reads the signal tags and makes routing decisions in real time. Here’s what that looks like in practice:
A user submits a task: “Build a Python trigger that allows Codex to repackage files after a push event.”
The kernel wraps this in an ATP envelope:
Simplified Kernel use
Mode: Build
#Context: Initial Codex CLI Trigger Script
#Priority: High
#ActionType: Scaffold
#TargetZone: /Projects/Codex_Experiments/scripts/
#SpecialNotes: Must be compatible with Git safe-commit checks.
Now the kernel’s router has everything it needs.
#Mode: Build combined with #ActionType: Scaffold tells it this is a code-generation task that needs structural output first, not a finished product. The router queries the Agent Registry, finds agents with code_generation and python capabilities, selects the highest-scoring candidate (based on composite trust scores weighing alignment, accuracy, and efficiency), and dispatches the task.
The selected agent receives the ATP envelope, and now it knows exactly what to do: scaffold a Python trigger script, scope it to the Codex Experiments directory, ensure Git compatibility, and treat this as high-priority work. No guessing. No prompt engineering hacks. No “let me think about what you might have meant.”
The entire routing decision from ATP parsing to agent selection to dispatch takes approximately 7 milliseconds. Compare that to the 800ms+ you’d spend asking an LLM to read agent profiles and pick the right one. That’s a 99% latency reduction, and it’s fully deterministic. Same input, same routing, every single time.
What the current AI Discussions are Missing
Let’s be direct about what the current agent ecosystem looks like without something like ATP.
In most frameworks agents communicate through one of two mechanisms: function call chaining (where outputs from one agent become inputs to another through code-level plumbing) or prompt injection (where one agent’s output is literally pasted into another agent’s context window).
Both approaches have the same fundamental problem: they carry data without carrying intent.
When Agent A passes a 2,000-token output to Agent B, Agent B has to infer everything about that message. What was the goal? What constraints apply? How urgent is this? What kind of response is expected? Agent B has no structured way to know so it guesses. And LLMs, as we all know, are confidently wrong guessers. This is why you see the classic multi-agent failure pattern: agents that spiral into infinite loops, agents that solve the wrong problem with beautiful precision, agents that ignore critical constraints because they weren’t formatted in a way the model could parse reliably.
ATP eliminates inference at the communication layer. Every message arrives with its own instruction set. The receiving agent doesn’t guess it reads the contract and responds accordingly
The Deeper Architecture: Symmetric Tags and Fault Awareness
ATP doesn’t just handle the initial dispatch. It governs the entire conversation lifecycle.
Every outbound ATP tag expects a corresponding acknowledgment. When an agent sends a #Mode: Build message, the receiving agent must respond with a #Mode_Ack: Build to confirm it understood the operating mode. When a #Context tag is set, the response carries a #Context_Ref back-link. This symmetric tagging creates a verifiable handshake both sides of the conversation are on record confirming alignment.
But the real innovation is in fault awareness. If an agent receives a message with a tag it doesn’t recognize, or a #TargetZone that doesn’t exist in the current project structure, it doesn’t guess or hallucinate an interpretation. Instead, it emits a structured warning:
Intersect_Warning: Tag not mapped in ATP.
Request human arbitration or memory recall.
This is the difference between a communication protocol and a prayer. In traditional agent frameworks, an unrecognized instruction gets absorbed into the context window and the model does its best which often means doing something confidently incorrect. In ATP, ambiguity triggers an explicit interrupt. The system stops, flags the issue, and waits for resolution. No silent failures. No confident hallucinations.
Hash-Based Context Linking: Memory Across Conversations
One of ATP’s most powerful features is its hash-based context linking system. Every ATP message block receives a unique context hash a short identifier like ctx_4df3a that tags the semantic content of that exchange. When another agent references the same context later (even in a different session, or days later), it uses reply_ctx_4df3a to create an explicit link.
This means agents can reference the same context across disconnected threads, sessions, and even different model instances. It’s the difference between an agent that says “I remember building that feature” (and is hallucinating) and one that says “I’m referencing context ctx_4df3a from the 2026–02–10 session” (and can prove it).
In Artemis City, these context hashes are stored in the Memory Bus and indexed in both the Obsidian knowledge vault and the Supabase vector store. They’re searchable, auditable, and decay-aware meaning the system knows not just what was said, but when it was said and how reliable it still is.
Why This Matters Beyond Artemis City
ATP was designed for Artemis City, but the problems it solves are universal.
If you’re building any multi-agent system whether it’s a coding assistant, an enterprise workflow engine, a research pipeline, or an AI-driven operations platform you will eventually hit the wall of unstructured agent communication. Your agents will miscommunicate. They’ll lose context. They’ll make decisions without explaining why. And when you try to debug what happened, you’ll find a pile of JSON blobs and prompt logs that tell you what each agent did but not why.
ATP provides the “why” layer. It’s the structured intent metadata that turns agent communication from a best-effort guess into a verifiable contract.
The design principles transfer directly:
Define modes, not just messages. Don’t just tell agents what to do tell them how to think about what they’re doing. A build task and a review task require fundamentally different reasoning approaches, even if the subject matter is identical.
Carry context explicitly. Never rely on an LLM to infer the project goal from the content of the message. State it. Tag it. Make it mandatory.
Demand acknowledgment. Symmetric tags aren’t bureaucracy they’re verification. If the receiving agent can’t confirm it understood the instruction, you’ve caught a failure before it becomes a production incident.
Interrupt on ambiguity. The most dangerous thing an agent can do is confidently proceed when it doesn’t fully understand the task. Build fault awareness into the protocol layer, not the model layer.
Type caption for image (optional)
The Road Ahead
ATP v0.3 is live in Artemis City today, and we’re already working on the next evolution. Future versions will introduce specialized modes like #Mode: VoiceReflect for speech-captured inputs that need different parsing. We’re exploring weighted priority systems where the kernel can dynamically adjust task urgency based on system load and deadline proximity. And we’re building cross-instance ATP the ability for separate Artemis City deployments to communicate through the same protocol, creating a federation of governed agent systems.
But the core philosophy won’t change: agents need structure to communicate reliably, and that structure needs to be explicit, mandatory, and verifiable.
The era of agents passing unstructured prompts back and forth and hoping for the best is over. If you’re building production-grade multi-agent systems, you need a transmission protocol. ATP is ours. Build yours. Or better yet help us build the standard that the entire ecosystem can share.
Top comments (0)