Appearance
Agents
An agent is a small standing job for Iris: when a high alarm raises on the tank farm, look at the tags and recent alarms and write down the likely cause. A trigger starts it, it reads the plant through its tools, and it hands its result to an output that cannot control anything.
You need the license modules aiCore and aiAgents, the Agents switch on (Turning Iris on), and the Iris administration capability to create or run one.
What an agent can and cannot do
- It runs as its own identity,
agent:<name>, with only the abilities of the tools its definition lists. It never inherits the authority of the person who wrote it or who is signed in. - It reads. It can be given a proposing tool, but that only files a proposal a person approves. No output writes a tag or a file.
- It is bounded: at most 20 model rounds (
maxSteps, 6 by default) and 120 seconds, an optional token limit per run and a runs-per-hour limit, and every model call counts against the agent's own budget.
Writing one
In Studio, open the Project Browser and add one under Iris Agents. An agent is a project resource, so it travels with the project through export, backup and source control. Its fields:
| Field | Meaning |
|---|---|
| name | Lower-case letters, digits, - and _. It becomes the agent's identity. |
| enabled | A switch. An agent with an invalid definition loads disabled, with the reason shown, and is never run. |
| trigger | Manual; alarm raised or alarm cleared (optionally for tags under a path and from a priority up); schedule (a five-field cron line, in plant time); or tag condition (a tag, a comparison and a value, with a hold-off between firings). |
| instructions | What to do, in words. Plain text, up to 16 KB. |
| tools | The read tools it may use, and optionally the proposing tools. |
| outputs | Alarm note, Notification enrichment, Report, E-mail to a notification roster, or Proposal. |
| budget | Tokens per run and runs per hour. |
A typo in any field is an error, not a guess: a definition with an unknown key is refused rather than half-run.
Triggers are cheap and bounded
A trigger only posts a job. It never waits on a model, so a flood of alarms cannot slow alarm handling down.
- One run per alarm instance: a flapping alarm does not start a run each time.
- A gateway-wide limit on runs started by triggers, 10 a minute by default (
agentMaxRunsPerMinute). Above it a trigger is dropped and counted, not queued. A person starting a run by hand is not counted.
Root-cause analysis before a notification
In Studio's notification policy editor, add a stage called Iris root-cause analysis (before the next notification), naming an agent and a wait. The stage notifies nobody. It starts the agent, then holds the next stage for the wait (10 seconds by default, never more than 30). When the wait ends, or the agent answers, the next stage goes out, and if the agent's note arrived it is added to the message, labeled Iris (AI, may be wrong).
The wait is a hard bound. If Iris is off, the model is slow, the agent fails or the cap was reached, the notification goes out unchanged at the end of the wait, or at once when Iris could not even start. An alarm never waits on a model for longer than the stage says, and an acknowledgment or a clear ends the hold straight away.
Seeing what an agent did
ConfigHub › Security › Iris Agent Runs lists every run (including refused ones), with its trigger, steps, tokens, outputs and the proposals it filed. A run's page has the conversation, the tool calls and a link to each proposal. Each is also an audit-log row (AI_AGENT_RUN) and a transcript, kept as long as transcripts are.
In Studio, Run now in the agent editor runs one by hand and shows its progress.