Long-lived systems need modularity
This article is part of a series on agentic systems:
- Agentic systems are struggling to scale (this should feel familiar)
- Agentic systems are still in the artisanal era
- Agentic systems are bound by the same fundamental limits
- Artifacts are compression: how systems handle complexity
- Why all systems become pipelines
- Long-lived systems need modularity 👈
- Designing agentic systems for engineering organizations
- Writing this series with AI: a postmortem
Pipelines explain how complex work moves. They do not explain what lets a system survive change.
That is what modularity is for.
Long-lived systems need modularity because tools change, models change, teams change, and workflows still have to keep working.
You cannot modularize what is not already structured.
If the stages, handoffs, and responsibilities are still ambiguous, there is nothing stable to make replaceable.
Modularity is survivability
A pipeline can be clear and still be fragile.
If planning logic lives in one operator’s head, if approval criteria only exist in one long transcript, or if recovery depends on one coordinating agent, the workflow cannot absorb change.
| Without modularity | With modularity |
|---|---|
| Changing one tool destabilizes the whole workflow | Components can change behind stable interfaces |
| Knowledge is trapped in one actor or session | Knowledge is carried in explicit handoffs |
| Failures spread across the system | Blast radius stays local |
Bus-factor problems are really design problems. The risk is not merely that someone leaves. The risk is that the workflow was never encoded in a form the rest of the system could reuse.
Good boundaries localize change
Good modularity means small, substitutable parts with a clean separation between interface and implementation.
The key question is not whether the boxes are large or small. It is whether change stays local.
A good boundary lets you replace one part without forcing the rest of the system to rediscover intent, state, or operating rules. A bad boundary only redraws the diagram while the real coupling remains hidden underneath.
Aviation solved this at the handoff
Part 1 pointed to the aviation version of this problem.
As Maximilian Walterskirchen points out, autopilot did not remove pilots from the system. It changed the interface between automation, procedure, and human takeover. Aviation became safer because the system learned to formalize when automation should lead, when humans should re-enter, and how that handoff should happen.
Long-lived agentic systems need the same discipline. When a model changes, a tool fails, or a task falls outside the expected path, the workflow needs a stable takeover point rather than a hidden dependency on one giant prompt.
Real systems already optimize for replaceable interfaces
The most useful current examples are not theoretical.
| System example | Stable interface |
|---|---|
| GitHub Copilot cloud agent | Plan, branch diff, checks, and pull request are explicit handoff objects 2 |
| Microsoft agent orchestration guidance | Typed payloads, persisted state, evaluator loops, and human approvals keep stages replaceable 4 |
| OpenAI’s agent guidance | Start single-agent, then add specialization only when the task shape actually demands a new boundary 5 |
These systems do not scale by hiding more state inside the model. They scale by making interfaces explicit enough that one stage can evolve without collapsing the others.
What modularity buys you
In practice, modularity buys three things.
- Replaceability: one evaluator, planner, or model can change without rewriting the whole workflow.
- Evolvability: the system can adopt better tools gradually instead of through all-or-nothing rewrites.
- Long-term stability: humans can still inspect, resume, and correct the workflow because the state lives in artifacts and contracts.
Automation makes modularity more valuable, not less.
The final design question
Once the boundaries are clear enough to survive change, the remaining problem is organizational.
Who plans, who executes, who checks, and where should judgment stay human? That is the last step in the argument, because modularity only matters if it can be turned into a real operating model.
👉 Part 7: Designing agentic systems for engineering organizations