The industry spent years telling us microservices were a mistake. Too much overhead. Too much operational complexity. Too many moving parts for too little payoff. The consensus hardened, the monorepo era took hold, and microservices quietly became the thing you admitted to only in legacy codebases.
We think it is time to reopen that debate. Not because the old arguments were wrong, but because the context has changed. Literally.
Context engineering is the new bottleneck
In AI-native development, the quality of your output is a direct function of what you put into the context window. This is not a soft claim. Fill that window beyond what Matt Pocock calls the "smart zone" and your results degrade. The model loses the thread. Suggestions get vague. Completions drift. The code you get back starts to look like it was written by someone who was briefed badly, because it was.
So context engineering, what you include, what you leave out, how you structure the information an AI agent is working with, is now a first-class engineering concern. It sits alongside performance, security, and scalability as something you have to actively design for.
The problem is that most development setups were not built with this constraint in mind.
The monorepo problem nobody is talking about
Take the monorepo. It made sense when the goal was to keep everything in one place, share tooling, reduce duplication, and give developers a single source of truth. Those are real benefits and they did not disappear.
But feed a monorepo into an AI-assisted development workflow and you run straight into the context problem. Your framework configuration is in there. Your CI/CD setup is in there. Your design documentation, your architectural decision records, your test scaffolding. Bundle all of that with an AI harness to enable agentic development and your starting context is already compromised before you have written a single line of new code.
You can mitigate some of this with decision trees in your agentic harness, routing the agent to only the relevant slice of the codebase for a given task. That helps. But it is patching a structural problem with a layer of orchestration logic, and that layer has its own cost.
The question worth asking
Here is where it gets interesting. Microservices, by design, are small and bounded. Each service has a narrow scope. Its codebase is smaller, its dependencies are more explicit, and the surface area an AI agent needs to reason about is dramatically reduced.
That was never the point of microservices. They were designed for independent deployability, fault isolation, and team autonomy. Context window management was not a concept that existed when the architecture was being debated. But the structural property that makes microservices painful in some ways, the fact that they force you to draw hard lines around domains, might be exactly the property that makes them a good fit for how AI agents reason and operate.
So the question is not whether microservices are good architecture in the classical sense. That debate already happened. The question is whether the constraints of AI-native development give us a new reason to draw those hard lines. Whether microservices should make a comeback, not as a distributed systems decision, but as a context engineering decision.
We do not have the answer. You might.
We are posing this as a provocation, not a prescription. The developer community has strong opinions here and we think this is worth a genuine debate.
If you are building AI-native products, if you are already working with agentic harnesses, or if you have hit the context wall in a monorepo and found a way through, we want to hear what you think. Does the architecture of your codebase affect the quality of your AI-assisted development workflow? And if it does, does that change the calculus on how you structure your next project?
The paper said microservices considered harmful. The question on the table is whether that verdict still holds when the thing doing the reasoning is not a human engineer navigating a distributed system, but an AI agent navigating a context window.
Considered beneficial? We genuinely do not know. But we think it is the right question to be asking right now.