Building Agentic Systems Without a Blueprint
Most teams building agentic systems today are doing architecture by instinct. Experienced engineers make good decisions — they know what sound systems look like. But those decisions aren’t made through a structured process. They’re not documented in architectural artifacts. They can’t be reviewed, audited, or handed off.
Here’s what that looks like in practice: an agent handles Tier 1 support tickets, calls a CRM tool, writes back to customers. It works. Then the auditor asks: what policy authorized that tool call? What data was in context when it wrote to the customer record? Who approved the delegation chain? The engineering lead points to the LangChain config. The architect points to the threat model. Neither document connects to the other. The system is in production, the answer doesn’t exist, and the deployment is frozen — weeks of engineering work on hold while the team tries to retroactively invent architectural records that should have existed from day one.
That’s a failure of methodology. The practitioners are capable, the tooling is improving, the patterns are spreading. What’s missing is the design layer — the structured process that connects business intent to governed, traceable, operable agentic systems.
Why Agentic Systems Break Existing Architecture
Traditional distributed systems are deterministic. You can trace a request through microservices, map the call graph, and verify trust boundaries at design time. Agentic systems are different in ways that matter architecturally: they’re non-deterministic, they maintain state across context windows, and they delegate authority opaquely through chains that no single document describes. Try modeling a support agent that decides to escalate to a specialist agent, which calls a billing tool, which writes to a customer record. That’s a delegation chain with trust, data, and authorization implications at every hop — none of which appear in a standard architecture diagram. TOGAF can model the container. It has no vocabulary for the autonomy.
This isn’t “new tech needs new frameworks” — a claim architects have heard every few years for decades. It’s more specific than that. The architectural primitives are different. What constitutes an agent boundary, how context engineering maps to architectural layers, where trust lives in a non-deterministic loop — these aren’t edge cases for existing methods. They’re the core design problems. Existing frameworks don’t address them because they were built before those problems existed.
Analysis Without Design
The industry hasn’t ignored the problem. Security frameworks like MAESTRO map the agentic threat landscape across seven layers — purpose-built for agentic threat modeling. NIST AI RMF extends that into governance vocabulary for AI risk. OWASP’s LLM Top 10 catalogs attack vectors every team should understand. These are serious tools built for real problems.
On the architecture side, TOGAF provides process and SABSA provides risk-driven design. They’re the closest things to a methodology: phased approaches, governance cadence, viewpoints, deliverables.
But all of these share a common limitation: they’re either process containers (phases, governance gates, risk vocabulary) or analysis tools (threat taxonomy, compliance mapping, risk categories). What they don’t provide is content — the domain-specific ontology for agentic systems. What exactly is an agent boundary? How does a delegation chain map to architectural layers? What does a control plane look like for a multi-agent system?
None of them answer these questions because they were never built to. Applying TOGAF to an agentic system design requires first inventing the primitives that TOGAF’s phases would operate on. Most teams don’t have the time or background to do that work — so they skip the methodology and build by instinct instead.
The Translation Gap
Engineering teams building agentic systems have developed effective patterns. Orchestration loops, context management, tool governance, delegation chains — this knowledge is real, it works, and it spreads through the practitioner community fast.
Enterprise governance teams have frameworks for AI risk. NIST, regulatory guidance, compliance standards — the policy layer is forming.
The gap is between them. The design methodology that takes business intent — “we need agents that handle Tier 1 support” — and moves it through capability definition, architectural structure, governance design, and runtime operations. That produces artifacts engineers, architects, and compliance teams can all work from.
This gap isn’t about awareness. Everyone knows governance matters. The gap is process and shared vocabulary — the structured design methodology that lets an enterprise architect and an AI engineer work on the same problem in the same frame, and produce something an auditor can actually review.
The Missing Design Layer
A design methodology does something analysis frameworks don’t: it produces structure before you build.
When you work through a proper agentic design process, you know what primitives the system has. You know where trust boundaries are drawn. Critically, you know the difference between structural safety — guarantees enforced by the architecture itself through permissions, control planes, delegation constraints, and audit logs — and behavioral safety, which is model and prompt behavior shaping. Both matter. But structural safety has to be designed into the system; you cannot prompt your way to architectural guarantees.
Here’s what that design process produces, concretely:
- Agent/system primitive model — what components make an agent an agent, what makes a system a system
- Delegation chain map — who can delegate to whom, with what constraints and under what conditions
- Tool access policy — what tools each agent can call, enforced at design time and runtime
- Context lifecycle spec — data sources, retention, redaction, grounding constraints
- Control plane design — monitoring, approvals, kill switches, audit logs
Those artifacts give you a shared vocabulary. An architect can talk to a governance team about delegation chains and control plane design. An AI lead can brief a CISO on structural versus behavioral safety. The coordination cost drops because the design produced something everyone can read.
The Work I’ve Been Doing
To bridge this exact gap, I’ve been developing the Architecture Framework for Agentic Systems (AFAS) — a practitioner’s design methodology built to fill the space between engineering practice and enterprise governance.
AFAS isn’t a replacement for NIST, MAESTRO, or TOGAF. It’s the domain content those frameworks assume exists. The agentic primitives, the control plane patterns, the trust and identity model for multi-agent systems. When you work through an AFAS design, you produce artifacts that map to NIST controls, MAESTRO threat categories, and EA governance requirements. The security and compliance work becomes easier because the architecture was designed for it.
I’ve been building this from the inside out — starting with primitives (what is an agent, what is a system), working through the control plane (structural safety, not behavioral safety), mapping design decisions to architectural layers. Practitioner-first — developed against production agentic systems in regulated enterprise environments, not constructed from theory.
What’s Coming
I’m publishing this framework piece by piece over the next several weeks — each post standing alone, each assembling into the larger whole.
The topics ahead:
- The two-level primitives model: what an agent IS versus what a system IS
- The control plane: structural safety versus behavioral safety
- Context engineering as a design discipline
- Trust and identity in multi-agent systems
- Runtime governance patterns
If you’ve spent time drawing delegation chains on a whiteboard while the compliance team asks for “the architectural decision record on agent autonomy” — you’re working in the gap. That’s exactly the problem this framework is being built to solve.
Agentic systems are being deployed faster than the discipline to govern them. Until we build the design layer, we’re building without a blueprint.
The next post covers the primitives model — what an agent actually is, at an architectural level. That’s where the framework starts.
AFAS — Architecture Framework for Agentic Systems — is a practitioner’s design methodology for building governed, traceable agentic systems. This is the first post in an ongoing series.