Nobody sat in a room in 2024 and drew up a plan for twelve AI agents. That number arrived the way most enterprise software counts arrive: a service desk pilot here, an embedded copilot switched on inside the CRM there, a finance team that expensed a seat-based tool without telling anyone, a developer platform that shipped agentic code review as part of a renewal. Two years later, the portfolio exists. It just was not designed.
Salesforce's 2026 Connectivity Benchmark Report, which surveyed 1,050 enterprise IT leaders across nine countries with Vanson Bourne and Deloitte Digital, puts the average enterprise at 12 AI agents today and heading to 20 within two years. The number that should get your attention is not 12. It is that half of those agents operate in isolation, with no data sharing and no handoffs to any other agent. You are paying for twelve, and roughly six of them cannot see anything the others know.
That makes 2026 a portfolio and sourcing year, not a pilot year. The live question is no longer whether agents work. It is which agents should be embedded in the systems you already own, which should sit on a shared platform layer, which should be custom built, and which should be turned off entirely at the next renewal.
Sprawl happened because agents arrived through three doors at once and no single door had an owner. Vendors began shipping agents inside products you had already bought, business units procured point solutions on departmental cards, and internal teams built prototypes that quietly became production. None of those paths ran through a portfolio review, so the count grew without anyone deciding it should.
The vendor door is the largest and the least visible. Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% in 2025. Read that as a supply-side fact about your own stack. Agents are being added to software you already licensed, on the vendor's release schedule, whether or not you asked. Every ERP, CRM, HCM, ITSM, and security platform in your environment is becoming an agent vendor by default.
The underlying condition is integration debt, and it predates AI. The same Salesforce research found enterprise application counts grew from 897 to 957 year over year with only 27% of those applications integrated. Agents inherit that topology. Drop autonomous software into an estate where three quarters of the applications do not talk to each other, and you get isolated agents by construction, not by accident. The isolation statistic is a symptom of the integration number, not a separate problem.
Governance lagged the same way. Salesforce reports that 89% of enterprises now run AI agents while only 54% have a governance framework, and that 27% of enterprise APIs are considered ungoverned. That gap is where the real risk sits, because an agent is only as contained as the API surface it can reach. Before you can consolidate anything, you need to know what exists, which is a discovery exercise: our guide to discovering and inventorying shadow AI agents covers the mechanics of building that list from identity logs, egress data, and expense records rather than from a survey nobody answers honestly.
Agent sprawl is an integration and sourcing problem wearing an AI costume. Consolidation succeeds when you decide sourcing mode per capability (embedded, platform, or custom) and enforce it at renewal, not when you simply delete agents.
Every agent in your portfolio belongs to one of three sourcing modes, and the deciding factor is how differentiated the work is and how much of the required context already lives inside a single system of record. Embedded agents win when the work happens entirely inside one application's data. Platform agents win when the work crosses systems. Custom builds win only when the workflow is a genuine competitive difference and no vendor can reach the data it needs.
If an agent's entire job is summarizing cases, drafting quote language, routing requisitions, or scoring opportunities inside one platform, take the vendor's version. The decision rule we apply: if more than roughly 80% of the data the agent needs already lives in that vendor's schema, buy embedded. You will never beat the vendor on data proximity, permission inheritance, or upgrade path, and you inherit their access controls for free. The cost is lock-in and pricing exposure, which is a contract problem rather than an architecture problem. This is where most CRM and sales AI capability should land for the majority of organizations.
If a workflow touches three or more systems of record, it belongs on a shared platform layer with common identity, logging, policy, and tool access rather than inside any one vendor's agent. Order to cash, employee onboarding, incident to change, and vendor intake all qualify, and letting each vendor's embedded agent stretch outside its own domain is how you end up with six overlapping agents that each own a fragment of one process. That layer is the control point for everything else, which is why an AI gateway acting as a control plane is worth standing up before you scale agent count, and why agent-to-agent interoperability and governance stops being theoretical the moment you have more than a handful.
Build only when the workflow is a source of margin or differentiation, the required data is proprietary, and you can commit to owning evaluation, monitoring, and lifecycle for at least three years. Custom is the smallest bucket and the one most often chosen for the wrong reason. CIO.com's analysis of the build versus buy dilemma at the heart of enterprise AI names the real constraint: vendor-embedded AI almost always requires your data to live in the vendor's cloud, which makes this an architecture question about where the AI layer runs and who controls it, not a procurement one. If you cannot name the person who owns it in year three, do not build it. Where the case does hold, custom AI agents deliver leverage no packaged product will, and they need the same AI DevOps discipline you would apply to any production service: versioning, regression suites, rollback, and observability.
Run it as a mapping exercise before a cutting exercise: inventory every agent, map each one to the business capability it serves, then find the capabilities with more than one agent attached. Consolidate within a capability, never across capabilities, and retire agents by shadowing and decommissioning rather than by switching them off on a date.
The sequence that works in practice:
Sequence the pass around contract dates rather than around enthusiasm. Consolidating a capability nine months before its renewal produces a stranded license. Consolidating it sixty days before renewal produces leverage.
The main trap is that agent pricing compounds in ways seat pricing never did: per-seat fees stack across products that each bundle their own agent, while usage-based pricing scales with agent activity you do not directly control. A per-conversation or per-action meter means an autonomous agent can generate cost without a human initiating anything, which breaks the budgeting assumptions most IT finance models still run on.
Four specifics worth writing into contracts. First, demand usage telemetry you can see in near real time, not a monthly invoice line, and set spend alerts at the gateway. Second, negotiate a cap or a rollover on consumption units so a runaway retry loop does not become a budget event. Third, watch for agent capability being repositioned from an included feature into a premium tier at renewal, and get the current bundling written into the contract itself rather than the order form so a packaging change cannot reprice you mid-term. Fourth, price the human cost honestly: review queues, exception handling, and prompt maintenance are real operating expense, and in the portfolios we have reviewed they are routinely the line item nobody budgeted. Put a named owner and an hours estimate against each surviving agent before you sign.
Consolidation itself creates the leverage. As CIO Dive's reporting on IT leaders grappling with agent sprawl and integration reflects, most organizations are discovering overlap after the fact. Walking into a renewal with a defensible map showing three vendors covering one capability changes the conversation from feature comparison to displacement risk.
Leave alone anything where the agent's value comes from proximity to data that only one system holds, and anything operating under a regulatory or contractual constraint that names a specific vendor or data boundary. Consolidating those creates integration work and compliance exposure that will exceed any license savings.
Specifically, do not merge agents across data classification boundaries just to reduce headcount in a spreadsheet. Do not collapse a clinical, legal, or financial-controls agent into a general purpose one because the general one is cheaper. Do not retire a small, well-governed agent that a single team depends on daily in favor of a platform capability that does not ship for two quarters. And do not consolidate during an active audit window. A slightly larger portfolio that is fully governed beats a smaller one held together by exceptions, which is the practical argument for treating agent operations as a managed discipline rather than a project. That is much of what a managed intelligence provider actually does day to day.
Measure four things: agent count per business capability (target one, tolerate two), percentage of agents with a named owner and defined autonomy level, percentage of agents integrated into shared identity and logging, and total agent spend per unit of work completed. Cost reduction alone is a weak signal, because you can cut spend by cutting capability.
Set the baseline before the pass, not after. The most useful single metric we track with clients is the isolation rate: what share of your agents can hand off to another agent or read from a shared context layer. If Salesforce's benchmark has half of enterprise agents isolated, moving your own figure from 50% to 20% is a more meaningful result than removing four licenses. Pair it with a governance coverage figure given that only 54% of enterprises running agents have a framework at all, and with cycle time on the two or three processes the surviving agents actually touch. That last one is the number the business cares about: if cycle time on those processes did not move, you tidied up the automation portfolio without improving the business.
Re-run the pass every two quarters. With vendors shipping embedded agents on their own release cadence, your portfolio will re-sprawl on its own. Consolidation is not a project you finish. It is a standing review that you attach to your renewal calendar.
Infonaligy is an AI consulting and IT services firm based in Dallas-Fort Worth, delivering remotely to clients nationwide. We inventory agent portfolios, apply the embedded, platform and custom sourcing rule capability by capability, and run the consolidation pass against your renewal calendar so the savings and the governance land together. If you are not sure how many agents you are running or what they can reach, start with an inventory: talk to us about AI consulting or custom AI agents at hello@infonaligy.com or 800-985-1365.
Infonaligy supports IT and business leaders from our Dallas-Fort Worth base, with remote delivery for organizations nationwide.
An Infonaligy engagement starts with a two-week inventory: every AI agent in your environment, what it can reach, who owns it, what it costs, and when its contract renews. From there we apply the embedded, platform and custom sourcing rule capability by capability, and sequence the consolidation pass against your renewal calendar. Vendor-neutral, built on what you already run.
Infonaligy