For a while, the easiest way to think about generative AI was as a new interface.

You gave a model some context. It generated an answer. Maybe that answer became code, a summary, a recommendation, or a draft. But the model itself mostly stopped at the edge of the conversation.

Agentic AI changes that boundary.

The interesting part is not simply that the model is smarter. The interesting part is that software can now decide what to do next, select a tool, take an action, inspect the result, and continue.

That sounds like a small extension of what we already have. Architecturally, it is not.

The Shift Is From Answers to Actions

A conventional AI feature might answer a question about an account. An agent may decide to retrieve the account, compare records, open a case, send a message, update a workflow, and then verify that the change completed.

The first system produces information.

The second system participates in operations.

Once AI crosses that line, the risk model changes. A bad answer is frustrating. A bad action can mutate data, spend money, create an obligation, expose information, alter infrastructure, or trigger another automated system.

This is why I think agentic AI should be treated primarily as a systems architecture problem.

An Agent Is More Than a Model

It is tempting to reduce an agent to the model at its center. In practice, the useful unit of architecture is larger:

Model + context + memory + tools + identity + workflow + policy + feedback

The model reasons, but the surrounding system determines what the model can see, what it can call, what credentials it can use, how long it can continue, what happens when something fails, and whether a proposed action is allowed to execute.

Those surrounding decisions often matter more than the model choice.

A modest model operating inside a carefully designed execution environment may be safer and more useful than a more capable model with broad credentials and weak controls.

Agents Bring Back Familiar Distributed-Systems Problems

There is a tendency to describe agent architecture as if everything about it is new. Much of it is not.

Once agents call tools and participate in workflows, architects run into familiar questions:

  • What happens if an action is retried?
  • How do we make side effects idempotent?
  • How do we recover when a multi-step workflow partially completes?
  • How do we prevent one slow tool from blocking an entire chain?
  • How do we trace a decision across services?
  • How do we enforce timeouts, quotas, and concurrency limits?

Agents introduce new reasoning behavior, but they still run on top of distributed systems. They still fail in networks, databases, APIs, queues, and permissions.

The difference is that the control flow is more dynamic. Instead of every path being explicitly written by a developer, part of the path may be chosen at runtime by the agent.

That makes observability and policy much more important.

The Blast Radius Matters More Than the Demo

A useful architecture review question for any agent is simple:

If this agent makes a bad decision, what can it actually do?

That question forces us to look past the demo.

An agent that drafts a support response has a very different risk profile from an agent that can issue refunds. An agent that recommends an infrastructure change is different from one that can deploy it. An agent that reads a customer record is different from one that can update account permissions.

For each agent, I would want to know:

  • which identity it runs under,
  • which systems it can reach,
  • which tools it can invoke,
  • which actions are reversible,
  • which actions require approval,
  • how much time or money it can consume, and
  • whether we can reconstruct what happened afterward.

This is essentially the agent's blast radius.

Tool Access Should Not Mean Execution Authority

This is the part of agent architecture I keep coming back to.

Many implementations connect model output directly to executable tools. The model chooses a function and the runtime performs it. That is convenient, but it quietly gives the reasoning component operational authority.

I think those concerns should be separated.

The model should be able to propose an action. A different layer should decide whether that action is allowed in the current context.

In other words:

intelligence can generate intent, but intelligence should not automatically grant authority.

That can be implemented in many ways: scoped permissions, policy engines, approval gates, execution adapters, risk tiers, or event-driven workflows. The exact technology is less important than the boundary.

If the model both proposes the action and effectively authorizes it, the system has collapsed reasoning and control into one component.

Observability Has to Capture More Than Requests

Traditional application observability asks familiar questions: which request failed, which dependency was slow, and where did the exception occur?

Agent systems add another dimension: why did the system choose this path?

A useful trace may need to connect:

trigger → context → proposed intent → tool selection → policy decision → execution → outcome

That does not mean storing every hidden model thought. It means preserving the system-level evidence required to understand what the agent attempted, which controls were applied, what actually executed, and what happened next.

Without that, debugging an agent becomes guesswork.

Human Approval Is Not a Failure of Automation

There is sometimes an assumption that a truly autonomous agent should avoid human intervention.

I think that is the wrong goal.

The goal should be to automate as much as the risk allows.

Low-risk and reversible actions may be perfectly reasonable to execute automatically. Higher-impact actions may need more context, stronger policy checks, or explicit approval.

A good agent architecture should therefore support several outcomes:

  • allow when the action is within policy,
  • block when it is clearly unsafe or disallowed, and
  • escalate when human judgment is still the right control.

Autonomy is not binary. It is something we should grant deliberately.

What Changes for Software Architects

The arrival of agents does not make traditional architecture less important. It makes many of the old disciplines matter again in a new form.

Identity becomes agent identity. API governance becomes tool governance. Distributed tracing becomes agent execution tracing. Rate limits become action budgets. Zero Trust expands from users and services to autonomous actors. Platform engineering starts serving both developers and the agents working on their behalf.

And architecture reviews need to move beyond asking whether an AI feature produces good output.

We also need to ask whether the system is designed to behave safely when that output becomes action.

The Real Frontier

Agentic AI is often presented as the next generation of automation. I think the more useful framing is that it introduces a new kind of software actor.

This actor can interpret ambiguous goals, choose among possible actions, use tools, and adapt to what it observes.

That is powerful.

But power is only useful in production when it is paired with boundaries.

The most important agent systems will not be the ones with the most autonomy. They will be the ones where autonomy is intentionally designed: where identity is scoped, tools are controlled, actions are observable, failures are recoverable, and authority is explicit.

That is the part of agentic AI I find most interesting.

Not simply making software more intelligent.

Making intelligent software something we can actually trust to operate.

Explore this topic

Part of the Agentic Systems topic collection.