Strip the vocabulary away and an investigation is a procedure: something happened, so gather what is known about it, from the systems that know, in a sensible order, and assemble a picture a decision-maker can act on. A downtime event wants the footage before the stop, the event history for that station, the maintenance record for that machine, and the works order that was running. A safety near miss wants the clip, the zone's ninety-day pattern, and the procedure that governs the area. The gathering is not intellectually hard, and it consumes hours of exactly the people whose judgment the final picture needs, which is why so many investigable events at a busy plant simply go uninvestigated: the fixed cost of assembly exceeds the expected value of the answer. Agentic AI, stripped of its own vocabulary, is the automation of that assembly, and this article explains what it concretely consists of in a manufacturing deployment, where its authority should stop, and how the governance holds. It belongs to the operations thread of this series under our pillar guide to AI-powered video analytics for manufacturing.
What an agent is
In this platform's terms, an agent is a configured thing, not a mysterious one: a system prompt that defines its job, a knowledge scope that bounds what it may consult, a set of tools it may use, and a model that does the reasoning. Several coexist, each scoped to its purpose, a downtime investigator, a safety-event assembler, a compliance reporter, and the scoping is the point: an agent is useful precisely because it is narrow, auditable, and repeatable in a way an ad-hoc chat prompt is not.
The second piece of the architecture is the trigger that puts an agent to work. Event-driven workflows subscribe to what the platform already emits, and the detection events this series has spent twenty articles generating, the stop, the zone entry, the worker-down, the Standard Operating Procedure (SOP) deviation, become the starting guns for investigation graphs. An event fires, the graph runs, and the work happens without anyone watching for it, which is the property that changes the economics: the investigations that were not worth an engineer's afternoon become worth an agent's ninety seconds, and the plant stops triaging which events deserve understanding.
The third piece is the tools, and tools are where an agent's reach is defined. Retrieval over the described, indexed footage and records this series' search article covers. The written-question analysis of clips from the anomaly article. And, through the integration layer our Manufacturing Execution System (MES) and Supervisory Control and Data Acquisition (SCADA) article details, the plant's other systems: the maintenance history, the works orders, the quality records, each reachable as an operation the agent may invoke, under credentials and permissions that remain the source system's own. The picture an agent assembles is exactly as wide as the tools it was given, which is a governance dial, not a limitation.
Example: investigating a line stop
Concreteness beats definition, so walk the downtime case end to end. The stop detection fires from the live layer, per the downtime article's mechanics, and the subscribed graph starts. It pulls the event's clip and the pre-event footage that recording preserved. It queries the event history for that station, the last week of dwell violations, micro-stops, and interventions, because context is half of cause. It puts a written question to the footage, describe what happens at this station in the two minutes before the stop, and files the answer with the prompt that produced it. Through the integration tools, it fetches the machine's recent fault codes from the historian and its open work orders from the maintenance system. Then it assembles: a timeline of visual and machine events, the clip links, the pattern context, the candidate cause the evidence suggests, and it delivers the package to the reliability lead's queue, minutes after the stop, as a briefing rather than a verdict.
Every investigation the graph runs looks like this, which is itself part of the value: the fourth stop of the month is assembled identically to the first, the comparison across them is trivial because the structure repeats, and the weekly review the downtime article describes starts from briefings instead of blank pages. The same shape serves the safety near miss, the SOP deviation, the quality escape, each with its own graph, its own scope, and its own recipient, and the graphs are authored artifacts, versioned and reviewable, not emergent behavior.
Where humans stay in control
The question every IT and Operational Technology (OT) leader should ask of any agentic system is where its authority ends, and the defensible answer in a plant has two parts.
The defensible division of authority runs in one line: investigation is autonomous, and action is gated. Assembling evidence, querying systems read-only, and drafting briefings are safe to automate because they change nothing in the world, and that is where the graphs above live. The moment a workflow would act, create the work order, flag the lot, page beyond its standing rules, the design question is whether a human approves first, and human-in-the-loop gates exist as explicit workflow steps for exactly this. The honest default for a plant is conservative: reads run free, writes need approval, and the approval list shortens only as specific actions earn trust through review. Anything touching physical control systems sits beyond this conversation entirely, on the far side of the OT boundary, where the integration article draws the line this series does not cross.
Everything is logged, because the record is the trust. Agent runs, the tools invoked, the sources consulted, the prompts put to footage, and the outputs delivered all land in audit logs, and briefings carry citations back to their sources, so a reliability lead reading an assembled timeline can open every clip and record behind it. The governance instincts this series applies to cameras extend to agents without modification: scoped purpose, written terms, logged operation, and the workforce told plainly what runs and why. An agent that investigates conditions inherits the no-discipline commitment of the detection layer it feeds on, and the question register discipline of the anomaly article governs what its analyses may ask.
Model and deployment choices follow the same sovereignty logic as everything else on the plant floor. The reasoning layer runs against the models the deployment configures, including models hosted entirely on the customer's own infrastructure, so a plant under export control or OT segmentation runs the full loop, detection, retrieval, analysis, assembly, without any of it leaving the boundary, which for this buyer is usually the difference between a capability and a compliance finding.
What an agent briefing contains
The artifact an investigation graph produces deserves description, because its format is where trust is won or lost. A good briefing opens with the one-paragraph situation: what fired, where, when, and the candidate account the evidence supports. Beneath it, the timeline, visual and machine events interleaved with timestamps, each line linked to its source, the clip, the historian entry, the work order. Beside it, the context block: this station's event pattern for the period, open maintenance items, the last comparable incident and its resolution. And at the bottom, the provenance: which tools ran, which questions were put to footage with their exact prompts, and what was consulted and found empty, because a briefing that says the maintenance system had no relevant orders is making a checkable claim, and checkable claims are the currency. What the briefing conspicuously does not contain is a conclusion dressed as fact: the candidate account is labeled as such, and the reliability lead's judgment remains the last step, which is not a limitation of the system but the design that keeps the judgment sharp and the record defensible.
Start with one workflow
Agentic deployments fail by ambition, the everything-assistant nobody trusts, and succeed by specificity. The pattern that works picks the event type whose investigations are most numerous and most formulaic, downtime is the usual winner, builds the one graph that assembles its briefing, and delivers it to the one person who reviews those events anyway. The first month's briefings run beside the manual process, the reliability lead grades them, the graph's scope and prompts get tuned from the grading, and authority extends only as far as the grades justify. From there, expansion is horizontal, the near-miss graph, the SOP-deviation graph, each following the same probation, and the plant accumulates something subtle alongside the time savings: a consistent investigative method, encoded, versioned, and applied to every event of its type, which no staffing plan has ever delivered.
The prerequisite list is short and honest: the detection layer generating events worth investigating, the recording preserving the clips, the search layer indexing what agents retrieve, and the integration layer reaching the systems that hold the other half of every story. Sites that have built this series' earlier layers have built the prerequisites; the agent layer is what they were for.
What IT and OT teams need to prepare
The agent layer lands on the desk of the Head of Manufacturing IT/OT, and the honest prerequisites list from that chair reads as follows. Identity and access: agents act under service credentials with scoped permissions, so the integration accounts need the same review discipline as any system account, and the source systems' own permission models remain the enforcement point. Network posture: the reasoning and retrieval run inside the plant boundary on the deployment's own hardware, so the OT segmentation conversation is about which system APIs the integration layer may reach, read-only, from where, which is a familiar firewall discussion rather than a novel one. Change management: graphs and prompts are versioned artifacts, so they enter the same release discipline as any configuration, with the sampling audits and interrupt-rate metrics of the escalation chain serving as the operational monitoring. And vendor scrutiny: the questions worth pressing any supplier on are the ones this article answers, where do models run, what is logged, where do writes require approval, and what happens when a tool call fails mid-graph, because the difference between an agent platform and a demo is entirely in those answers.
How VIDIZMO fits
In VIDIZMO's platform, AI Intelligence Hub supplies the agent layer: agents configured with prompt, knowledge scope, tools, and model; event-driven workflows subscribing to what AI Live Insight and the rest of the platform emit; human-in-the-loop gates as workflow steps; and audit logging across runs, tools, and outputs. AI Live Insight supplies the events and the footage, the Nexus portal supplies the governed library and search the agents retrieve from, and the integration layer supplies the reach into MES, maintenance, and quality systems, under the manifest-based model the next article in this series details. The two products are licensed separately because the boundary is real: a plant runs detection for years without agents, and the day it adds them, the event stream it built becomes the trigger fabric.
The failure-handling question from the vendor-scrutiny list deserves its answer stated here, because it is the operational one: a graph step that fails, an unreachable system, a timed-out query, should degrade the briefing visibly rather than silently, the missing section named and the rest delivered, because a partial briefing that declares its gaps is useful while a complete-looking one that hides them is dangerous. That behavior, checkable in any demo by unplugging something, is a fast honest test of how a platform thinks about truth.
One caution keeps expectations honest across the whole layer: an agent's briefing is only as good as the records and coverage beneath it, and a plant with thin event data, patchy camera coverage, or an unmaintained maintenance system will receive thin briefings that faithfully cite their thin sources. The agent layer amplifies the data discipline a site already has; it does not substitute for it, which is one more reason this series put it last.
The evaluation question for this layer is refreshingly concrete: list last quarter's investigable events, count how many were actually investigated, and price the gap. The agent layer's pitch is that the gap goes to zero at the cost of review rather than assembly, and the plant's own backlog is the only benchmark that matters.