Agents are microservices with a friendlier voice

Everyone is talking about AI agents like we discovered a new species. I keep looking at them and seeing microservices.

Small, purpose-built capabilities. APIs. State. Orchestration. Something fails halfway through and now somebody has to work out what actually happened.

I made the comparison pretty bluntly on LinkedIn. It deserves one correction before we take it too far: an agent is not automatically a microservice. The useful overlap is the engineering discipline, not the deployment model.

Are AI agents actually microservices?

A microservice is a way to organize and deploy software around a bounded capability. An agent describes behavior: a model can select tools and adjust its next step using the result. You can run several agents inside a monolith. You can put one agent behind a service boundary. You can also build a perfectly useful workflow without giving a model control of the sequence.

Lewis and Fowler’s microservices description centers on independently deployable services organized around business capabilities. Anthropic’s agent architecture guide distinguishes predefined workflows from model-directed tool use. Those describe different dimensions of a system.

The analogy becomes useful when the agent crosses a boundary. Who owns the data? What can this caller change? What happens if the request times out after the write succeeds?

We already needed answers to those questions. A conversational interface adds another participant that can misunderstand them.

A cart edit is a better test than a good conversation

An audit of my Après Studio commerce demo on September 5, 2026 exposed a useful example. Juniper, the shopping assistant, could add one black, medium Summit fleece to the bag. Asking her to change the quantity to two failed twice. The normal cart stepper made the same change successfully. Afterward, Juniper could read the updated quantity and subtotal.

That is one dated demo test, not a production reliability measure. It also does not establish the underlying cause. It narrows the investigation: the direct cart interaction could perform a change that the conversational path could not.

The shopper asked for two total. A retry must preserve that intent. If the first request actually succeeded but its response disappeared, blindly adding another unit could create three. A command to set quantity to two has different retry semantics from a command to add two more.

That distinction belongs in the tool contract and backend behavior. Asking the model to be careful is insufficient.

Which decisions belong outside the agent?

I want the model helping with interpretation and choice. I want the commerce system enforcing what is allowed and reporting what happened.

Shopper request	Useful agent work	Enforced system responsibility
Find a black fleece in medium	Interpret preferences and compare grounded options	Return real variants, prices, and availability
Make that two total	Resolve the intended cart line and requested quantity	Validate the change, handle retries, return the resulting cart
Cancel my order	Identify the request and explain the available path	Verify customer access, cancellation eligibility, and the actual result

The exact split depends on the product. The principle holds: the model’s interpretation is input to an authorized operation. It is not permission to perform it.

Successful tool execution also needs evidence the assistant can use. “Request accepted” and “order canceled” are different states. A pending operation should stay pending in the customer response until the owning system confirms otherwise.

More named agents can mean more coordination

A shopper agent, buyer agent, and merchant agent sound like clean boundaries. Names do not establish them.

Give all three the same mutable memory, overlapping write tools, and one enormous orchestration prompt, and a small change can affect all of them. You have more participants to trace without gaining independent ownership or change.

Before splitting an agent, I would want a concrete reason: a different permission boundary, a different owner, a workload that needs independent scaling, or a task that benefits from a separately evaluated capability. “The diagram looked more agentic” will be expensive to support.

There is more on that ownership problem in agentic systems need an operating model.

Test the failed action and the next request

For a commerce agent, I would start with a small set of transaction tests: a successful write, a rejected write, a stale cart, an ambiguous variant, and a lost response after a write. Then ask another question. Check whether the assistant carries forward the real state or the state it hoped to create.

Trace the tool inputs, permissions, responses, and resulting business state. Set a retry limit. Give the shopper a usable fallback when the conversational path is stuck. The recovery path needs as much attention as the first successful turn.

The tech is new. The way to screw it up isn’t.