Manufacturing: AI Agent Pilot With a Governance Gate

01 · BUSINESS PROBLEM

Diagnostics bottlenecked on the most experienced technicians

When equipment threw alerts, diagnosis depended on correlating sensor readings with maintenance manuals, specs, and the work-order history — knowledge concentrated in the most experienced technicians. Junior staff took longer, escalated more, and occasionally missed steps buried in documentation. The company didn't want an agent that "does maintenance." It wanted a diagnostics copilot: given an alert, pull the relevant manuals, telemetry, and history, and propose a diagnostic plan and work order for a human to approve.

02 · INDUSTRY

Anonymized

Industry

A global manufacturing company — plant operations and maintenance.

Anonymization

Client name and identifying details withheld. Presented as experience informing AnovaCloud's methodology, not as an AnovaCloud delivery claim.

03 · SCALE

Orders of magnitude that shaped the design

Pilot scope

Bounded deliberately: selected equipment classes and plants — narrow enough to govern, representative enough to learn from.

Knowledge estate

Maintenance manuals, equipment specs, sensor telemetry streams, and years of work-order history with technician notes.

Users

Maintenance technicians and reliability engineers — the people whose judgment the agent had to earn, not replace.

04 · CONSTRAINTS

The non-negotiables

• Safety first: the agent could never actuate equipment or change setpoints — proposals only, executed by humans.
• Human-in-the-loop: every proposed work order required technician approval before becoming real work.
• Least privilege: read-only tools, scoped to the pilot's equipment and documents — the agent couldn't reach what it didn't need.
• Auditability: every proposal, approval, modification, and outcome logged — the pilot had to be reviewable end to end.
• Data residency: operational data stayed within required boundaries; no training on company data.

05 · BASELINE

What diagnosis looked like before

An alert fired; a technician pulled up dashboards, searched PDF manuals, and — for the hard ones — found the senior tech who'd seen it before. Work orders were written from experience and templates. The knowledge existed, but it lived in documents, systems, and heads that weren't connected at the moment of need. Mean time to diagnose varied widely with who was on shift.

06 · TARGET ARCHITECTURE

An agent that proposes, never acts

The agent's only tools are read-only: retrieval over manuals and specs, telemetry queries, and work-order history search. The planner agent correlates an alert with documentation and history, then produces a proposed work order — diagnostic steps, likely parts, safety notes — which a technician reviews, modifies, or rejects. Policy guardrails bound the agent's scope (no actuation, no out-of-scope equipment, no unapproved data sources). An eval and red-teaming harness gates releases; the audit trail records every proposal, decision, and outcome so the pilot can be reviewed like an engineering system, not trusted like a colleague.

07 · KEY DECISIONS

The tradeoffs that mattered

08 · IMPLEMENTATION

Phased by risk reduction

09 · GOVERNANCE

Who decided what

• Risk tiering: the pilot classified under the company's AI risk framework, with controls proportionate to its tier — safety-adjacent, human-approved, fully audited.
• Weekly pilot review: proposal quality, approval/modification/rejection rates, and any incidents reviewed with maintenance leadership — the pilot's honesty metrics.
• Incident playbook: a wrong or unsafe proposal had a defined response — containment, root cause, regression test added to the eval set.
• Expansion criteria: written before the pilot started — what "good enough to expand" meant, so success couldn't be redefined mid-flight.

10 · SECURITY

Controls for an agentic pilot

• Tool sandboxing: read-only tools with scoped credentials; the agent's identity had the minimum permissions to do its job and nothing more.
• Prompt injection defenses: manuals and telemetry treated as untrusted input — instruction hierarchy enforced, tool outputs validated before entering the planner's context.
• Data leakage controls: no operational data in training; prompts and logs scoped to the pilot; vendor and support access bounded.
• Red-teaming: adversarial testing of scope escape, data exfiltration, and unsafe proposals — run before production data and repeated on every significant change.

11 · CHALLENGES

What was actually hard

• Proposal quality variance: the agent was excellent on common failure modes and shaky on rare ones — exactly where technicians needed help most. The eval set weighted rare-but-critical scenarios accordingly.
• Manual freshness: some manuals lagged equipment revisions. The ingestion pipeline flagged stale documents, and proposals cited document versions so technicians could see what they were standing on.
• Alert fatigue transfer: early proposals were too eager — suggesting work for alerts technicians would have watched. Tuning the proposal threshold against technician feedback was a standing agenda item.
• Trust calibration: the goal was appropriate trust, not maximum trust. Showing the agent's sources and uncertainty kept technicians in the judging seat.

12 · RESULTS

Outcomes, described without invented metrics

• Technicians got diagnostic proposals that pulled together manuals, telemetry, and history in one place — the correlation work that used to depend on who was on shift became systematic.
• The human-approval gate held through the pilot: every work order that became real work had a technician's judgment on it, and every approval, modification, and rejection fed back into proposal quality.
• The governance gate — eval, red-teaming, risk tiering, audit design — passed before production data, and the weekly review kept the pilot honest about its own performance.
• The expansion decision was made on written criteria and pilot evidence, not on demo enthusiasm.

13 · LESSONS LEARNED

What generalizes

• Propose, don't act — until trust is earned in proposals. The propose-only architecture is what made the pilot governable. Autonomy is a dial, and it starts at zero.
• The governance gate goes before production data, not after the demo. Risk tiering, red-teaming, and the incident playbook are cheapest when nothing is live yet.
• Approvals are labels. Every technician approval, modification, and rejection is training signal for proposal quality — design the loop to capture it.
• Calibrate trust, don't maximize it. Showing sources and uncertainty keeps humans judging. An agent nobody questions is a liability wearing a success metric.
• Write expansion criteria before the pilot. Deciding what "good enough" means after seeing results is how pilots become permanent demos.

14 · RELATED

Pattern, toolkit, service