From Ticket Chasing to Evidence-Grounded Change Control

Executive Snapshot

• Client type: Mid-sized regional colocation provider operating three continuously available facilities
• Industry: Data-center infrastructure and managed colocation
• Core problem: Production changes crossed shared network, power, cooling, access, scheduling, customer, and SLA dependencies, but the evidence was fragmented across operational systems and informal records
• Why agentic AI: The work required stateful retrieval, cross-domain dependency reasoning, iterative clarification, specialized handoffs, and controlled escalation rather than a single fixed automation
• Deployment stage: Prototype
• Primary result: The proposed operating model moves evidence assembly and coordination ahead of approval while preserving human authority over production changes, emergency work, shutdowns, external commitments, and SLA risk

1. Business Context

NorthBridge Data Centres operates three regional facilities serving roughly 180 enterprise and public-sector customers across about 1,400 active racks. Each month, its teams handle hundreds of planned changes and a smaller stream of emergency work involving equipment installation, power increases, cross-connects, network maintenance, access requests, and facilities interventions. A single request may touch the IT service-management platform, DCIM, building-management telemetry, network-management tools, the CMDB, access-control records, electrical one-lines, rack diagrams, customer restrictions, email threads, and engineer notes. Delays matter because incomplete reviews postpone customer deployments; errors can remove redundancy, exceed power or cooling headroom, affect another tenant, violate a notification period, or force an emergency rollback.

2. Why Simpler Automation Was Not Enough

The workflow did not fail because NorthBridge lacked tickets, dashboards, or threshold alarms. It failed at the joins between them. The request might name one rack while the real impact ran through an upstream PDU, an active UPS maintenance plan, a shared cooling zone, a supposedly redundant circuit using the same physical route, and a customer blackout recorded outside the ticket. Fixed scripts could validate known fields, but they could not reliably gather new context, revise an impact hypothesis, ask for clarification, and route different questions to network, facilities, security, operations, and account owners.

Analytical point — coordination compression with bounded agency. The selected research suggests that the strongest organizational contribution does not come from letting agents make more high-stakes decisions. It comes from combining tool-grounded reasoning, specialized agent roles, graph-based retrieval, telemetry-backed scenario analysis, and low-cost human intervention around one versioned evidence state.¹²³⁴⁵ NorthBridge therefore designed the agents to compress search and handoff work, not to replace accountable change authority.

3. Pre-Agent Workflow

1. Intake and clarification. A customer, project manager, network engineer, or facilities engineer opened a ticket. The change manager categorized it, checked whether scope, timing, implementation, rollback, access, and affected assets were complete, and returned it through comments or email when details were missing.
2. Manual evidence gathering and impact discovery. The change manager and senior engineers searched the ITSM record, DCIM, BMS, NMS, CMDB, diagrams, access systems, account notes, and local engineer records. Network engineers traced circuits and redundancy; facilities engineers calculated power and cooling exposure; security reviewed vendor access; account managers checked customer restrictions and SLAs.
3. Window and plan assembly. The change manager reconciled maintenance calendars, staffing, vendor availability, customer blackout periods, and overlapping facilities work. The engineering owner produced the implementation, validation, stop, and rollback plan.
4. Review and authorization. Findings were consolidated from ticket comments, spreadsheets, diagrams, calculations, and email. Domain owners signed off, and the change advisory board approved, rejected, or returned the change for revision. Production approval and risk acceptance were human decisions.
5. Execution, exception handling, and closure. Technicians executed the approved runbook while the NOC and facilities teams watched service, network, power, and thermal signals. An authorized leader decided whether to continue, stop, shut down equipment, roll back, or initiate emergency work. After validation, staff manually collected logs, screenshots, photographs, test results, and access records before updating configuration records and closing the ticket.

Key pain points:

• The same fact was repeatedly searched, restated, and reconciled by different teams.
• Dependency quality depended heavily on senior-engineer memory and the freshness of diagrams and configuration records.
• Conflicts were often discovered late—during CAB review, final readiness checks, or the maintenance window itself.
• Customer notifications and post-change evidence were reconstructed from the final ticket rather than generated from a shared, continuously updated case state.

4. Agent Design and Guardrails

• Inputs: Change ticket, customer and asset identifiers, ITSM history, DCIM records, BMS telemetry, network topology and alarms, CMDB relationships, access approvals, diagrams, maintenance calendars, customer restrictions, contracts, email or chat records approved for retrieval, and engineer notes.
• Understanding: The Change Request Intake Agent extracts and normalizes the request, identifies contradictions, and produces a source-linked gap list. The Infrastructure Dependency Mapper builds a typed impact subgraph connecting racks, devices, ports, circuits, carriers, PDUs, UPS systems, cooling zones, access zones, customer services, SLAs, and overlapping work. Graph retrieval is used to return the smallest relevant evidence set rather than flattening the entire infrastructure model into a prompt.³
• Reasoning: The Power and Cooling Capacity Reviewer applies deterministic engineering calculations to current load, reservations, incremental demand, upstream aggregation, redundancy exposure, temperature history, and cooling-zone conditions. A validated digital twin can add bounded “what-if” analysis, but it does not replace approved thresholds or engineering judgment.⁴ The Maintenance Window Coordinator checks blackout periods, facilities work, staffing, escorts, vendors, carriers, and NOC coverage.
• Actions: Agents create a versioned review dossier, route domain-specific sections, propose feasible windows, draft customer notices, create coordination tasks, assemble readiness evidence, and collect post-change records. Tool actions are read-only or draft-producing until the relevant human approval is recorded.
• Memory/state: One change dossier holds provenance, confidence, assumptions, accepted corrections, dependency versions, calculations, reviewer decisions, communications, execution events, and pre/post evidence. Interleaved reasoning and retrieval allow the dossier to be updated when a reviewer corrects a relationship or a monitoring observation changes the plan.¹
• Human review points: Engineers validate uncertain or high-impact dependencies; domain owners sign off their findings; the CAB or delegated authority approves production work; account and technical owners approve external notices; the change leader makes the final go/no-go decision; authorized humans decide on shutdown, rollback, emergency action, and SLA-risk acceptance; the change manager accepts closure.
• Out-of-scope actions: Agents cannot operate breakers, shut down customer equipment, change production network configurations, expand the approved scope, waive policy, accept customer risk, make binding SLA commitments, or close a materially noncompliant change.

The six-agent design uses role-specific handoffs rather than one general chatbot. Multi-agent orchestration research supports combining differently configured agents, tools, and human inputs, but also warns that external actions require traceability and safeguards.² NorthBridge therefore treats the agent conversation as working coordination, while the structured dossier—not free-form dialogue—is the operational record.

5. One Workflow Walkthrough

A financial-services customer requested four high-density GPU servers, more rack power, and two redundant network connections during a Saturday window. The Intake Agent assembled the ticket, rack record, recent alarms, access request, account restrictions, and existing maintenance schedule, then flagged an incomplete rollback test and inconsistent circuit identifiers. After the requester clarified the plan, the Dependency Mapper showed that the rack had reserved capacity but shared an upstream distribution unit near its operational limit; it also found that the proposed network paths converged on the same physical route. The Capacity Reviewer connected the request to recent cooling-zone temperature alerts, while the Window Coordinator found overlapping UPS maintenance and a neighboring healthcare customer’s blackout.

Network and facilities engineers reviewed the source-linked graph, corrected one stale circuit edge, and revised the power and routing plan. The CAB approved the revised scope for a later window. The Notification Drafter produced customer-specific notices, which the account manager and technical owner approved. Before execution, the Evidence Collector captured the approved plan and baseline telemetry. Technicians performed the work under human control; the NOC monitored the agent-prepared watchlist. Post-change tests, telemetry, photographs, access logs, and configuration deltas were assembled into the closure package, leaving an auditable path from request to decision to outcome.

6. Results

• Baseline period: To be established through an initial observation period of the existing workflow
• Evaluation period: Proposed controlled pilot before broader deployment
• Workflow scope/sample: Normal changes involving at least two of network, power or cooling, customer impact, access, or maintenance scheduling; emergency authority remains outside autonomous execution
• Process change: Replace repeated manual searches and document assembly with one provenance-linked dossier; measure submission-to-approval time, reviewer effort, clarification loops, returned requests, and late rescheduling
• Decision/model change: Surface dependency conflicts and capacity exposure before CAB review; measure confirmed conflicts found pre-approval, false-positive alerts, reviewer corrections, and completeness of implementation and rollback evidence
• Business effect: Target fewer change-related incidents, notification misses, emergency rollbacks, and audit reconstruction hours without reducing human accountability
• Evidence status: Planned; no production benefit figures are claimed

The immediate deliverable is therefore an operating-model result rather than a validated financial result: evidence that used to be assembled separately by each function is prepared once, reviewed by the accountable specialists, and carried forward into execution and closure. Production claims should be made only after the pilot establishes a baseline and measures both speed and error trade-offs.

7. What Failed First and What Changed

The first prototype design treated every inconsistent field and low-confidence dependency as a separate interruption. Reviewers would have been asked to approve too many small points, reproducing the coordination burden in a new interface. This risk is consistent with human-in-the-loop agent research: users value approval guards for consequential actions but can find excessive requests disruptive, and long traces can be difficult to review.⁵

NorthBridge changed the design in three ways. Conflicts are grouped into decision packets; interruptions are triggered by risk and materiality rather than uncertainty alone; and each reviewer sees only the sections within their accountability. Human corrections update the versioned dependency model and re-run only affected analyses. A remaining limitation is unavoidable: stale configuration data and undocumented physical work still require engineers or technicians to inspect and correct the record.

8. Transferable Lesson

• Automate evidence movement before decision authority. Retrieval, reconciliation, drafting, routing, and evidence capture are strong agent tasks; production approval and irreversible action remain accountable human work.
• Give specialized agents one shared state. Role separation helps only when every handoff uses the same provenance-linked dependency, calculation, decision, and evidence model.
• Place review where risk changes. Ask humans to resolve ambiguity, validate material dependencies, authorize high-consequence actions, and judge exceptions—not to supervise every routine retrieval step.

This case shows that agentic AI works best in operational change control when it turns fragmented coordination into a traceable evidence loop while leaving consequential authority exactly where the organization can govern it.