I Swapped "Service" for "Agent" in a 2016 Design Doc. Most of It Still Held.

Swapping 'service' for 'agent' in a 2016 microservices design doc still reads mostly correct — except in four places where teams are now burning money.

Out of curiosity I took a microservices design doc I wrote in 2016 and replaced every "service" with "agent". Most of it still read correctly. Comforting or troubling, depending on how much of the last two years you spent thinking you had to start over.

Not the first time. Agents are the second coming of the business rules engine — Drools, 2005: pull the logic out of the code into a data artifact, then nobody can explain why a rule fired. Same pattern, same failure mode, better marketing.

So the years you spent learning to decompose a domain, define a contract and externalize state did not evaporate. Idempotency still decides whether a retry heals you or corrupts you. That judgment is your most transferable asset.

But the dictionary lies in four places, and that's where teams are burning money.

1. Control flow became unreliable. Two decades of patterns for a flaky network — retries, circuit breakers — all assumed reliable branching and unreliable I/O. Agents invert it. The network is fine; the if-statement is 95% accurate. The fix isn't a better prompt. It's designing so a wrong branch is cheap, visible and reversible.

2. The cost of a call inverted, which kills "micro." A function call is free, so microservices pushed toward finer decomposition. An agent hop takes seconds and costs money. The economics push the other way: fewer agents, doing more. "Micro-agents" is where my own analogy breaks — decompose agents like you did services in 2018 and your latency and invoice will teach you inside a quarter.

3. Data became control. Microservices separated data plane from control plane. An agent reads retrieved content and instructions through one channel. Prompt injection is to agents what SQL injection was to web apps in 2003, and we're still at the "just concatenate the string" stage.

4. Testing became statistics. You can't assert equality on a nondeterministic system. Pass/fail becomes pass-rate; a regression is a distribution shift, not a red X. That isn't a new tool. It's a new profession.

The practical version: draw boundaries around business capabilities, not prompts. Cap iterations and tokens on every loop, like you time out every HTTP call. Externalize state — the context window is RAM, not a database. Deterministic code where you can, LLM decisions where you must, because every branch you hand to a model is a branch you can no longer prove.

Number four is the uncomfortable one. Everything else is a translation of something we knew, so experience covers it. That one isn't — it asks for probability, sampling, evaluation design. Most of us with a CS degree and fifteen years of production skipped exactly that. Which is the next post.