The engineers who will build reliable agent systems aren’t the ones who know the most about the latest LLM tools. They’re the ones who were already good at breaking systems to components and components to classes correctly.
The skill is the same
Every few years, a new architectural paradigm arrives. Each time, the industry treats it as a reset — new tools, new frameworks, new job titles. And each time, the engineers who adapt fastest are not the ones who studied the new paradigm the hardest. They’re the ones who already understood where to draw boundaries.
Agent engineering is no different.
Looking back: the lineage
Consider what we’ve asked engineers to decompose over the last three decades:
Functions → classes → components → services → microservices → rulesets and applications → agents and skills
Each transition introduced new vocabulary. Each one rewarded the same underlying capability: the ability to identify a clean boundary, define a clear interface, and resist the temptation to put too much in one place.
The tools changed with every generation. The thinking didn’t.
What’s different now is the speed of change. LLM-specific knowledge — which model handles which task best, which framework has the best agent loop, which vector store performs at scale — is depreciating faster than any previous generation of tool knowledge. Teams that invested heavily in deep expertise on a specific framework two years ago are already rebuilding on something else.
Decomposition thinking doesn’t depreciate. It compounds. An engineer who understands why a microservice should own exactly one bounded context will understand, almost immediately, why an agent should own exactly one trust boundary.
Looking forward: where it goes wrong
The failure modes of bad agent decomposition are not new. They’re the same failures we’ve seen in every previous generation — just with a new attack surface added on top.
Mechanics: the invisible mistake
Most decomposition mistakes aren’t dramatic. They don’t surface in the first sprint, or the second. They become visible when the system grows.
Here’s a concrete example. When working with AI-assisted development tools, you face an early design decision: how do you teach the agent about your codebase? Five options present themselves:
- A skill called “understand the codebase” — describes the project structure, key files, and conventions. Sounds useful. But there is no trigger and no action attached to it. A skill with no invocation condition is documentation that never gets read.
- A skill called “find the right file to implement the feature” — same project knowledge, but with a clear invocation trigger. Works, but every time this skill fires, it loads structural information into the main agent’s context — information that is only needed at planning time, not throughout the entire conversation.
- A subagent dedicated to planning — same project knowledge, but runs in an isolated context. Works, but duplicates the effort: you now maintain both a skill and a subagent doing essentially the same job.
- A planning subagent that uses the project skill directly. The main agent stays lean. Planning runs in an isolated, scoped context. The skill teaches the subagent your codebase; the main agent delegates and moves on.
- A generic skill that instructs the main agent to invoke the planning subagent — adding one more layer of indirection on top of option 4.
Option 4 is the most optimal, although it may be overkill for a small repository. The reasoning matters more than the specific choice: keep the main agent lean, scope knowledge to where it is actually needed, and separate planning from execution. This is single responsibility, applied one layer up.
The Pega angle is worth noting here. Pega Infinity 26 already exposes the rulebase via MCP automatically — so the repository layer is handled. But the question of how you teach your AI assistant your team’s own best practices, conventions, and architectural decisions is exactly the same design problem as above. The MCP connection gives the agent access to the rules. It doesn’t give it judgment about how your team uses them. That still requires deliberate decomposition — a scoped skill, owned by the team, maintained like any other engineering asset.
Maintenance: the god agent
The god class was a well-understood anti-pattern before most current engineers started their careers. One class that knew too much, did too much, and was referenced by everything. Nobody wanted to touch it because changing anything broke something else.
The god agent is the same problem.
A single agent wired into five different business processes, handling every action in the system, accumulates the same structural debt. A prompt adjustment to fix behavior in one process surfaces as a regression in another — one that only appears in UAT three weeks later. The testing surface is proportional to the number of processes that depend on the agent, not to the complexity of the change.
The correct design extracts shared behavior into well-scoped skills with explicit interfaces and composes them into process-specific agents that own their own context. Changes stay local. Testing stays tractable.
Security: the consequence you can’t patch your way out of
Bad decomposition doesn’t only create maintenance debt. It creates attack surface.
An agent that receives external input — from customers, partners, or any untrusted source — and also holds broad tool access is a prompt injection risk by design. The blast radius of a successful injection scales directly with the tool surface available to that agent. If it can write to persistent state, trigger case actions, and call external APIs, a single malicious input can chain across all three.
The mitigation is not a guardrail bolted on later. The mitigation is a trust boundary drawn at design time — separating the agent that handles external input from the agent that executes consequential actions. This is the same principle as not exposing your database directly to the internet. The solution is architecture, not patching.
Organisations that have done this decomposition correctly don’t spend engineering cycles on prompt injection defences for their core operational agents. The attack surface was never created.
The implication: what to learn and who to hire
For engineers: the investment that compounds here is not in learning the current generation of agent frameworks. It’s in deepening system design fundamentals — bounded contexts, trust boundaries, single responsibility, interface design. Those skills transfer across every paradigm shift that’s coming, including the ones we haven’t named yet.
For engineering leads and CTOs: when you’re building an agent engineering capability, the screening question is not “have you worked with LangGraph or CrewAI.” It’s “walk me through how you would decompose this problem.” That answer tells you whether you’re hiring someone who will build something maintainable — or someone who will build something that works until it doesn’t.
The engineers who were good at microservice decomposition are, with some nuance learning, good at agent decomposition. The ones who weren’t, aren’t.
That pattern is consistent enough to be a hiring signal.
Agents introduce new vocabulary, new frameworks, and new failure modes. But the core design problem — where to draw the boundary — is one engineers have been solving for decades. I haven’t seen a convincing argument that this time it’s fundamentally different. Have you?