ML/AI, CV
The Model Is No Longer the Architecture - Software Engineering in the Agentic Era
For the last few years, most conversations about AI in software engineering revolved around one question:
Which model is best?
That question is rapidly becoming less interesting.
The more important question is:
How do we safely give an AI system enough context, tools and authority to actually do useful work?
That change represents a much bigger architectural shift than simply adding an LLM to an application.
We are moving from AI-assisted software development to agent-operated software systems.
And that requires a new architecture.
From copilot to delegated execution
The first generation of AI development tools sat beside the developer.
A developer wrote code, AI suggested something, and the developer decided whether to accept it.
Developer
↓
IDE
↓
AI suggestion
↓
Code
↓
Build → Test → Deploy
The human remained in almost every execution loop.
Agents change this model.
Modern engineering agents increasingly operate at the level of repositories, features and workflows rather than individual lines of code. Research into agentic software engineering describes the transition as one from code generation toward delegated execution under human supervision.
The emerging workflow looks more like:
Human
↓
Goal / Specification
↓
Agent
↓
Plan
↓
Retrieve Context
↓
Use Tools
↓
Modify Code
↓
Run Tests
↓
Open PR
↓
Potentially Deploy
That is no longer autocomplete.
It is an autonomous workload.
And once we think about agents that way, many familiar software architecture problems suddenly return in a new form.
The agent harness becomes the architecture
An LLM by itself is not an agent.
It cannot reliably provide identity, permissions, durable state, execution isolation, recovery, governance or auditing.
Those capabilities have to exist around the model.
This surrounding infrastructure is increasingly called the agent harness. I have written about it before - the model is not your agent makes the case, and build an agent harness from scratch shows what one looks like in about 250 lines of Python.
Research examining dozens of agent systems identifies recurring architectural concerns around context management, tools, subagents, orchestration, safety and execution environments.
A production architecture therefore starts looking like this:
HUMAN
│
Goal / Spec
│
┌───────▼───────┐
│ Agent Harness │
└───────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
Context Planning Memory
│ │ │
└─────────────┼─────────────┘
│
Tool Gateway
│
Policy Engine
│
Secure Runtime
│
┌───────────┼───────────┐
▼ ▼ ▼
Git CI/CD Cloud
The model is important.
But increasingly, the harness determines whether the model is useful in production.
Harness, in one sentence
The harness is the loop and everything the loop needs that the model cannot supply: which tools exist, what the agent is allowed to do, where its state lives between turns, what happens when it gets stuck, and who can prove afterwards what it did. Swap the model and the harness should still stand. Swap the harness and even the best model is just a text box.
Context becomes infrastructure
Agents also introduce another architectural layer: context infrastructure.
A developer understands much more than the files currently open in their editor.
They understand architecture decisions, coding conventions, tickets, previous incidents, deployment processes, domain terminology, security policies and the history behind strange pieces of code.
An agent needs access to some approximation of that knowledge.
This creates a new engineering problem:
Repository
Documentation
Architecture Decisions
Tickets
Standards
Policies
Production Signals
Previous Agent Runs
│
▼
Context Layer
│
▼
Agent
Atlassian's recent agentic-development work illustrates this direction, adding organisation and multi-repository context alongside controls and automated engineering loops.
The quality of an AI system may therefore depend increasingly on something that isn't the model at all:
the quality of the context supplied to it.
MCP is becoming the integration layer - but not the security layer
The Model Context Protocol has quickly become an important mechanism for exposing tools and data to agents.
Instead of building custom integrations for every agent:
Agent → Jira adapter
Agent → Git adapter
Agent → Database adapter
Agent → Kubernetes adapter
Agent → Slack adapter
we can increasingly imagine:
Agent
│
MCP
│
┌───────────┼───────────┐
▼ ▼ ▼
Git Database Kubernetes
MCP is also evolving quickly. AWS recently highlighted the 2026 protocol change toward a stateless core, simplifying remote MCP infrastructure and removing several session-management requirements.
But there is an important distinction:
MCP standardises how an agent calls a tool. It does not determine whether the agent should be allowed to call it.
Microsoft has explicitly highlighted this gap, describing the need for governance around MCP tool execution.
MCP answers the integration question. The companion piece MCP gave agents tools, A2A gives agents colleagues covers what happens when the thing on the other end of the connection is another agent. Neither protocol answers the authorisation question.
That leads naturally to another architectural component.
The agent control plane
Giving an AI agent credentials directly is probably going to look increasingly strange.
Instead:
Agent
│
▼
Agent Control Plane
│
├── Identity
├── Tool permissions
├── Model routing
├── Cost limits
├── Policy
├── Human approvals
└── Audit
│
▼
MCP / APIs
│
▼
Enterprise Systems
AWS is already exploring MCP gateways and registries where organisations maintain approved agents, MCP servers, skills and workflows.
This resembles something software engineering has seen before.
We built API gateways to control service-to-service communication.
We built Kubernetes control planes to manage workloads.
We built IAM to control human and machine identities.
Now we are beginning to build control planes for autonomous agents.
Treat an agent like a workload identity
This leads to an important security principle.
Don't think of an agent as:
an employee with an AI assistant.
Think of it as:
an untrusted workload requesting permission to perform actions.
Every action should therefore have:
Identity
+
Intent
+
Context
+
Policy
↓
Authorization
↓
Execution
Infrastructure patterns are already emerging around least-privilege agent gateways, policy-as-code, ephemeral execution environments and OpenTelemetry-based monitoring. Assume the agent can escape walks through nine of those controls, and Kubernetes is acquiring the isolation primitives that the ephemeral part needs.
An agent modifying documentation might need broad autonomy.
An agent changing production infrastructure should probably encounter significantly stronger controls.
Autonomy should be proportional to the blast radius of failure.
A human approval is a control, not a boundary
Approval gates are valuable because they put a person in front of a consequential action. They are not a security boundary, because the thing asking for approval is also the thing describing what it is about to do. If the description is wrong, so is the approval. The boundary is the policy engine, the scoped credential and the sandbox - the things that hold whether or not the agent's account of itself is accurate.
Observability must evolve too
Traditional applications gave us:
Logs
Metrics
Traces
Agents require another level of visibility.
A useful agent trace might look like:
Goal
↓
Context retrieved
↓
Model decision
↓
Tool selected
↓
Policy decision
↓
Tool arguments
↓
Tool result
↓
Agent decision
↓
Human approval
↓
Side effect
↓
Cost
↓
Outcome
And importantly, not all of this data should have the same lifecycle.
A reasoning trace may be temporary diagnostic information.
But:
Agent X modified production infrastructure at 14:32 under policy Y after approval from user Z
is an audit event.
That distinction between observability and accountability will become extremely important.
AI doesn't remove deterministic software
Perhaps the biggest mistake in AI architecture is assuming probabilistic systems should replace deterministic ones.
They shouldn't.
Consider mathematics.
An LLM might be excellent at:
understanding the question
↓
identifying the required skill
↓
explaining the concept
↓
choosing an appropriate exercise
But if the system needs to establish whether:
2x + 5 = 17
was solved correctly, a deterministic mathematics engine can verify that answer. That is the whole argument of CAS is not obsolete in the age of agentic AI: the AI proposes, the CAS proves.
Similarly:
AI
→ interpret
→ plan
→ explain
→ navigate
→ generate candidates
Deterministic systems
→ authorize
→ calculate
→ validate
→ enforce
→ test
→ persist
The strongest AI architectures will combine the two.
Don't replace deterministic systems with AI. Put AI around deterministic systems.
Software engineering isn't disappearing
The engineer's role is changing.
Historically:
Understand
↓
Design
↓
Code
↓
Test
↓
Deploy
Increasingly:
Understand
↓
Specify
↓
Constrain
↓
Delegate
↓
Observe
↓
Verify
↓
Approve
Recent research describes this as a shift from deterministic programming toward supervising probabilistic execution, while still emphasising that agentic engineering depends heavily on classical software-engineering principles.
And that may make some engineering skills more important rather than less.
Architecture.
Domain knowledge.
Security.
Testing.
Observability.
Clear specifications.
Understanding failure modes.
Knowing what correct actually means.
Because generating ten thousand lines of code becomes much less impressive when machines can generate them in minutes.
The scarce skill becomes knowing whether those ten thousand lines should exist at all.
The emerging AI-native architecture
Put all of these developments together and a pattern starts to appear:
HUMAN
│
Goal / Intent
│
┌────────▼────────┐
│ Agent Control │
│ Plane │
└────────┬────────┘
│
┌───────────────┼────────────────┐
│ │ │
Planner Builder Reviewer
│ │ │
└───────────────┼────────────────┘
│
Context Layer
│
Agent Harness
│
MCP / Tool Gateway
│
Policy Engine
│
Secure Sandbox
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Git CI/CD Cloud/K8s
│
▼
Deterministic Systems
Rules / Tests / CAS
│
▼
Observability
│
┌──────────┼──────────┐
▼ ▼ ▼
Traces Audit Analytics
This may become one of the defining software architectures of the next decade.
The interesting part is that the LLM occupies only a relatively small part of it.
That is exactly what the vendors are now organising around. When Microsoft reorganised its reporting into a segment called Agents and Infra, it grouped the runtime, the data, the developer platform and the compute together and left the model as one line item inside it. The AI war is moving down the stack for the same reason.
The next era of software engineering
The first AI wave asked:
Can AI generate code?
We've answered that.
The second asked:
Can AI complete engineering tasks?
Increasingly, yes.
The next question is much harder:
Can we build systems where autonomous agents operate safely, economically, observably and predictably at scale?
That isn't primarily an AI-model problem.
It's a software architecture problem.
And that is why software engineering may matter more - not less - in the age of AI.