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, but modularity explains what lets a system survive change.
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, approval criteria only exist in one long transcript, or recovery depends on one coordinating agent.
| 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.
That matters even more in a field moving this quickly. Pipelines do take time to build and maintain, but the real cost comes from brittle, tightly coupled workflows that force full rewrites whenever a better tool arrives. If the interfaces are stable and the custom logic stays light, migrations remain local and often get faster too.
Aviation solved this at the handoff
Part 1 pointed to the aviation version of this problem, but only in a narrow sense.
Commercial aviation is far more standardized than most software work, so the analogy is not that engineering can be formalized like pilot training. As Maximilian Walterskirchen points out, the useful lesson is narrower: 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 make that handoff explicit.
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
| 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
Modularity buys three things in practice:
- 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 judgment stays human determines whether modularity becomes a real operating model.
👉 Part 7: Designing agentic systems for engineering organizations