Google's agentic orchestrator doesn't need microservices

Google released an open agentic orchestrator, and the first thing everyone wants to know is how to deploy it. The loudest replies say microservices. The better answer is one process and one database.

That choice decides whether you spend your time building or debugging network partitions. For an agent pipeline with shared state and tight latency needs, distributed services are the worst possible fit.

What Happened

Google's release of an open agentic orchestrator set off the usual deployment argument, and a large share of the replies pushed microservices as the obvious answer. The counter-argument is that an agent pipeline keeping shared state with tight latency needs is the worst possible fit for distributed services — you will spend more time debugging network partitions than building anything useful.

The recommendation is to start with a monolith instead: one process, one database, and SQLite if traffic allows it. Extract the one hot path later, once you have actual numbers proving it hurts.

Why It Matters

Premature service splitting is just tech debt with extra network hops. The cost arrives long before any benefit does, and it arrives as time you never get back. Ship the thing first, keep it in one process, and let real measurements tell you when to break it apart — not instinct.