Event-driven agents, and the guards they need
An agent that runs nightly finds a problem up to twenty-four hours late. An agent that runs on the event finds it immediately and, without guards, finds it eleven thousand times.
What triggers what
Agent evaluations subscribe to state changes on object types rather than running on a clock. A revision reaching *Released*, a nonconformance opening, a supplier certification field changing, a publication failing reconciliation.
The subscription is configuration: which agent, on which object type, on which transition, under which conditions. It is declarative for the same reason the rules engine is — an administrator needs to be able to read what will happen without reading code.
Scheduled evaluation still exists and is still correct for some work. Certification expiry is a date arriving, not an event occurring, and no state change announces it. The two models coexist; the mistake is using a schedule for something that has an event, and paying up to a day of latency for nothing.
The three guards
Event-driven agents fail in three specific ways, and each has a specific guard. Without all three, the model produces a system that is either expensive, wrong, or both.
- Debounce. A mass change touching four thousand items emits four thousand events. Evaluations coalesce over a short window so the agent runs once against the resulting state rather than four thousand times against intermediate ones — which is also the only way the cost is predictable.
- Idempotency. An evaluation that has already produced a finding for a given object and state does not produce a duplicate. The finding is updated or left alone. Without this, a work queue fills with the same task expressed forty times and people stop reading it.
- Depth limits. An agent action that changes an object emits an event that may trigger an agent. The chain is bounded and the bound is low, because an unbounded chain is not a feature with a bug — it is a system that consumes its budget in an afternoon and writes a great deal of nonsense while doing so.
The failure it prevents
A reconciliation drift appears on a released item: the ERP's unit of measure disagrees with the PLM's. Nightly evaluation would find it the following morning.
In the meantime, four purchase orders are raised against the wrong unit of measure. The quantities are out by a factor of a thousand — metres against millimetres — and two of them are placed before anyone looks at a queue.
Latency is the cost, and it is not evenly distributed. Most findings do not care whether they arrive now or tomorrow. Reconciliation drift, publication failure and expired deviations do, because each of them is a window during which something wrong is being acted on downstream.
How it meets the rest of the product
Events come from the same transition machinery the workflow engine uses, so an agent subscribes to the same transitions a workflow does. There is no parallel event system, which matters because two event systems eventually disagree about what happened.
Every evaluation is metered and attributed. An event-triggered run appears in the audit trail with the event that caused it, which is what makes the question *why did this task appear* answerable — and it gets asked more than any other question about agents.
Budget controls apply per tenant and are what makes the model safe to enable. When a budget is approaching its limit, event-driven evaluation degrades to scheduled evaluation rather than stopping, so the work still happens with more latency instead of silently not happening.
Subscriptions are visible as configuration rather than buried. An administrator can see every agent subscribed to a transition and what conditions it runs under, which is what makes the question of why a task appeared answerable from a screen rather than from a support conversation.
How it meets your ERP
The highest-value events are ERP-facing, which is not a coincidence: they are the ones where the delay has a downstream cost measured in orders rather than in inconvenience.
A publication that fails validation, a reconciliation drift on a released item, a sync run that stops part-way. Each of these means the two systems currently disagree, and every hour that persists is an hour in which somebody may act on the wrong side of the disagreement.
Events from your ERP arrive through the connector rather than being polled, where the ERP supports it. Where it does not, the connector polls and emits events on change — so the agent model is the same either way and only the latency differs.
Where the boundary is
Event-driven does not mean autonomous. The trigger changes; the permission tier does not. An agent that could only recommend when run on a schedule can still only recommend when triggered by an event.
Chains are bounded and the bound is not configurable upward past a small number. An agent triggering an agent triggering an agent is a design smell rather than a capability, and allowing deep chains would mean shipping a system whose cost nobody can predict.
Facts
| Trigger | State transitions on object types, declaratively subscribed |
| Still scheduled | Date arrivals — a certification expiry is not an event |
| Guard 1 | Debounce — 4,000 events from a mass change become one evaluation |
| Guard 2 | Idempotency — no duplicate findings for the same object and state |
| Guard 3 | Depth limits — bounded chains, bound set low |
| Highest value | ERP events — publication failure, drift, stalled sync |
| Under budget pressure | Degrades to scheduled, never to silence |
| Unchanged | Permission tiers — the trigger changes, the authority does not |
Frequently asked
Why not run everything on a schedule?
Because latency has an uneven cost. Most findings do not care whether they arrive now or tomorrow, but reconciliation drift, publication failure and expired deviations do — each is a window during which something wrong is being acted on downstream.
What stops a mass change from triggering thousands of runs?
Debounce. Evaluations coalesce over a short window so the agent runs once against the resulting state rather than four thousand times against intermediate ones. It is also the only way the cost of enabling event-driven evaluation at all stays predictable in advance.
How do you avoid duplicate tasks?
Idempotency. An evaluation that has already produced a finding for a given object and state updates it or leaves it alone rather than producing another. Without that, a work queue fills with one task expressed forty times and people stop reading it.
Can an agent trigger another agent?
Within a bounded chain whose limit is low and not configurable upward past a small number. Deep chaining is a design smell rather than a capability, and permitting it would mean shipping a system whose running cost nobody could predict in advance.
Does event-driven mean the agent acts on its own?
No. The trigger changes; the permission tier does not. An agent that could only recommend when run on a schedule can still only recommend when triggered by an event, and nothing about the trigger mechanism grants additional authority to act.
What happens when we approach our budget?
Event-driven evaluation degrades to scheduled evaluation rather than stopping. The work still happens with more latency instead of silently not happening, which is the failure mode worth avoiding — an agent that quietly stopped looking is worse than a slow one.
Do events come from our ERP too?
Through the connector, where your ERP supports emitting them. Where it does not, the connector polls and emits events on change instead, so the agent subscription model is identical either way and only the latency between the two systems actually differs.