If you've logged into any enterprise tool in the last six months, you've seen them. Little cheerful agent boxes popping up in your sidebar. "Add this agent." "Try our new assistant." Slack has them. GitHub has them. Notion has them. Your CRM has them. Your finance tool has them.
Nobody asked you. They just appeared.
I get it. GenAI is the wave, and every enterprise vendor is racing to ride it and become the toll-taker of the new infrastructure. So they're cramming agents into the existing surface area of their products, hoping you'll start using them and forget they were ever optional.
But I think we're about to make the same mistake we've made twice before. And if you're a CIO, or anyone responsible for how systems fit together inside a company, it's going to matter how deliberately you handle what comes next.
Let me borrow a phrase. My good friend Dan Perrera has the best name I know for the kind of system we keep building by accident: a box of springs. To explain why it's the right name, I have to talk about springs for a minute.
What a Spring Is For
A spring stores force and gives it back on command, predictably: pull twice as hard, get twice the give. That's what makes it trustworthy enough to run a watch.
Look closer at that watch. The mainspring is the muscle: wound tight, all stored force, no manners. Left alone, it dumps everything at once and spins the gears into a useless blur. What holds it back isn't another spring; it's a mechanism called the escapement. An escape wheel, whose teeth are caught and released one at a time by a rocking pallet fork, metering the mainspring's energy into equal, rationed beats. Tick. Tick. Tick. The mainspring is the power. The escapement is the reason you can trust it to tell you the hour.
The genius of the spring was never the tension. Anybody can wind something up. The genius was containment: a known amount of force, released in a known way, inside a known limit.
Take the containment away and you get the opposite. This is what Dan means by a box of springs. It looks orderly: every coil wound tight, every one in its place. Then you reach in. One fires, then the one beside it, then four more, and you're standing in a mess you can't trace.
We've already built two boxes of springs in software. Both times, we kept the tension and threw away the containment. The third is coming.
One Job, One Place
I've been a software guy for 25 years, and the most durable idea I've worked with is also the simplest: every part of a system should have one job, in one place you can reason about. The textbook version is the three-tier stack. Data stores and retrieves. The middle tier holds the business logic. The presentation layer presents. Thirty years on it still holds, because the moment logic smears into places that aren't built to hold it, you lose the thread.
┌──────────────────────────────────────┐ │ PRESENTATION │ │ ui · browser · cli │ └─────────────────┬────────────────────┘ │ ┌─────────────────┴────────────────────┐ │ BUSINESS LOGIC │ │ rules · workflows · code │ └─────────────────┬────────────────────┘ │ ┌─────────────────┴────────────────────┐ │ DATA │ │ storage · retrieval │ └──────────────────────────────────────┘
We have a long history of ignoring that, usually because a clever shortcut is sitting right there. And every time, we end up in the same mess. Two stories.
Trigger Happy
In the relational database world, there's a feature called a trigger. When a row changes, whether an insert, an update, or a delete, the database fires off a stored procedure and runs logic right there, inside the database, at the moment the data moves.
On paper, it's irresistible. You're listening at the system of record, exactly where the truth changes. You can react in the same transaction. You don't have to build a separate event pipeline. The pros write themselves.
In practice, it became an anti-pattern.
Because suddenly your business logic lives in two places: the middle tier, where you can read it, test it, version-control it, and the database, where you can't. New engineers spend hours debugging a feature before someone finally says, "oh, that's a trigger." Side effects fire on bulk loads no one expected. You ship a migration and trip a trigger on the way out. The system grows unintended consequences faster than you can document them.
Don't flame me on this. There are real, good reasons to put logic in the database: constraints, integrity checks, sometimes performance. I'm talking about business logic, the kind that should live where humans reason about it.
That was the first box of springs. Everyone could see the coils. Nobody could see what would fire.
Microservices and the Event Bus
The second story is microservices.
Eight or so years ago, the monolith fell out of fashion. We started carving compute into tiny services with tight inputs and outputs, deployed independently, scaled on demand. Alongside that came the event bus: pub/sub everywhere. Services emit. Services subscribe. The system orchestrates itself.
Each individual service was beautiful. Testable. Self-contained. Easy to reason about in isolation.
The orchestration was a nightmare. What happens when this message is published? Which seventeen services react? In what order? What breaks if service nine is down? The unit of work was clean. The system was a box of springs.
I never fully bought in. The cost of distributed debugging always outpaced the benefit of the abstraction. People who lived inside those systems spent a disproportionate amount of their time hunting through logs across services, trying to understand what their own software did.
Same pattern. Logic spread across too many places. Side effects everywhere. Easy to write. Almost impossible to reason about as a whole.
The second box of springs.
The Third Box of Springs
Triggers were the first box of springs. Microservices were the second. This is the third.
We are about to spread AI agents across every surface of the enterprise, and we are doing it the same way both of those mistakes started. By default. Without a plan. Because the vendor turned it on.
You log into Slack and there's an agent. You log into Notion and there's an agent. GitHub. Linear. Jira. Confluence. Your HRIS. Your CRM. Each one helpful in isolation. Each one operating on its own slice of state. Each one with its own access scope, its own assumptions, its own little stored procedure of "what to do when X."
Multiply that across thirty SaaS tools.
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │SLACK │ │GITHUB│ │NOTION│ │ JIRA │ │ CRM │ │ + ai │ │ + ai │ │ + ai │ │ + ai │ │ + ai │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │ │ │ │ │ ╲ ╲ │ ╱ ╱ ╲ ╲ │ ╱ ╱ ╲ ╲ │ ╱ ╱ ╲ ╲ │ ╱ ╱ ▼ ▼ ▼ ▼ ▼ ┌─────────────────────────────────┐ │ YOUR DATA · YOUR ORG │ │ (each agent firing on its own │ │ schedule, its own scope, │ │ its own assumptions) │ └─────────────────────────────────┘
That is a third box of springs. Bigger than the database one. Bigger than the microservices one. And this time the springs aren't even predictable. A steel coil does the same thing every time, right up until it snaps. An agent gives you no such guarantee. It doesn't fail predictably. It fails creatively.
And this one isn't contained. The first two boxes of springs lived inside a single system: a tangle in one database, or one service mesh, with a lid you could close. This one has no lid. It's spread across every tool your company runs. When it misfires, you don't get bugs in one system. You get them across the whole organization.
Someone Has to Build the Escapement
Every vendor is shipping these agents on by default. Your users see them, click them, start to depend on them, and six months later your system of record has an agent nobody actually chose. It just drifted in.
These tools are mainsprings: powerful, wound tight, full of stored force. But power was never the hard part. Containment is. The vendor wound the spring and walked away, and almost nobody is building the escapement, the thing that turns raw capability into something bounded and auditable, released in beats you can trust.
The first two boxes of springs were problems you could engineer your way out of: move the logic back where it belongs, trace the events, draw the service boundaries differently. The third one looks the same. It isn't.
The fix is organizational. If your company doesn't already have an agent operations function, a team that owns how all of this composes, start building one. Not a committee. A function, accountable for which agents you let in, what they're allowed to touch, where the privilege boundaries sit, and what gets turned off. The escapement, owned on purpose.
That function makes calls, tool by tool. An agent living next to your code, your tests, your review process? I'm enamored with that; the ground was already built for automation. An agent loitering in the channel where your people actually talk to each other? I'm skeptical: let it read and send from the outside, but keep it out of the conversation. An agent quietly editing the wiki that holds your canonical word? That's the trigger problem all over again, and I'd want version history, an audit trail, and an explicit invocation before it touches the store. You don't have to agree with my answers. You have to have answers.
Someone has to lead it. I think that's a CAIO, and I'm one, so discount me accordingly. But the title matters less than the mandate: one person accountable for turning a box of springs into something that keeps time.
These tools are the mainspring. Someone in your company has to own the escapement.
It's still early. The box of springs hasn't fully taken shape yet. We have a real chance to be deliberate this time instead of waking up in three years to write the "why agents-everywhere was an anti-pattern" essay.
I'd like to skip that one.