Why Infrastructure Tool Sprawl Is an Orchestration Problem

An application is experiencing intermittent connectivity. Monitoring detects the symptoms. Inventory identifies the infrastructure. An automation workflow can apply a change. Yet an engineer still has to connect those capabilities into a resolution.

This is the operational cost of infrastructure tool sprawl. Each system may be doing its job, while the work between systems remains manual. Adding AI reasoning creates an opportunity to improve that coordination, but the operational process still needs to establish what is permitted, how actions execute, and whether the problem was resolved.

For me, the useful question is how many manual interactions are required to achieve an operational outcome. That gives us a more practical way to assess the architecture than counting the tools in the environment.

The Work Between Systems Is Still Work

The research reflects this challenge. In its observability unification study, Enterprise Management Associates surveyed 356 enterprise IT professionals. Its public findings report that 75% use 4 to 12 observability tools and 55% switch tools 3 to 5 times per incident.

Those findings describe the observability environment. They also raise an architectural question for the broader infrastructure process: how does information from those systems become an authorized, verified action?

In the connectivity incident, an engineer might correlate latency with interface congestion, identify the affected service, inspect recent configuration changes, and determine whether a routing policy is involved. The engineer then has to select a remediation, assess its impact, obtain the required approval, execute the change, and validate the result.

A monitoring platform should provide signals. Inventory should provide context. An existing workflow should execute an established change. The architecture must connect those responsibilities.

Task Automation Needs an Operational Process Around It

A script can retrieve a configuration. A playbook can update a device. An API can create a ticket. These are valuable capabilities, but none of them, by itself, defines how the incident moves from detection to verified resolution.

That process includes dependencies and decisions: which resource is affected, whether a change is authorized, what must be checked before execution, how to handle failure, and what evidence permits the incident to be closed.

Orchestration gives those individual capabilities a shared operational path. It coordinates actions across systems and preserves the requirements that belong to the process. Engineers can then focus on architecture, policy, exceptions, and the decisions that require their judgment.

This distinction becomes more consequential when AI enters the process. A model can select a plausible next action. The operational architecture still has to determine whether that action is appropriate, authorized, and sufficient to achieve the intended result.

Give AI Reusable Expertise and Authorized Capabilities

An AI agent can help investigate unfamiliar symptoms, correlate information, and reason about possible causes. Its usefulness depends on the information and capabilities available to it.

Tools provide capabilities such as retrieving interface statistics, inspecting routing state, querying inventory, or invoking an established workflow. Skills provide operational guidance about how to approach a problem, which evidence to collect, and when to escalate. Context gives the reasoning process relevant infrastructure state and history.

For example, a troubleshooting skill can guide an investigation through reachability, interface health, protocol adjacency, and recent changes. The agent uses tools to collect the corresponding evidence and evaluates what it finds. It should also identify when the evidence is insufficient to support a remediation.

This is a way to make engineering knowledge reusable. Teams can improve a documented diagnostic method instead of embedding a separate version of the same procedure in every prompt or agent.

That separation is central to FlowAI’s agent harness. FlowAI brings together tools, skills, context, and governance within the Itential Platform. It connects model reasoning to scoped infrastructure capabilities and existing automation, giving teams a foundation for operational use.

Follow the Incident Through to Verified Resolution

Consider how the connectivity incident could move through an orchestrated process. This example describes an architectural pattern; the exact actions and controls depend on the environment.

Detect & Establish the Scope

The observability platform detects abnormal latency or packet loss. An operational workflow records the incident and identifies the affected service and infrastructure. Inventory relationships and ownership information establish the scope of the investigation.

Investigate With Relevant Evidence

A troubleshooting agent uses authorized tools to inspect interface statistics, configuration state, and recent change records. Task guidance defines the diagnostic approach. The agent records supporting evidence and explains whether its conclusion is certain enough to propose a remediation.

Evaluate & Authorize the Change

The proposed action is evaluated against the relevant permissions, service dependencies, change requirements, and approval policy. An agent authorized to investigate a device should not automatically inherit authority to modify it. Unresolved questions can return the process to an engineer.

Execute Through Established Automation

Once authorized, an existing workflow performs the change. It handles the required integrations, parameters, pre-checks, error conditions, and configured recovery behavior. The organization reuses the execution capability it has already developed and tested.

Verify the Outcome & Update the Record

The process checks both the resulting infrastructure state and the original service symptom. A successful configuration response does not, by itself, establish that application connectivity recovered. If validation fails, the process follows its defined recovery or escalation path. The incident record reflects what occurred and what remains unresolved.

The systems retain their responsibilities. Monitoring provides signals, inventory provides context, and automation performs established actions. Orchestration connects them through the decisions and evidence required to resolve the incident.

Preserve the Execution Foundation as Models Evolve

Infrastructure teams have invested years in scripts, playbooks, workflows, integrations, and operating procedures. Agent adoption should make those assets easier to use through authorized interfaces.

Rebuilding every capability inside each new agent introduces another maintenance burden: duplicate integrations, separate permissions, inconsistent tool definitions, and different recovery behavior. The same operational knowledge can become fragmented across agent implementations.