Multi-agent in TypeScript is engineering-hard. Context propagation between agents, routing quality across providers, observability inside LLM-drive...
For further actions, you may consider blocking this person and/or reporting abuse
This is hands-down one of the most rigorous, high-signal post-mortems on multi-agent architecture I've read in a while. Pulling the actual GitHub issue receipts to trace the erosion of the mesh network pattern into a hierarchical supervisor tree is brilliant.
Wall 1 (Memory context corruption) and Wall 5 (Performance/Token collapse) are the two massive ghosts haunting enterprise agent development right now. When frameworks try to treat the entire conversation loop as fluid, ambient context, they inevitably run into what I call the "Prose Tax"—where sub-agents are forced to repeatedly ingest and burn high-compute tokens just to parse through conversational noise, markdown fragments, and duplicate state histories.
Your breakdown perfectly illustrates why we have to move away from letting agents handle raw, unchecked context propagation. We have to treat agent payloads as untrusted telemetry at the ingestion boundary, sieving out conversational noise and signing a deterministic state schema before it ever passes to a supervisor or worker runtime.
Absolute masterclass of an article. Saving this as a core reference text.
The "Prose Tax" name makes the cost concrete. Mastra's year was basically a paid lesson that letting agents negotiate state through prose burns tokens without compounding capability.
Treating payloads as untrusted telemetry at the boundary is the right primitive. OMA's typed Goal→Result + separate SharedMemory layer was the same bet from a different angle: once the contract is explicit, supervisors stop re-litigating what's already done.
"Letting agents negotiate state through prose burns tokens without compounding capability"—that belongs on a t-shirt, Jack. That is the exact trap of Ambient Context Fluidity.
Your mention of OMA’s typed
Goal → Resultstructure is spot on. It proves that the laws of distributed systems don't change just because we throw a neural network in the middle. The moment you move away from explicit contracts, the supervisor agent is forced to constantly re-litigate past actions, burning compute just to establish basic orientation.Shifting that
Goal → Resultmechanic to an automated, cryptographically sealed Forensic Receipt at the local boundary is exactly what I've been coding out this week. It locks down the contract so the orchestrator can step out of the parsing business entirely.This thread has been an absolute goldmine. Thanks for the phenomenal historical context.
"Forensic Receipt" makes the cost asymmetry obvious. Once the contract is sealed at the boundary, the supervisor stops paying compute to reconstruct trust on every hop, and the gain compounds with agent count.
Drop a link when the schema is public. Want to see how you handle revocation and replay.
Jack;
The announcement post is live for the Python SDK. The open source Sovereign Systems Specification has also been announced this week.
Take a look, let me know what you think, give the associated repos a "star", offer suggestions, or make a pull request.
The spec going live means I finally get to see how you handled revocation and replay, the part I was most curious about. Separately, that "Prose Tax" line stuck and made it into a post I just put out, in the section on what goal-first orchestration actually costs you. Credited you there: dev.to/jackchenme/goal-driven-agen...
The trailing whitespace breaking Bedrock Claude routing (#13621) is the most diagnostic example in this whole post — it's a single character exposing the entire brittleness of LLM-driven routing as a paradigm. You can't unit-test your way out of that. The observation about "blogs are written for press, issues are real" is worth framing as a research methodology — the GitHub issue tracker as ground truth for production hardness is underused by people trying to evaluate frameworks. Bookmarking this as required reading before picking any agent framework.
The compression bit is what I keep thinking about: maintainers write blog posts to compress complexity ("we now support X!"), issues preserve it ("X, but only when Y and Z"). Doing similar archaeology on my own repo (open-multi-agent). If you've seen frameworks with especially wide docs-vs-tracker gaps, would want to hear.