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 is 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 time.
The spring was smart. The containment was genius: 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.
┌──────────────────────────────────────┐ │ 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.
Trigger Happy
There's a database 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, 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.
Your Agents, or Theirs
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. And like any mainspring, the power is the easy part. 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. This one you can't, because the deepest problem is ownership. None of these are your agents. They belong to the vendor, built for the vendor's product and tuned to the vendor's surface. The vendor wound that spring for their watch, not yours. Wire thirty of them into your company and you haven't built an AI strategy; you've rented thirty other companies' strategies and turned them loose in your business.
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 with a real mandate: which agents you let in, what they touch, where the boundaries sit, what gets turned off. And, more to the point, which agents you build for yourself, designed around your work and your data, meeting your people on a surface you actually control. The escapement, owned on purpose.
That function sets the agent strategy and owns it. Its job is to partner across the company and design one orchestrated system instead of thirty disconnected ones, then make the 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.
Your vendors wound the spring. The escapement is on you.
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.