Nanoservices and AI: Why the Anti-Pattern Becomes the Architecture
Why nanoservices, once an antipattern, are the architecture AI-driven development requires.
Why nanoservices stop being an anti-pattern
While AI agents can now write high-quality applications autonomously without anyone ever seeing the code, organizations remain accountable for their output. In order to govern this, verification has to be possible from the outside. This is a new structural constraint for software architecture: accountability without visibility. The structure this points to is one that has been warned about as an anti-pattern for many years: nanoservices.
What is a nanoservice
Arnon Rotem-Gal-Oz coined the nanoservice as an anti-pattern in his book SOA Patterns (Manning, 2012). His definition is purely economic: a service whose overhead (communications, maintenance, etc.) outweighs its utility. Granularity is not part of the definition. He is explicit on both sides: a single-operation service with rich internals — his fraud detection example, where the innards involve rule engines, blacklist matching, and complex decisioning — is not a nanoservice because the utility justifies the overhead. Conversely, a service with a comprehensive contract can still be a nanoservice if it becomes a central bottleneck whose cost outweighs its contribution. The definition cuts on the ratio, not on the granularity.
In the SOA era these two were nevertheless inseparable in practice. At single-operation granularity, the overhead almost always outweighed the utility, so the label “nanoservice” attached itself to fine granularity even though the definition cut elsewhere. What that label fused together was an economic condition and a granularity at which the condition predictably held. The granularity is a structural property. The economic condition is a product of the era’s constraints. They are not the same thing, and if the condition changes, the granularity remains but the label, by the definition’s own terms, no longer applies. Since then, much has changed.
Evolution of nanoservices overhead
Four costs grounded that economic condition: network, operational, development, and design (fragmented logic). All four were too high for single-operation services, which is what made the label apply at that granularity in the first place.
Three of them have collapsed — on different timelines, for different reasons. One has not. Network and operational overhead dropped over fifteen years and that trajectory enabled microservices, not nanoservices. The cost AI uniquely collapses is development overhead, and that is what tips the ratio at single-operation granularity. Design overhead remains, and at nanoservice granularity it gets harder, not easier.
The SOA era’s network pain was specific and measurable. SOAP used verbose XML serialization with WSDL contract definitions and envelope wrappers, and communication was typically WAN-centric, crossing network boundaries between organizations or data centers. Every service call incurred serialization, OS network handoff, protocol translation, wire travel, and the same chain in reverse — what Rotem-Gal-Oz called a “significant performance nightmare,” rooted in violating two of the fallacies of distributed computing: assuming bandwidth is infinite and transport cost is zero.
Then and now
Over the past fifteen years, REST replaced XML with JSON, reducing payload size and eliminating the WSDL overhead. gRPC went further with compact binary serialization over multiplexed connections. More fundamentally, modern cloud deployments moved service-to-service communication from WAN to intra-region, and often intra-VNet or intra-cluster. Service meshes and platform networking absorbed mTLS, routing, retries, and circuit breaking into the infrastructure layer.
This is the trajectory that made microservices viable by roughly 2016. It was not AI-driven. It was infrastructure-driven, and it has been underway for over a decade. The per-call cost has dropped far enough that it is no longer the blocking factor for finer granularity within a cluster.
Management overhead assumed a roughly constant marginal cost per additional service: new server provisioning, new monitoring configuration, new deployment pipeline, new registry entry. Each service had to be tracked in a registry, monitored, configured, governed. In the SOA era, deploying ten services meant ten times the operational burden, and at fine enough granularity the overhead of managing the services exceeded the value they delivered.
Then and now
That linear relationship broke with platform engineering. Containerization and Kubernetes made the marginal cost of the Nth service drop sharply after the initial platform investment. Infrastructure as Code made provisioning repeatable and version-controlled rather than manual. OpenTelemetry established one instrumentation standard, one collection pipeline, one dashboard layer; adding a service no longer requires adding monitoring.
The pattern is the same as with network overhead. The marginal cost curve flattened, and that flattening is what made microservices operationally sustainable. It was not sudden, and it was not triggered by AI. It was a decade-long maturation of platform capabilities.
At nanoservice scale — hundreds or thousands of services — operational overhead is not zero. Service discovery, configuration management, and observability at that density remain demanding. Rotem-Gal-Oz revisited the granularity question in 2025 with AI in mind. He concedes that AI struggles with large solutions and that breaking systems into services makes them more tractable for agents. But he stops at the nanoservice threshold: “cross that threshold into nano-services, and you’re just creating overhead for no good reason.” The anti-pattern verdict, in his view, still holds.
Each service carries a fixed development cost that is independent of how much business logic it contains: project scaffolding, dependency injection configuration, health checks, logging setup, deployment scripts, conversion layers between internal models and contracts. At microservice granularity, this boilerplate is a manageable fraction of the codebase. At nanoservice granularity, it dominates — and this is the cost that tips the ratio at single-operation granularity, specifically because it is the one cost AI collapses.
Then and now
This cost scales linearly with the number of services. Unlike network overhead (addressable through better protocols) and operational overhead (addressable through platform investment), development overhead could not be amortized. Every additional service required someone to write the same scaffolding again.
This is the cost that AI collapses. Repetitive, pattern-following, structurally identical across services: project setup, configuration, infrastructure code, conversion layers. This is precisely the kind of work that AI generates reliably. The per-service development cost that made nanoservices economically irrational for humans approaches zero for autonomous AI agents.
Network and operational costs dropped over fifteen years and that trajectory enabled microservices. Development overhead did not collapse until autonomous agents took over construction, which is why the granularity shifts now and not in 2016.
Rotem-Gal-Oz’s second objection, fragmented logic, was never about cost. It was about cognitive complexity. Business logic scattered across many fine-grained services is hard to reason about, and AI does not solve this. At nanoservice granularity this work gets harder, not easier, because there are more boundaries to define and more interactions to manage.
Then and now
Where to decompose, what each contract should specify, how services compose into a coherent whole: this is design work that requires domain understanding, architectural judgment, and deliberate human decisions. Where do the boundaries fall? How does data flow? How do failures propagate? How do you ensure consistency across services that each own a fragment of a business process?
Design overhead is the cost that persists after network, operational, and development overhead have dropped. It is also the cost that determines whether nanoservices deliver on their promise or collapse into the Knot anti-pattern that Rotem-Gal-Oz warned about.
Nanoservices as AI-native architecture
This is where the argument lands inside emergence theory. Prigogine’s bifurcation framework states that a system reorganizes into a new order when two conditions hold at once: the pressure on the existing structure exceeds what it can absorb, and the cost of the new order falls below a critical threshold.
The pressure is accountability without visibility. A microservice is already small, but it can still bundle multiple operations, contain internal interactions, implicit state transitions, and edge cases that no contract can fully capture. In this state, contract-based verification is structurally incomplete because the contract describes a surface and the surface conceals behaviors that determine outcomes. The nanoservice — one input, one output, one behavior — is the unit at which accountability without visibility becomes achievable.
The cost reduction is development overhead collapsing through AI, on top of the network and operational reductions that platform engineering had already delivered. Both conditions are now true. The granularity does not drift smaller; the system bifurcates.
A category of utility that did not exist in 2012 — exhaustive contract-based verification of code no one will read — was added to the other side of the equation. The anti-pattern was never a property of the granularity. It was a property of the economics, and the economics have changed.
This is also where the argument parts ways with Rotem-Gal-Oz’s own 2025 position. He sees AI as a force for smaller services and acknowledges it changes the economics of boilerplate, but his analysis assumes humans remain in the construction loop, writing and reviewing and reasoning about the code. Under that assumption, fragmented logic still outweighs the utility of finer granularity, and the anti-pattern holds. The constraint identified here only bites when the human steps out of the loop entirely. When the agent builds autonomously and no one reads the code, contract-based verification is not optional. It is the only mechanism left, and it is large enough to tip the ratio.
What this argument does not settle
Two things are worth acknowledging directly. First, no contract literally captures every behavior of a service. Side effects, internal state, error modes, and performance characteristics still escape a signature; smaller granularity reduces the surface but does not eliminate it. Second, if humans no longer read code, someone still has to read the contract. The verification burden does not vanish; it concentrates in specifications, tests, and templates. Both problems belong to the implementation layer rather than to the economic case made here, and both are addressed in the follow-up article: Software Architecture for AI Agents: Designing for Permanent Absence. The argument here establishes that the granularity is now economically rational. The follow-up works through the architecture that makes that granularity actually verifiable.
What this means for DRY, YAGNI, and other human-era verdicts
Anti-patterns are not eternal. They are verdicts pronounced under specific economic and human constraints, and they survive only as long as those constraints do. The verdict on the nanoservice was a verdict on overhead, not on granularity. Three of the four overheads — network, operational, development — that grounded it have now collapsed. The granularity that the SOA generation could see but could not afford is the granularity the autonomous AI agents can.
The label detaches and the structure stays. What follows from that is more interesting than the nanoservice itself. Every architectural verdict from the human-author era was issued under the same set of assumptions: that someone would write the code, that someone would read it, that scaffolding had to be paid for in human hours. Those assumptions are not permanent. The verdicts that depended on them — on DRY, on large classes, on YAGNI, on code comments — deserve the same re-examination this one has just received. Some may turn out to have been verdicts on economics that no longer apply.
Opus 4.7 was used to support formulation. The ideas, framework, and editorial decisions are my own.
Frequently Asked Questions
What is the difference between a nanoservice and a microservice?
A microservice owns a business capability with several related operations behind one boundary. A nanoservice owns a single operation. The difference that matters for this article is verifiability: a microservice bundles enough behavior that its contract cannot fully capture what happens inside, while a nanoservice reduces scope to where the contract exhaustively describes the service.
Should everyone build nanoservices?
If your architecture today fits well with microservices, it is probably a good candidate for nanoservices once autonomous agents take over construction. The reasons people choose microservices over monoliths — independent deployability, team autonomy across bounded contexts, capability-specific scaling, independent evolution — all carry over. The transition is from multiple operations per service to one. If those reasons led you to microservices today, the structural properties that make nanoservices a natural next step apply when accountability without visibility becomes the constraint.
Are nanoservices the same as serverless functions?
No. Serverless functions are a deployment model — code that runs on demand without managing infrastructure. Nanoservices are a logical architecture — one operation, one contract, one owner. A nanoservice can be deployed as a serverless function, a container, or a module within a modular monolith. The deployment boundary is a separate decision from the logical decomposition.