Abstract
Most "AI architecture" talk is really tool talk. It treats frameworks as the thing being chosen, when the thing being designed is a system that must remain legible under pressure: when it fails, when it scales, when it gets audited, and when someone new has to change it.
This piece argues that AI architecture is a governance question disguised as a technical one. The core decision is where you place control: whether AI is allowed to author the sequence of work, or whether it operates inside a workflow whose boundaries you can name, test, log, and interrupt.
The question beneath the framework debates
The debates are loud: agent frameworks, graphs, orchestration, "crew" patterns, typed wrappers, new libraries every month.
Underneath the noise is a simpler question:
What does your system need to be true about itself when something goes wrong?
If the answer is "we can explain what happened, trace what moved, and stop it quickly," you are doing architecture.
If the answer is "we trust the framework," you are doing hope with momentum.
The control plane mistake
There is a seductive model that keeps reappearing: AI as orchestrator.
In that model, you give a model a goal and let it decide which tool to call next, when to loop, when to stop, who to delegate to, and how to compose the result.
For open-ended exploration, this can be useful.
For defined business work, it is often the wrong place to put power.
A business workflow already has a control plane:
- triggers
- known steps
- known "done"
- review gates
- policies about what must not happen
When you move the control plane into a model, you trade legibility for vibes. Sometimes the vibes work. When they do not, you discover the cost: debugging becomes anthropology.
If you cannot explain what happened and who could intervene, it is not architecture.
The model that holds up: AI as transformation inside a workflow
A more durable approach is boring in the right way.
AI is a transformation step inside a workflow you control.
- input arrives
- context is gathered
- AI transforms (extract, classify, draft, decide)
- output returns
- the workflow continues
Sophistication can live inside the step:
- retrieval augmentation
- tool calls
- multi-turn prompting
- schema correction
- self-checks against constraints
What you keep is governance: explicit flow, visible state, and clear intervention points.
A concrete example: support ticket triage
Most orgs do not need a debate to know what "ticket triage" means. They need it to happen reliably.
Here is a workflow that counts as architecture:
- Ticket arrives (trigger)
- Strip risky content, normalize fields (boundary)
- Retrieve customer context (state)
- AI extracts issue category, urgency, and suggested next action (transform)
- Confidence gate:
- high confidence: route automatically
- low confidence: human review (control)
- Action is applied (tool use)
- Full trace is logged (observability)
If this fails, you can answer:
- what data went in
- what context was retrieved
- what the model produced
- why it routed the way it did
- who reviewed it
- what action was taken
- how to stop it from repeating
That is why the workflow comes first.
Use orchestration, but keep it in a box
You do not have to ban agentic behavior.
You just have to bound it.
Use orchestration inside a clearly defined box where:
- inputs are constrained
- allowed actions are constrained
- outputs are validated
- loops have limits
- a human can intervene
Do not let orchestration become the outer control plane for a known business process.
Match architecture to workflow reality
Most teams reach for sophistication too early, because sophistication looks like progress.
A better approach is to choose the minimum structure that preserves legibility.
| Tier | When it fits | What you need to be true |
|---|---|---|
| Tier 1 | Request response, linear flow | No durable state, clear validation, clear logs |
| Tier 2 | Background jobs, retries, throughput | Queues, idempotency, persistence, error handling |
| Tier 3 | Pause/resume, human gates, checkpoints, cycles | Explicit state machine or graph, checkpointing, review gates, intervention paths |
Criteria that outlast frameworks
Frameworks change. Criteria should not.
Transparency
Can you trace the execution path without reading framework internals?
If you cannot follow the flow, you cannot reliably debug it or explain it to stakeholders.
Typed interfaces
Do you enforce contracts, or do you hope outputs are shaped correctly?
A typed interface is not a style preference. It is a control mechanism.
Explicit control flow
Do you define the workflow, or does the framework decide?
If you cannot point to the step sequence, you cannot govern it.
State visibility
Can you inspect state, persist it, restore it, and modify it?
If state is implicit, incident response becomes guesswork.
Escape hatch
When the abstraction breaks, can you drop to plain code?
If not, you are coupled to a system you cannot fully own.
Minimal layers
Could a new engineer rebuild the core logic in a weekend if needed?
If not, you are borrowing complexity without pricing it in.
Why this is governance, not preference
This is the part that is easy to miss.
The reason visibility and control matter is not engineering purity.
It is because every serious conversation eventually becomes a governance conversation:
- "Is it secure?"
- "Can we audit it?"
- "Can we stop it?"
- "Who is accountable?"
- "What happens when it fails at scale?"
Architecture is the answer you give when someone asks those questions.
Closing thought
Stop choosing frameworks first.
Choose where control lives. Keep AI inside workflows you can name, test, log, and interrupt. Use orchestration when it is needed, but keep it bounded and governed.
If you can produce a clean explanation of what happened, what moved, and who could intervene, you have architecture.
If you cannot, you have a prototype with momentum.
What to remember
- Architecture is governance: control flow, state, boundaries, observability, failure handling.
- Keep AI as transformation inside workflows you control, and bound orchestration in a box.
- Tier your architecture based on workflow requirements, not tool hype.
- Pick frameworks by criteria that preserve legibility under pressure.