Two axes for scaling capability past one agent's turn.
Both axes aim at the same outcome, more capable work from a language model, and pull on different variables to get there.
| Axis | What scales |
|---|---|
| vertical scaling | Capability grows by making a single agent's turn more capable: a larger model, a longer context window, more compute spent per call. The unit that grows is one agent's own turn. |
| horizontal scaling | Capability grows by coordinating more agents, each operating in a smaller context, through state that persists and is shared outside any single agent's window. The unit that grows is the population working the problem, not the size of any one member's turn. |
Bigger models, longer windows, more compute per turn.
The current default path to more capable AI work is vertical: larger models, context windows extended into the millions of tokens, and more compute spent evaluating each call. Visible artifacts of this pattern include vendors advertising multi-million-token windows, usage reports that describe a large share of sessions running at very high context lengths, and weekly rate limits functioning as the mechanism that rations an increasingly expensive resource.
None of this is a flaw in the pattern. A larger window is a real improvement for the tasks it suits, and a more capable model helps on essentially every task. The pattern has a scope, though: it scales what a single agent's own turn can hold and process, and that scope does not automatically extend to work that spans several agents or several sessions.
Coordinating many small-context agents through shared state.
The alternate axis described here scales capability by coordinating a population of agents rather than by growing any one of them. Each agent keeps a comparatively small working context; coordination happens through a structure, entries and the typed links between them, that persists and is shared outside any individual agent's window, rather than through one agent holding the full state of the work in its own context.
Under this axis, adding capacity means adding agents that read and write the same shared structure, each at roughly constant per-agent context cost, rather than enlarging the context any single agent must carry. Production examples of agents coordinating this way, including cross-session and cross-agent cases where no single context held the full picture, are catalogued alongside the direct window-size comparison in vs. a bigger context window.
One boundary, three timescales.
The reason a larger window does not substitute for coordination is structural rather than a matter of degree. A workflow runtime that fans work out to several subagents can generate reasoning, combined across those subagents, that runs well past what any single context window holds. That reasoning cannot be admitted into one orchestrating agent's context regardless of how large that context is, because doing so would bury the orchestrator's attention under material it has no way to prioritize. A runtime built this way keeps the intermediate reasoning outside the orchestrator's window and returns only a converged result, discarding most of what was produced to reach it.
The same shape recurs at three timescales, each bounded by something a wider window does not move:
| Timescale | The boundary a larger window doesn't move |
|---|---|
| within one turn | A context window bounds what a single call can attend to at once. A larger window raises that bound for the session currently open, and only for that session. |
| within one workflow | An orchestrating agent fanning work out to several subagents can accumulate far more combined reasoning than fits inside its own context. That reasoning has nowhere to go inside the orchestrator's window regardless of the window's size, so the reasoning is kept outside it and only a converged result returns. |
| across a project | A new session begins without the decisions an earlier session reached, independent of how large its window is. Nothing about window size carries yesterday's state into a session opened today. |
A wider context window reaches only the first row, and only for the session currently open. Coordinating agents through a structure that persists outside any one of their contexts addresses all three, because the structure is the write target the reasoning at every timescale needs and a single agent's context cannot supply on its own.
This shape shows up outside Vinculum, too.
Anthropic has published its own account of building a multi-agent research system along similar lines: work is distributed to subagents with narrower, deeper scope rather than grown inside one context, and most of what those subagents produce is discarded at the runtime boundary, with only a synthesized result returned to the orchestrating agent. The account also describes a failure mode on the horizontal side: passing every subagent's raw output directly to its peers reintroduces the same context load the split was meant to avoid, so what crosses between agents has to be compressed rather than forwarded whole.
Separate academic work on heterogeneous multi-agent language-model systems proposes structured contextual memory as the coordination layer between agents, arguing for the same shape from outside any single vendor's implementation: an external, structured store that agents read from and write to, rather than each agent's own context growing to hold what the group collectively knows.
Common questions.
Does this argue against larger context windows?
No. Larger context windows are a genuine improvement for single-session work. The distinction concerns what happens once a session ends and what happens when the combined reasoning of several agents exceeds what any one context can hold, both boundaries a single window’s size does not reach.
Is horizontal coordination just another name for multi-agent systems?
Not exactly. Several agents can still be organized around one large orchestrating context that every subagent reports back into, an arrangement that scales vertically even with many workers attached to it. Horizontal coordination specifically describes scaling through agents that each keep a small context and coordinate through state that persists outside all of them.
Where does the distinction come from?
The vertical/horizontal framing is drawn by the Vinculum project to describe the architectural choice behind its own design. It is not an established industry term with one canonical definition elsewhere; the underlying observation, that coordinating several agents needs a write target outside any single context, appears in the wider literature under other names, including structured contextual memory for multi-agent systems.
How does this relate to prompt caching?
Caching lowers the cost of re-reading the same context within one session, but the cached content is still lost once that session’s cache entry expires. The cost side of that comparison is covered in the cost of keeping the thinking; this entry is about the coordination and persistence problem caching alone does not solve.