Agents that close work orders — not chat windows
An operational agent is a worker with tools, permissions, and an audit trail. Anything less is a demo.
The interesting agent is not the one that answers “what is a CMMS?”. It is the one that reads a vibration exception, drafts a work order against P-204, checks spare status, and waits for a human to release it.
The run log is the product
If you cannot show the tool calls, the policy check, and the resulting state change, you cannot put the agent near a plant. Operators will not trust a black box next to a compressor. A useful agent is inspectable: which tool it called, with which input, under which rule, and what it was not allowed to do.
type AgentStep = {
id: string;
tool: "assets.get" | "inventory.check" | "wo.create";
input: Record<string, unknown>;
policy: "allow" | "require_approval";
result: "ok" | "blocked";
};A worker, not a chatbot
Chat is a convenient surface. It is a poor system of record. The agent should write into the same objects a technician already uses: the work order, the asset, the spare, the permit. If the only artefact is a conversation, the plant still has no history.
That is the test we use at Adqueo. If the agent cannot name the asset, respect a permission, and leave a trail a supervisor can read on Monday, it stays in the lab.
