We let AI coding agents into our codebase. The modular monolith won.

For a decade, "microservices vs monolith" was an argument about human teams: Conway's Law, independent deploys, blast radius. In 2026 a new participant walked into the codebase and quietly changed the math: the AI coding agent.

We build software for a living. Our work is production systems for regulated industries, and we've spent the last year with agents (Claude Code, Cursor, the usual suspects) reading and writing real code alongside us. The pattern is consistent enough to say out loud: agents reason far better over a well-structured modular monolith than over a fleet of microservices. And we're not alone in moving that direction. The CNCF has reported a wave of teams consolidating services rather than splitting further.

Here's why, and where it still breaks.

Microservices were optimized for a constraint AI doesn't have

The original case for microservices was largely organizational: let many teams ship independently without stepping on each other. That's a real benefit for humans, at scale.

But an AI agent's bottleneck isn't team coordination. It's context. An agent is only as good as what it can see and hold at once. And microservices are, by design, an architecture of hidden context:

• The logic for one user action is smeared across N repositories. To change a behavior, the agent has to discover, clone, and correlate code it can't see from where it started.
• A function call became a network call. The agent can read a function and reason about it; it cannot "read" a flaky gRPC hop, a retry storm, or a partial failure between services.
• Eventual consistency replaced transactions. The agent can't reason cleanly about state that's correct "soon."
• There's no single stack trace. When something breaks, the truth is spread across logs in five services.

These are the same costs we wrote about in our trip to "microservices hell": the network tax, the observability tax, the eventual-consistency headache. For a human team they're an operational drag. For an AI agent they're a reasoning wall, because the information it needs to be correct is precisely the information the architecture hides.

A modular monolith is an agent's best-case environment

Flip every one of those and you get the modular monolith, with strong module boundaries inside a single deployable:

• One repository = one context. The agent can load the whole picture: the call site, the function, the data model, the test, in one place. Repository-level understanding, the thing every 2026 agent is racing to do better, is trivial when there's one repository.
• In-process calls. A call is a call: typed, traceable, refactorable. The agent can follow it and change both sides atomically.
• Real transactions. State is consistent now, so the agent's mental model matches reality.
• One stack trace. When a test fails, the agent sees the whole failure and can iterate, which is exactly how agentic coding loops work.

The modular monolith keeps the design benefit of microservices (clean separation, clear boundaries) while removing the operational fog that both humans and agents trip on. You get roughly 90% of the architectural benefit at about 10% of the cost, and now there's a second reason it matters: it's the difference between an agent that can safely refactor your system and one that flails across repos it can't hold in its head.

"But our agents will just handle the complexity"

The hope is that agents get good enough to manage distributed systems for us. Maybe, eventually. But today, handing an agent a microservices estate mostly multiplies the surface area where it can be confidently wrong, and distributed-systems bugs are the most expensive kind to be wrong about. Giving the agent a smaller, coherent world isn't a limitation; it's how you get trustworthy output. The teams getting the most out of agents in 2026 aren't the ones with the most services. They're the ones whose codebase an agent can actually understand.

When you should still split (the rule hasn't changed)

This isn't anti-microservices zealotry. Split a module into its own service when you have a clear, painful, obvious reason: a component with a wildly different scaling profile, a hard security or compliance isolation boundary, or a team that genuinely must deploy on its own cadence. That's a refactoring step you earn, not a starting point, and not a default you adopt because a conference talk said so. Start with the modular monolith; extract a service the day a specific module forces your hand, and not before.

The takeaway

Microservices solved a human-team problem and charged an operational tax to do it. AI agents don't have the problem, yet they pay the tax twice, because the architecture hides exactly the context they need to reason. If you're rebuilding your team around AI agents in 2026, the highest-leverage architectural decision you can make is to give them a codebase they can hold in one head: a modular monolith.

We build this way on purpose, on production systems where an agent (and a new senior engineer, and an auditor) can understand the whole thing. If that's the kind of software you need built, here's how we do it.

What's your experience letting agents loose on microservices vs a monolith? I'd genuinely like to hear where this breaks.