In December 2025, OutSystems surveyed 1,900 IT leaders. 96% already had AI agents running somewhere in the business. 94% said the sprawl those agents created was making things worse: more complexity, more technical debt, more security exposure. Both numbers came from the same companies. That gap is the problem with how most teams have adopted agents so far.
A chatbot is not an architecture
The fastest way to get an agent into production is to stand one up next to a single workflow. Sales wants lead triage, so sales gets a bot. Support wants ticket summaries, so support gets a different bot. Six months later there are eleven of them, each with its own API keys, its own prompt, its own copy of the customer record, and nobody who can say what all eleven are allowed to touch. In the OutSystems data, 38% of organizations reported mixing custom-built and pre-built agents in exactly this way. Only 12% had put a platform underneath them.
Why disconnected agents become a liability
A standalone chatbot answering questions is low-stakes. The risk shows up when agents start taking actions: issuing refunds, updating records, sending email on your behalf. Each agent you add multiplies two things at once. The number of credentials floating around your stack, and the number of code paths that can reach a production system without a human in the loop. When one of them misbehaves, you often cannot tell which one, because there is no shared log and no shared identity. The agents were built to ship fast, not to be audited.
An agent that can write to your CRM is not a feature. It is a service with production access, and it deserves the same scrutiny as any other service with production access.
Orchestration is the control plane
The alternative is to treat orchestration as infrastructure rather than an afterthought. A control plane sits between your agents and the systems they act on, and every tool call routes through it. That single chokepoint is where the safeguards live:
- Scoped permissions. An agent gets access to the three endpoints its job needs, not a blanket API key. Revoking that access is one change in one place.
- Shared identity and an audit log. Every action carries which agent did it, on whose behalf, and why. When something goes wrong, the trail already exists.
- Human-in-the-loop as a designed step. High-consequence actions pause for approval by default, and the approval is recorded next to the action it authorized.
Treat agents as software
A developer-led team builds agents the way it builds anything else that runs in production. Prompts live in source control, so you can see what changed and roll it back. Tool contracts are tested, so an agent cannot call an endpoint with the wrong shape and corrupt data. Behavior is observable, so you can watch latency, error rates, and how often a human override fires. None of this is exotic. It is the discipline that keeps a payments service reliable, applied to a thing that happens to talk.
The teams in the OutSystems report who felt in control were not the ones with the fewest agents. They were the ones with a platform to manage them. Governance did not slow them down; it was what let them keep adding agents without the blast radius growing each time.
If you already have sprawl
You do not have to rebuild everything. Inventory what is running first, because most teams are surprised by the count. Pull the agents with production write access to the front of the line, since that is where an incident hurts most. Put those behind a single point of access with real permission scoping and logging. Then make the next agent the easy one to build the right way, so the platform becomes the default path instead of the exception.
At Foundation AI we build agents as orchestrated systems from the first one, because retrofitting governance onto eleven loose chatbots is the more expensive project. If your agent count is climbing faster than your ability to answer “what can each one do,” let’s talk.