The Agent Coordination Stack Is Fragmenting Into Four Distinct Layers

Four separate tools landed on Hacker News this week, each targeting a different coordination problem for AI agents. Taken together, they reveal that the multi-agent stack is not converging on one framework. It is stratifying into distinct layers, and builders need a mental model for which tool belongs where.

The pattern

Every team running more than one AI agent eventually hits the same wall: agents duplicate work, lose context between sessions, run up inference costs on idle time, and behave unpredictably when handed complex tasks. The instinct is to find a single orchestration layer that fixes everything. What is actually emerging is a four-layer stack, each with its own tradeoffs.

• Shared memory and skills (Rafter)
• Cloud orchestration across models (Open Session)
• Cost-aware scheduling (Scheduled Claude Code agents)
• Systems discipline for agent behavior (ken)

Why now

Back in 2024, most teams ran one agent against one task. By mid-2026, the default architecture is a mesh: specialized agents hand off to each other, pull from shared context, and run on schedules or triggers. That shift exposes coordination overhead that single-agent tooling was never designed to handle. The tools appearing this week are direct responses to pain teams are feeling in production, not research prototypes.

How it works in practice

1. Shared memory layer. Rafter is an MCP server that gives a whole team access to one shared pool of memory, skills, and agents. The problem it solves is concrete: every team member currently re-explains context from Jira, Drive, and OneDrive at the start of every AI session, burning tokens and time. Rafter externalizes that context once so every agent and every teammate draws from the same source. For prompt engineers, this is the context hydration problem solved at the team level rather than the prompt level.

2. Cloud orchestration layer. Open Session is an open-source, self-hostable orchestrator that started as an internal tool at Tella (YC S20) before being released publicly. It runs agents against any model or combination of models and has proven useful across product development, customer support, operations, and data analysis. The self-host option matters for teams with data residency requirements or who want to avoid vendor lock-in on the orchestration layer itself.

3. Cost-aware scheduling layer. The Scheduled Claude Code agents project addresses the most immediate budget concern: agents that sit idle still cost money if they are polling or keeping sessions warm. The pattern here is event-driven or cron-driven invocation so that on a quiet day the bill is effectively zero. This is a deployment pattern more than a framework, but it is one of the highest-leverage changes a team can make.

4. Systems discipline layer. ken applies Thompson-mode systems discipline to agent behavior. The reference is to Ken Thompson's philosophy of minimal, auditable, composable systems. For agents this means enforcing strict boundaries on what an agent can do, making its decision surface inspectable, and preventing the kind of cascading failures that happen when agents have too much autonomy and too little constraint.

The coordination tax on multi-agent systems is now higher than the inference cost for many teams, and tooling is finally catching up.

The trade-off

Fragmentation is the honest cost of this layered approach. Four tools mean four integrations, four failure surfaces, and four communities to track. Teams that adopt all four layers before they have validated their agent architecture will over-engineer early. The counterargument is that picking a monolithic framework that tries to solve all four layers locks you into one vendor's opinions about each, and those opinions are still changing fast.

The shared memory layer (Rafter) and the scheduling layer are the lowest-risk starting points because they sit outside the core orchestration logic and can be added or removed without restructuring the rest of the stack. The systems discipline layer (ken) is the highest-leverage investment for teams whose agents are already in production and behaving unpredictably, but it requires the most upfront design work.

None of these tools have significant production track records outside their own teams yet. Treat them as strong signals about where the stack is heading, not as stable dependencies for critical paths.

Where it goes next

The logical endpoint is a standardized interface between these layers, something analogous to how MCP standardized tool calls. Rafter is already using MCP as its transport, which suggests the memory layer may converge on that protocol. Orchestration layers like Open Session will likely grow plugin interfaces for memory and scheduling rather than building those features natively.

For teams building agents today, the practical move is to instrument each layer separately so you can swap components as the ecosystem matures. Tight coupling between orchestration and memory is the architectural decision you will most regret in twelve months.

The team that wins this space will not build the best single framework. They will build the best glue between layers that other teams have already chosen.