Architecture and Intent — Tony Malott
Skip to article
Tony Malott · Architecture · AI Systems
Architecture and Intent
The system diagram is only half the architecture.
Flagship V2 candidate
Owner-UAT
September 2026
I have spent enough time around enterprise architecture to know what happens when somebody asks for a system diagram. We draw the applications, services, data stores, APIs, identity layer, security boundaries, deployment model, telemetry and dependencies. Now we add the model, retrieval layer, vector store, orchestration framework, agent tools and whatever else accumulated since the last version.
That diagram is necessary. It is also only half the architecture.
The missing half is not another technology layer. It is the architecture that determines meaning, authority, legitimacy, consequence and constraint.
01 · Capability
We have been modeling capability better than authority.
If we are feeling ambitious, we put the whole system on one enormous page, connect it with a heroic number of arrows, add enough vendor logos to satisfy everyone who sold us something, and call it architecture. I am not dismissing that diagram. I want it. I need to know what the system touches, how information moves, where trust boundaries exist, how failures propagate and how we recover when something inevitably misbehaves at an inconvenient hour.
But the technical diagram can show me what the system can reach without telling me what it is allowed to trust. It can show an agent connected to a tool without explaining why that agent has legitimate authority to use it in a particular situation. It can show retrieval without telling me which source governs when retrieved information disagrees.
Those missing rules usually exist somewhere: policies, procedures, approval chains, security controls, exception processes, institutional knowledge and the heads of people who have been doing the work long enough to understand the unwritten rules. That may have been survivable when software mostly waited for explicit instructions. It becomes a dangerous assumption when systems begin interpreting context, selecting tools, coordinating work, changing state and increasingly acting on our behalf.
Technology architecture describes capability. Architecture of intent describes meaning, authority, legitimacy, consequence and constraint.
The two-plane model in one view: capability below, intent above, with authority, consequence and human judgment made explicit.
02 · The second plane
Architecture has another plane underneath the technical one.
The technology architecture contains the applications, models, data, retrieval mechanisms, context systems, APIs, tools, identity, security controls, infrastructure, deployment paths, observability, resilience and recovery mechanisms. It tells us what exists, how the pieces interact and what the system is technically capable of doing.
The architecture of intent contains the objectives the system is supposed to serve, the semantics that determine what information means, the hierarchy of authoritative sources, the rules for ambiguity and conflict, the boundaries of decision and mutation authority, the evidence required for consequential actions, the expected reversibility, the permitted blast radius, the escalation paths and the places where human authority enters.
Most mature organizations already have versions of these controls. They simply live somewhere else. Authority may be buried in an operating procedure. Approval may live in a workflow. Semantics may exist as institutional knowledge. Someone knows which repository is canonical. Somebody else knows that the document marked “final” was quietly superseded six months ago. People who have worked inside a large enterprise learn how to navigate that terrain. Machines do not inherit the understanding by osmosis.
03 · Information authority
Authority is not a ranking problem.
A document can be newer without superseding anything, highly relevant without being approved, or authoritative for one purpose while being completely inappropriate for another. And sometimes the authoritative source is simply wrong. Enterprise systems are full of these cases because authority, recency, relevance and correctness are different dimensions, even though retrieval architectures have a habit of flattening them into one ranking problem.
The architecture therefore needs to know more than where information came from. It needs some understanding of what standing that source has for the decision being made, especially when sources disagree. Maybe one is stale. Maybe one is local guidance while another is enterprise policy. Maybe both are legitimate but apply to different scopes. Maybe one describes the approved state and another describes operational reality.
AI systems are exceptionally good at making those disagreements look settled. Give a strong model several conflicting sources and it can often produce one wonderfully coherent narrative. Sometimes that is synthesis. Sometimes it is contradiction laundering.
There are cases where the right answer is: these sources disagree, I understand the disagreement, and I do not have sufficient authority to resolve it.
Retrieval finds candidates. Architecture determines standing. Disagreement and uncertainty remain visible when authority is insufficient.
04 · Action authority
Autonomy should scale with consequence.
An agent may be capable of sending an email, changing a repository, updating a database, publishing a page or deleting an object. Each capability answers one question: can the system perform the operation? The harder question is why that operation is legitimate in this situation.
Agentic systems make the distinction easy to lose because reasoning and execution increasingly happen inside one loop. The system observes something, forms a conclusion, chooses a tool, constructs an action and executes it. On an architecture diagram, the whole sequence can collapse into a single arrow coming out of a box labeled “Agent.” A surprising amount of authority can disappear inside that arrow.
This is why broad arguments about whether agents should be autonomous are not especially useful. Reading a public document and deleting a production record are both actions, but grouping them together because an agent initiated them throws away almost everything that matters. The useful variable is consequence.
At the lower end, systems should often operate with considerable freedom. Reading, inspecting, classifying, comparing, summarizing and deterministic analysis are precisely the activities we should stop forcing humans to babysit. As systems move into recommendation, preparation, drafting and staging, they influence downstream outcomes but remain largely reviewable and reversible. Once they modify operational state, trigger external systems, publish information, affect other people or perform destructive actions, the architecture should demand more.
Authority should become more explicit. Validation should strengthen. Evidence matters more. Observability becomes less optional. Blast radius should narrow. Reversibility should be engineered rather than hoped for.
Put friction where consequence warrants friction.
This does not mean putting a human in front of every tool call. That would combine the complexity of agentic systems with the operating speed of a committee meeting. Good automation removes people from mechanical work. Good architecture spends human attention where legitimacy and consequence require it.
05 · Binding the planes
The two planes have to connect.
Separating technology architecture from architecture of intent is useful for thinking and review, but leaving them as unrelated diagrams would simply create another documentation problem. They have to bind together.
If an agent can publish, I should be able to trace that capability back to an objective, the information allowed to govern the content, the authority required to release it, the validation performed before publication and the recovery path if the result is wrong. If a system can modify operational state, I should know what authorizes the mutation, the maximum permitted scope, how the result is verified and how quickly the previous state can be restored.
This is where architecture of intent stops being philosophical and becomes operational. A useful review should be able to take any consequential capability and ask a compact set of questions:
01
What objective does it serve?
02
What information has authority?
03
Who can decide, and what action is permitted?
04
How is the result validated and what evidence remains?
05
What is the maximum blast radius, and can the action be reversed?
06
When does the system escalate, and where must it stop?
Not every answer requires an elaborate control system. But every important question deserves an answer, and an explicit gap is more useful than a confident assumption hidden behind an arrow.
Historically, many of these questions would have been classified as governance and moved into another workstream after the “real architecture” was complete. I no longer think that distinction survives contact with agentic systems. If authority determines whether a technically possible action is legitimate, authority belongs in the architecture. If semantics determine how conflicting information is interpreted, semantics belong in the architecture. If reversibility determines whether an action can safely be delegated, reversibility belongs in the architecture.
This is not governance invading engineering. It is engineering finally being forced to model things organizations previously carried in people and process.
Bring me both diagrams
We are moving from systems that primarily retrieve and generate information toward systems that interpret context, select tools, coordinate work, modify state and act across organizational boundaries. The arrows in our diagrams are becoming more powerful. Our architecture needs to catch up.
I still want the technology diagram. Show me what the system can do and how it behaves when the infrastructure underneath it stops cooperating. Then show me the other plane: what the system is allowed to trust and why, where authority comes from, what happens when sources disagree, how a recommendation acquires legitimate authority to become an action, how far the consequences can spread, what evidence survives and whether the action can be reversed.
Show me where human judgment actually matters and where the machine has to stop rather than improvise.
Bring me both diagrams.
Evidence and provenance
Selected public authorities
The essay distinguishes Tony Malott’s architecture doctrine from external corroboration. These sources support specific risk, security, human-oversight and provenance claims; they do not claim authorship of the two-plane architecture thesis.
NIST AI 600-1
Generative Artificial Intelligence Profile · risk and trustworthiness context
NIST publication
OWASP LLM01
Prompt Injection · retrieved/external content and the limits of RAG as a mitigation
OWASP guidance
OWASP LLM06
Excessive Agency · least privilege, narrow tools, approval and monitoring
OWASP guidance
EU Artificial Intelligence Act
Risk-proportionate human oversight, intervention, override and safe stopping in applicable contexts
Official Journal text
W3C PROV
Provenance model for entities, activities, derivation and trust assessment
W3C PROV Overview
Version lineage
V2 is a ground-up successor presentation of the existing Architecture and Intent Work. The retained heritage predecessor remains evidence, not implementation source.
Tony Malott · Architecture and Intent · V2 Owner-UAT candidate
Core reading requires no JavaScript or network access.