Bringing AI Sprawl Under Control: An Enterprise Implementation Guide for the Agentic Economy — September 3, 2026
The proliferation of generative AI tools, embedded AI capabilities and independently developed agents is creating a new management challenge for enterprise technology leaders. Experiments that begin as relatively isolated investments can become persistent departmental capabilities, while consumption-based pricing, access to enterprise data and autonomous actions create financial and operational dependencies that may be difficult to see from the center of the organization.
Based on insights from a BizTechReports executive interview with Tiago Azevedo, CIO of OutSystems, this implementation guide provides a framework for moving from distributed AI experimentation toward a more deliberate enterprise operating model. The objective is to establish the visibility, architectural controls and economic discipline needed to manage AI at scale while preserving the ability of business and technology teams to experiment.
1. Establish Visibility Across the AI Estate
The first step is determining what is already operating across the organization. An enterprise AI inventory should extend beyond officially approved generative AI platforms. It should include departmental experiments, embedded AI capabilities within SaaS applications, internally developed agents, externally acquired agents, foundation models, specialized models and AI capabilities incorporated into development environments.
This exercise should also distinguish between experiments that have ended and those that have quietly become part of everyday operations. An AI initiative does not need to reach enterprise-wide production to become operationally important. A departmental proof of concept used every day may create dependencies that need to be managed even if the organization never formally designated it as a production system.
For each significant capability, organizations should document its owner, users, purpose, underlying model, data dependencies, integrations, consumption costs and operational status. The goal is visibility because enterprises cannot rationalize an AI portfolio they cannot see.
2. Reconcile Business Transformation With Technology Modernization
AI initiatives frequently emerge from different parts of the enterprise for different reasons. Business leaders may use AI to automate workflows, improve customer interactions or redesign operating processes. Technology organizations may simultaneously apply AI to software development, application modernization, infrastructure operations and service management.
Both streams can create value, but problems emerge when they develop independently without a common architecture or transformation agenda.
CIOs should establish a recurring process for comparing business-led and IT-led AI initiatives. The objective should be to identify overlapping requirements, shared data dependencies, duplicated investments and capabilities that could be developed once and reused across multiple functions.
This requires connecting distributed experimentation to a common enterprise architecture and transformation agenda.
3. Focus on Economic Visibility
Early experimentation often benefits from allowing many ideas to develop simultaneously. That approach becomes harder to sustain once usage begins accumulating across an enterprise.
Azevedo described the early period of AI experimentation as a “let 1,000 flowers bloom approach,” in which organizations provided broad access so employees could discover useful applications. The problem emerges when hundreds or thousands of individually reasonable decisions accumulate into an unexpectedly large enterprise expense.
Consumption-based economics make traditional seat-based software budgeting insufficient for some AI workloads. Organizations therefore need visibility into usage as well as contracts.
CIOs and CFOs should establish cost reporting that identifies consumption by model, application, agent, department and use case wherever technically feasible. Unusual increases should be detectable before they become material budget events.
The objective should also be economic optimization rather than indiscriminate cost reduction. An expensive AI workload that produces substantial business value may be justified. A cheaper workload duplicated across 20 departments may represent a greater opportunity for rationalization.
4. Match Models to Workloads
The most capable model is not necessarily the appropriate model for every enterprise task. Organizations increasingly have access to multiple commercial foundation models, specialized models, open-source alternatives and models available through cloud platforms. Those options can differ significantly in cost, performance, latency, security characteristics and suitability for particular workloads.
Enterprises should establish explicit criteria for matching models to use cases. Routine summarization or classification may not require the same model used for complex reasoning. Coding assistance may require different capabilities than customer service. Some workloads may justify premium models, while high-volume, relatively predictable tasks may be more economically served by smaller alternatives.
Model selection should therefore become an architectural and financial decision rather than an individual developer preference.
Organizations should periodically reevaluate these decisions because model capabilities, pricing and performance are evolving rapidly.
5. Identify Common Capabilities and Build Them Once
AI sprawl becomes particularly expensive when multiple teams independently solve the same problem. Once an enterprise has visibility across its AI estate, architects should look for repeated use cases, integrations and technical components.
If numerous departments need an agent to retrieve information from the same enterprise system, organizations should consider creating a reusable access mechanism rather than allowing each team to develop its own connection. The same principle can apply to authentication, logging, model access, data retrieval, monitoring and commonly used business functions.
This represents selective centralization. Business teams can retain the ability to create applications and experiment with agents while consuming reusable components established by enterprise technology teams. The architecture becomes a mechanism for accelerating distributed innovation rather than simply restricting it.
6. Create an Enterprise Catalog for Agents and Their Tools
As agents become more capable, inventorying the agent itself is insufficient. Agents depend on tools that allow them to retrieve information and perform actions. Those tools may interact with application programming interfaces, Model Context Protocol (MCP) servers, databases, enterprise applications and other services.
Organizations should therefore maintain a continuously updated catalog that connects each significant agent to the resources required for it to operate.
That catalog should document what the agent does, which models it uses, what tools are available to it, what enterprise systems those tools access, what data can be retrieved and what actions the agent is authorized to perform.
The catalog can also help identify duplicate agents and reusable tools while providing security, architecture and operations teams with a common view of the agentic environment.
7. Extend Identity and Access Management to Agent Actions
Agentic systems introduce an important identity problem. An agent may be acting autonomously, but it is typically acting on behalf of a person, role, department or business process.
Enterprises need explicit policies governing how agents inherit authority from the people, roles or processes they represent.
An agent assisting a salesperson, for example, should not automatically receive access to every record available through a CRM platform. Its access should reflect the employee's authorization, the purpose of the agent and the specific actions required to perform the task.
The same principle applies when agents write information into enterprise systems or initiate transactions.
Organizations should distinguish between permission to retrieve information and permission to act. Higher-impact actions may require additional authentication, approval or human intervention.
8. Build Deterministic Boundaries Around Nondeterministic AI
Generative and agentic AI systems are inherently nondeterministic. Enterprises should design architectures that account for that characteristic rather than assume it can be eliminated.
Azevedo's discussion of AI-assisted software development illustrates the principle. Natural language can be used during the creation process while deterministic rules govern portions of the resulting application environment.
The same principle can be applied more broadly to enterprise agent architecture. Organizations should identify where flexibility is valuable and where predictable rules are required. AI might interpret a request, summarize information or recommend an action, while deterministic software controls authorization, transaction limits, data validation or execution.
This creates boundaries within which nondeterministic systems can operate without giving them unrestricted authority over deterministic business processes.
9. Define Human-in-the-Loop Thresholds by Consequence
Human oversight should reflect the consequences of an agent making an error. Organizations should classify agent actions according to operational, financial, security, regulatory and reputational impact. Low-consequence activities may be appropriate for greater autonomy. Activities involving significant financial transactions, sensitive data, regulatory obligations or material customer consequences may require human approval.
The objective is not to require human review of every AI-generated action. Doing so could eliminate much of the productivity value organizations are attempting to capture.
The more useful question is what happens when the agent is wrong. The potential consequences of an error should determine the agent's level of autonomy and where human approval or escalation mechanisms are required.
Organizations should also compare agent performance with the existing human process. A nondeterministic system should not automatically be rejected because it occasionally makes mistakes, especially if the existing process produces errors at a higher rate. Having the correct human-in-the-loop safeguards in place reduces the likelihood that those mistakes will persist at a dangerous level.
10. Manage AI as a Continuously Changing Portfolio
Enterprise AI architecture should not be treated as a one-time implementation. Models will improve. Pricing will change. New agents will emerge. Experiments will become operational tools, while other capabilities will become redundant or obsolete.
CIOs should establish recurring portfolio reviews that examine usage, cost, performance, duplication and business outcomes across the AI estate.
These reviews should also establish clear criteria for retiring systems. Experiments that no longer generate sufficient value should be shut down, while successful departmental capabilities can be evaluated for broader adoption. The result should be a continuous cycle of experimentation, measurement, rationalization and reinvestment.
This also changes the CIO's role. Azevedo describes an emerging responsibility for the CIO as a “master architect” capable of creating an environment in which business teams can move quickly without creating an unmanageable collection of agents, models, tools and integrations.
The objective is an enterprise architecture capable of accommodating continuous experimentation while making its costs, dependencies, risks and results visible enough to manage. That architecture should provide centralized visibility and reusable controls without requiring centralized ownership of every AI initiative.
Executive Implementation Checklist:
Inventory production AI, departmental experiments, embedded SaaS AI and internally developed agents.
Identify ownership, users, models, integrations, data dependencies and costs for significant AI initiatives.
Compare business-led AI initiatives with IT-led modernization programs to identify overlap, duplication and shared dependencies.
Establish consumption reporting by model, workload, department and use case where possible.
Define criteria for matching model capabilities and costs to individual workloads.
Identify commonly required AI capabilities that can be developed once and reused.
Maintain a current catalog of enterprise agents, tools, MCP servers and system dependencies.
Define how human identity and permissions extend to agents acting on behalf of employees.
Separate data-access permissions from permissions to initiate actions or transactions.
Establish deterministic controls around high-consequence processes.
Define human-in-the-loop requirements according to the potential impact of errors.
Measure agent performance against the human or technology process being replaced or augmented.
Review the AI portfolio regularly for duplication, cost, performance and business value.
Establish criteria and procedures for retiring unsuccessful, redundant or economically unjustified AI initiatives.
Treat enterprise architecture as an enabling mechanism for AI innovation rather than simply a control function.
###