Zero-Read Orchestration Protocol: A complementary approach to agent orchestration

[neoncapy]

This repo has a well-designed multi-agent orchestration system. I wanted to share a complementary protocol that focuses specifically on context window management during orchestration.

claude-code-orchestration-protocol

https://github.com/orangefineblue/claude-code-orchestration-protocol

The core insight: the orchestrator session should be a router, not a thinker. It should never read source files or reason about content — only about pipeline design (which agents, what order, what files).

Key patterns

• 100-line hard limit: Orchestrator never reads anything over 100 lines
• Agent output protocol: Every agent writes ## Summary above ---. Orchestrator reads only above the line
• Anti-polling: Never call TaskOutput on running agents (each poll dumps 50-150K tokens into orchestrator context)
• QC loops: Run until genuinely zero issues at all severity levels
• 5-tier token budget: GREEN → GREEN+ → YELLOW → ORANGE → RED with specific actions at each tier
• Handover-first: Write full plan with agent prompts to disk before launching any agent

The protocol was developed over months of real production use and is implemented as a single /orchestrate slash command.

Would be curious how this compares to the orchestration patterns in this repo. MIT licensed.

[aniruddhaadak80]

The token-budget framing is one of the strongest parts of this proposal because it turns context management into something operational instead of hand-wavy. I especially like that the tiers force the system to acknowledge scarcity before it collapses into unreadable prompt growth.

What I would be curious about is how the protocol behaves when an agent misjudges the remaining budget and keeps trying to push work forward. If that failure mode is handled cleanly, the design gets much more credible for long-running orchestration.

[Nyrok]

The "orchestrator reads only above the line" pattern is clean. It works because you have a defined contract: agents produce a specific structure, orchestrators consume a specific region. That separation makes the system predictable.

The same principle applies one layer down at the prompt level. If the prompt going into each agent is also structured (typed blocks: role, objective, constraints, output format) rather than freeform prose, each agent has explicit instructions it cannot misinterpret, and you can inspect or patch individual blocks without touching the rest.

I have been building flompt (github.com/Nyrok/flompt) around that idea: a visual canvas to decompose prompts into 12 typed blocks and compile to Claude-optimized XML. The structured output contract you describe at the orchestration layer mirrors what structured input does at the prompt layer.