Microservices, Agents, and What I Am Building Next

For most of my career, microservices were a tax I could not afford alone. The idea is good: break a system into small, independent services, each owning one job, each able to fail, scale, and change without dragging the rest down with it. The problem was the overhead. More services means more deployments, more boundaries to define, more wiring, more ways for the connections between things to break. For a small team or a solo builder, the cost of all that machinery usually outweighed the benefit, and the honest answer was to keep things in one well-organized monolith and not pretend otherwise.

AI agents change that math, and that is why the architecture is back on my mind for what I build next.

What the agents change

The tax on microservices was never really the services. It was the connective tissue: the boilerplate, the deployment pipelines, the glue code, the operational babysitting of a dozen small things instead of one big one. That is exactly the kind of work the cost of which has collapsed. An agent can stand up a service, wire its deployment, write its tests, and connect it to the rest, in the time it used to take to decide whether the effort was worth it.

When the overhead per service drops far enough, the calculus flips. The reasons to want small, independent, isolated services were always sound. It was only ever the price that made them impractical at small scale. Lower the price and a single builder can run an architecture that used to require a platform team.

There is a deeper fit, too. A microservice is, by design, a bounded piece of work small enough to hold in one head. That is also the size of work an agent handles best. An architecture made of small, clearly-bounded units is an architecture you can hand to agents one unit at a time, which means the way I want to build and the way I want to structure what I build are starting to point in the same direction.

Why it fits how I already think

This is not a new instinct dressed in new clothes. It is the same idea I keep circling in everything else.

Breaking a system into bounded services is one more way of making a complex thing legible instead of simple. You do not pretend the system is small. You give it seams, so a human, or an agent, can reason about one part without holding all of it at once. The whole stays complex; each piece becomes comprehensible. That is the entire move I care about, applied to architecture.

It is also antifragile by construction. Isolation means a failure in one service is contained instead of cascading. Redundancy and independent scaling mean the system can absorb a shock in one place and keep running everywhere else. The same logic that makes me hold slack in a portfolio and redundancy in infrastructure makes me want boundaries in a system: not to be efficient, but to survive the part that breaks.

The discipline that keeps it honest

Here is the catch, and it is the same catch as always. The fact that agents make microservices cheap does not make microservices free, and it absolutely does not make them always correct.

There is a failure mode where you decompose a thing into twenty services because you can, and you end up with distributed complexity that is harder to reason about than the monolith you started with. A poorly drawn boundary is worse than no boundary. Splitting a system along the wrong seams gives you all the overhead of distribution with none of the benefit, and now the mess is spread across a network instead of contained in one codebase.

So the rule I am holding onto is the same one I apply to money and to systems generally: robustness before optimization. Start with the simplest thing that works, usually one service, and split only when a real seam reveals itself, when a part genuinely wants to fail, scale, or change on its own schedule. Let the architecture earn its complexity. Do not reach for the sophisticated structure because the tools finally let you. Reach for it when the system is actually asking for it, and not one service before.

What this means for what I build

The practical upshot is that the things I make next, the apps and tools and environments I have been sketching, get to be designed the way I always wanted them designed, in small honest pieces, because the help is finally good enough to make that practical for one person. I get to keep pushing the limits of what a single builder can stand up, using AI as additional hands, and keep the result coherent because each piece is small enough to understand and the seams between them are drawn on purpose.

That is the whole bet I keep making, in one more domain. Not simpler. Legible. A complex system, built in pieces you can actually reason about, that survives the failure of any one of them, and that one person can now hold in their head because they had the help to give it the right shape.

If you want the method underneath the building, it is an AI agent workflow that holds up. For the idea underneath the architecture, it is all the same thing: coherent complexity.