Why your next LLM module is worth less than a clean boundary
The hottest new AI architecture pattern often turns out to be a router you already knew how to draw. ⚡
Change the labels on a modern agent diagram and the picture becomes familiar: prompt chains look like Pipes and Filters, router agents look like Content-Based Routers, RAG looks like a Content Enricher with a vector index, and orchestrator-worker systems look like Process Manager plus Scatter-Gather. The strange part is how quickly teams forget the old lessons when the box in the middle says “LLM”.
That is the uncomfortable thesis: AI changes economics, interfaces, and failure modes, but many architectural forces are old. Boundaries still matter. Contracts still matter. Messages, workflows, validation, observability, coupling, cohesion, and business capability design still matter. AI makes them matter more.
The uncomfortable thesis 🧭
Modern AI is not “nothing new”. That slogan is lazy and wrong. A large language model is a genuinely new kind of software component: probabilistic, natural-language-native, tool-using, context-sensitive, and capable of useful work over messy inputs that once required expensive custom logic.
But modern AI is usually not a new top-level architecture style. It is a new probabilistic component that should be placed inside familiar architectural structures. The novelty is not the removal of boundaries. The novelty is that those boundaries now need to be hardened for stochastic behaviour, prompt injection, context management, model churn, cost, latency, and evaluation difficulty.
Anthropic’s agent guidance is useful here because it separates workflows from agents. Workflows orchestrate LLMs and tools through predefined paths; agents let the model direct more of the process dynamically (Anthropic, 2024a). OpenAI similarly defines agents around an LLM managing workflow execution and dynamically selecting tools (OpenAI, n.d.-a). That difference is real. It also makes the architecture question sharper: where exactly is the model allowed to decide, and what deterministic structure surrounds that decision?
The AI vocabulary translation layer 🧾
The industry has invented a lot of new vocabulary. Some is useful; some is fog. Here is the translation layer:
| Modern AI term | Older architecture idea | What is really happening |
| Tool calling | Service Activator, Command Message, adapter | The model proposes a structured request; application code executes a capability. |
| Function calling | RPC, DTO, schema contract | A model fills arguments for a typed function; your system owns execution. |
| Router agent | Content-Based Router, strategy selection | Input is classified and routed to a specialised path. |
| Prompt chain | Pipes and Filters | One stage transforms or checks output before passing it to the next. |
| RAG | Content Enricher, retrieval pipeline, read model | External context is retrieved and added before generation. |
| Multi-agent workflow | Scatter-Gather, orchestrator-worker, Aggregator | Work is split, delegated, observed, and synthesised. |
| Planner | Process Manager, workflow engine, saga-like coordinator | A component tracks state and chooses next steps. |
| Guardrails | Validators, policy enforcement points, Message Filters | Inputs, outputs, retrieval, and tool calls are checked at boundaries. |
| Structured output | DTO, canonical message, schema contract | The model is constrained to a shape, but truth still needs validation. |
| Agent memory | Message Store, Message History, cache, external state | Context is externalised, recalled, audited, and governed. |
| MCP server | Adapter protocol, plugin boundary, connector layer | Tools and context sources are exposed through a standard interface. |
The mapping is a way to recover engineering judgment. Enterprise Integration Patterns documents a mature vocabulary for routing, filtering, enriching, aggregating, and tracing messages (Hohpe & Woolf, 2003/2023). LangGraph’s workflow and agent documentation uses near-enterprise-architecture language for prompt chaining, routing, orchestrators, and evaluator loops (LangChain, n.d.-a). The names changed; the forces did not.
Agentic AI through old architecture patterns 🧩
Tool calling is the easiest place to see the old architecture underneath. A model does not “call Stripe” or “delete a record” in some mystical sense. It emits a structured request. Your application decides whether the request is valid, authorised, safe, idempotent, and executable. OpenAI’s function-calling docs describe function tools through JSON Schema, but the model filling arguments is not the same as the domain approving an action (OpenAI, n.d.-b).
If a refund assistant proposes refund_order(orderId: 123), that is not a refund decision. It is an untrusted command proposal. The model may extract facts, draft a customer-facing explanation, rank evidence, or recommend a path. The deterministic refund policy should still decide eligibility.
Router agents are similar. A support system that sends billing issues to billing, technical incidents to engineering, and refund requests to a refund workflow is not architecturally new. What changed is that the classifier can handle messy natural language. That is useful, but a probabilistic router still needs confidence thresholds, fallback paths, and a dead-letter story.
RAG is another over-mystified case. Retrieval-Augmented Generation began as a way to combine parametric generation with retrieved external knowledge (Lewis et al., 2020). In production, RAG is not one magic step. It is query rewriting, retrieval, filtering, reranking, context construction, generation, citation, and validation. Architecturally, that is a pipeline and a Content Enricher. The hard questions are old information-system questions: who can access this document, how stale is the index, what evidence reached the model, and what happens when retrieval fails?
Multi-agent systems deserve more nuance. Anthropic reports that its multi-agent research system outperformed a single-agent baseline by 90.2% on an internal research evaluation, largely because parallel subagents could explore more context and then synthesise results (Anthropic, 2025a). That is real evidence that multi-agent design can matter. But it does not abolish the older pattern language. It looks like orchestrator-worker plus Scatter-Gather plus Aggregator, with a probabilistic planner and a larger token budget.
Why clean boundaries beat model choice 🧱
The most important AI architecture decision is usually not which model you picked. It is where the model is allowed to touch the rest of the system.
Cockburn’s Hexagonal Architecture argues that application logic should be insulated from external devices such as UIs and databases through ports and adapters (Cockburn, 2005). Extend that idea one inch: your domain should work without a particular LLM provider, vector database, prompt template, tool protocol, or agent framework.
Do not inject ChatGPTService into domain logic. Define a capability port:
“`text
ClassifySupportIntent
DraftRefundExplanation
ExtractInvoiceFields
GenerateKnowledgeAnswer
SuggestContractRisks
“`
Then implement that port with an LLM adapter. The adapter owns model choice, prompts, retries, token budgets, structured output parsing, provider quirks, and traces. The domain owns the business vocabulary, policy, and state transitions.
This is where DDD and vertical slices become practical. Bounded Context exists because language and rules differ across domains (Fowler, 2014). Business-capability decomposition says services should be split by what the business does, not by technical substrate (Richardson, n.d.-a). Vertical Slice Architecture argues for organising by request or use case rather than horizontal layers (Bogard, n.d.). A generic ai/ folder does the opposite: it groups unrelated capabilities by implementation detail.
ai/ is not a business capability. It is architecture by vendor brochure. 🧨
What AI genuinely changes 🌪️
The old-pattern argument needs humility. Some conditions really are new.
First, behaviour is probabilistic. Traditional components may fail, but they usually fail inside a deterministic execution model. LLMs can produce plausible, schema-valid, wrong answers. That pushes teams toward evals, thresholds, datasets, statistical monitoring, and review. Fowler frames LLM engineering as evaluation, testing, threat modelling, and operational discipline, not prompt craft alone (Fowler, 2024).
Second, natural language collapses the instruction/data boundary. Prompt injection is not just SQL injection with a new logo. The hostile instruction may be inside a web page, ticket, document, email, or retrieved chunk. OWASP treats prompt injection, insecure output handling, sensitive information disclosure, and excessive agency as first-order LLM application risks (OWASP Foundation, 2025). Anthropic’s containment guidance reaches the same engineering conclusion from another angle: probabilistic safeguards help, but access boundaries and environment-level containment are needed when agents can act (Anthropic, 2026).
Third, control flow can become non-deterministic. In classic integration, a developer writes the router or workflow. In agentic systems, the model may choose the tool, next step, stopping point, or recovery path. That is a real shift, and it is why reliable systems often re-impose explicit control flow, bounded state, budgets, and checkpoints around model decisions.
Fourth, context is now an engineering surface. The model’s output depends on what fits in context, what was retrieved, what was summarised, and what got omitted. Anthropic’s context-engineering guidance treats this as a serious design problem, not prompt garnish (Anthropic, 2025b).
Fifth, observability is different. Ordinary APM tells you latency and exceptions. AI observability needs prompts, completions, retrieval hits, tool calls, model choice, token usage, cost, guardrail outcomes, approvals, retries, and final side effects. Langfuse frames LLM observability around traces, evaluations, prompt versions, cost, and latency because the systems are non-deterministic (Langfuse, n.d.).
Practical rules for architecture teams 🛠️
Start with the business capability, not the model. Do not ask, “Where do we add AI?” Ask, “Which workflow step needs probabilistic assistance, and what contract should wrap it?”
Put the LLM behind a port. The domain should call ClassifySupportIntent, not callOpenAI. The adapter hides model selection, provider APIs, prompt formats, schemas, retries, logging, and fallback.
Keep domain rules deterministic. Use the model to propose, classify, extract, summarise, rank, or explain. Use code to decide eligibility, permissions, payments, deletions, compliance, and state transitions.
Validate in layers. Structured outputs help with shape, not truth. Guardrails belong at input, retrieval, tool-execution, output, and environment boundaries. Human review belongs before high-blast-radius actions, but containment and permissions matter more than endless approval pop-ups (Anthropic, 2026; OpenAI, n.d.-c).
Design side effects like distributed systems. Agent loops retry. Tool calls time out. Message relays duplicate. If a duplicate call can refund twice, email twice, delete twice, or publish twice, the problem is not AI weirdness. It is missing idempotency. Patterns like Idempotent Consumer, Transactional Outbox, and Saga remain painfully relevant (Richardson, n.d.-b, n.d.-c, n.d.-d).
Trace the whole decision path. Treat observability as Message History for a stochastic workflow. You need to know what the model saw, what it proposed, what tools ran, which guardrails fired, and what side effect occurred.
Prefer fixed workflows before autonomous agents when the steps are known. Add multi-agent coordination only when the work benefits from parallel exploration, specialised context, or separate tool permissions (Anthropic, 2025a; LangChain, n.d.-b).
Counterarguments: where the thesis needs nuance ⚖️
The strongest objection is fair: agents are not merely old workflows with a chatbot inside. A traditional Process Manager does not infer an execution graph from ambiguous language or recover from tool errors by inventing a new plan. Modern agents can dynamically choose tools and paths. That is not nothing.
Natural language also changes product economics. A user can now express intent directly, and a model can translate messy input into structured action. Foundation-model platforms make workflows economically feasible that once needed separate ASR, NLU, retrieval, dialog, and orchestration components.
Multimodality changes the surface area too. Models can increasingly work across text, image, audio, files, browser state, and remote tools. That affects product design and backend architecture.
And multi-agent systems can sometimes pay for their complexity. Anthropic’s research-system example is a useful warning against a lazy “multi-agent is always hype” position (Anthropic, 2025a). The better rule is not “never multi-agent”. It is “earn multi-agent”.
So the refined claim is this: AI does not abolish old architectural forces. It intensifies them and adds new probabilistic, safety, and operational failure modes. The right move is not to architect around AI as a standalone kingdom. The right move is to embed AI capabilities inside named business workflows, explicit contracts, and governed boundaries.
Closing argument 🚦
Your next LLM module is worth less than a clean boundary.
A better model may improve a benchmark. A better prompt may rescue a demo. A better framework may speed up a prototype. But a clean boundary lets you swap models, test policies, trace failures, control side effects, protect data, and evolve one business capability without smearing probabilistic behaviour across the whole system.
The most useful architecture question in AI is not “Which agent framework should we use?”
It is: “What business capability needs probabilistic assistance, and what deterministic contract will keep it honest?”
Answer that well, and the shiny wrapper becomes useful. Ignore it, and you are not building an AI architecture. You are building a distributed system with amnesia and a credit card. 💳
Further Reading
- Anthropic, Building Effective Agents – useful for separating workflows from agents and understanding common agentic patterns (Anthropic, 2024a).
- Enterprise Integration Patterns – the canonical vocabulary for routers, filters, enrichers, aggregators, and message history (Hohpe & Woolf, 2003/2023).
- OpenAI, A Practical Guide to Building Agents – a current platform view of agent definitions, tools, guardrails, and orchestration (OpenAI, n.d.-a).
- Cockburn, Hexagonal Architecture – the cleanest foundation for putting an LLM behind a port (Cockburn, 2005).
- Fowler, Bounded Context – a compact reminder that language and ownership shape boundaries (Fowler, 2014).
- Bogard, Vertical Slice Architecture – practical guidance for organising code by use case instead of technical layer (Bogard, n.d.).
- Fowler, Engineering Practices for LLM Application Development – a useful bridge from ordinary engineering to evals, threat modelling, and LLM-specific practices (Fowler, 2024).
- OWASP Top 10 for LLM Applications – the best concise risk map for prompt injection, output handling, data leakage, and excessive agency (OWASP Foundation, 2025).
- Langfuse Overview – a practical view of tracing, cost, latency, prompt versions, and evaluations for LLM systems (Langfuse, n.d.).
- Anthropic, How We Built Our Multi-Agent Research System – a concrete production case where multi-agent design can be worth the cost (Anthropic, 2025a).