Exception handling agent
An exception handling agent organizes unexpected operational events into evidence-based cases, finds the approved response playbook and routes work to an accountable owner. It can summarize timelines and missing context while software controls permitted actions and retries. Werkon would validate this pattern through verified recovery, with consequential decisions and safety, security or emergency response owned by qualified people.
A validation failure, expected variation, duplicate alert, maintenance condition, complaint, security incident and emergency require different handling. Preserve original messages, API problems, measurements and reports with source identity, timestamps, units and corrections. Check clock drift, stale observations and sequence before correlating events through explicit keys and time windows.
Priority candidates should show the affected work, people, money, data and time exposure. Model confidence cannot determine urgency or establish a root cause. Keep current authoritative state, observations, conflicts and unknowns separate, and retrieve only the context the case permits.
An approved playbook defines prerequisites, allowed inputs, reads and writes, action limits, approvals, retries, compensation, stop conditions, escalation and expiry. Start with read-only steps where possible. Only reversible, idempotent and pre-authorized low-impact actions are candidates for automatic execution.
Assign one current accountable owner and record accepted or rejected transfers, the next action, response target and fallback. Safety, medical, security and emergency signals need independent approved routes. Exception details must not expose stack traces, credentials, personal data or sensitive controls.
Read current state immediately before action and block changed preconditions or competing writes. Cap retries and reconcile an uncertain result before repeating it. Preserve manual correction, abort, rollback and safe degraded operation. Qualified owners retain continuity activation, customer remedies, compensation and final closure.
Technical success, restored service, resolved impact and confirmed root cause are separate findings. Verify recovery in the affected system and human or physical process, retain residual risk and observe recurrence. A contributing condition or hypothesis becomes a confirmed cause only through qualified investigation.
Exception boundary
An exception crosses system state, human judgment and physical operations. Four boundaries keep detection useful and recovery accountable.
Bind expected state and exception condition to an authoritative process version, then validate source, schema, units, clocks, freshness and integrity before creating or updating a case.
Required evidence: Tenant and process, work item, expected and observed states, source and event identifiers, source and receipt times, unit and schema, freshness, threshold or rule version, validation result, duplicate key, conflicting evidence and rejected signal.
Gather only authorized source-linked context, distinguish facts from unknowns and hypotheses, correlate by domain keys and produce reviewable type, severity and routing candidates.
Required evidence: Original records, access purpose, affected people, assets, customers and work, related-case rationale, type and severity candidates, safety and security flags, material conflicts, uncertainty, missing context, correction and human classification.
Match an approved current playbook, verify prerequisites and permissions immediately before each step, keep actions reversible and idempotent, and stop on changed state or uncertain effect.
Required evidence: Playbook identifier and version, scope, prerequisites, permitted tools and fields, approval, action request, idempotency key, attempt, technical response, uncertain result, retry cap, stop reason, rollback or compensation and authoritative post-action state.
Preserve one accountable owner and every transfer, keep specialist and emergency routes independent, reconcile affected service and retain recurrence, impact, root-cause and improvement evidence beyond case closure.
Required evidence: Owner and supporting roles, route, delivery, acceptance or rejection, fallback and escalation, decision and action, service restoration, customer or physical confirmation, residual risk, incident, claim, complaint, loss, recurrence, root-cause status and verified change.
Signal-to-outcome path
A signal can start investigation. It cannot grant authority, prove impact or close the affected work.
Identify tenant, process, work item and authoritative state; capture original observations; validate source, schema, units, sequence and freshness; and hold invalid or conflicting signals for review.
Apply deterministic domain keys and bounded windows, preserve related candidates, create one attributable case and produce type, priority and specialist-route candidates without inventing urgency.
Find an approved current playbook, check type and scope, permissions, prerequisites, dependencies, stop conditions, approval points, retry and compensation rules, and fall back to human handling when any contract is missing.
Re-read current state, perform only pre-authorized reversible steps, record each attempt and uncertain result, stop rather than retry blindly, and transfer unresolved work to an accepting named owner.
Verify affected system and physical or human service, keep residual impact open, require qualified root-cause work and compare recurrence, customer impact and human effort before expanding automation.
Authority map
A model can summarize an abnormal trace. It cannot declare an incident, authorize a dangerous action or decide the business has recovered.
Software owns tenant boundaries, source and schema validation, clocks, state authority, correlation keys, thresholds, hard routes, permissions, playbook versions, prerequisites, idempotency, retry caps, case transitions, deadlines and receipts.
Models can classify a candidate, extract evidence with source references, summarize a timeline, identify missing context, find an approved playbook and draft clarification or handoff text while truth, priority, routing and action authority stay outside the model.
Named operations owners and qualified safety, security, continuity, compliance, customer, finance, legal and people responders own material classification, priority, action, emergency response, customer remedy, root cause, residual risk and closure.
Exception-handling components
Reliable handling depends on exact state, controlled action and durable ownership. Four components preserve that chain.
Version tenant, process, work item, expected state, authoritative source, exception condition, original observation, source and receipt times, schema, units, freshness, integrity, validation and correction.
Operating contract: Event is not business state, metric is not impact, threshold breach is not incident, model score is not fact, receipt time is not occurrence time, silence is not success and a monitoring gap is not normal operation.
Preserve case type, domain keys, correlation window and rationale, duplicates and related cases, affected scope, facts, conflicts, unknowns, severity candidate, hard route, current owner, status and response policy.
Operating contract: Similarity is not identity, shared timing is not shared cause, duplicate is not harmless, many alerts are not many exceptions, priority candidate is not authority, routed is not delivered, delivered is not accepted and aging is not owner action.
Bind approved playbook version, prerequisites, permissions, tools, reads and writes, approval points, action request, idempotency, attempt, result, uncertainty, retry cap, stop, rollback and compensation to current source state.
Operating contract: Runbook text is not current approval, technical response is not business success, timeout is not failure, failure is not safe to retry, repeated request is not idempotent by intent alone, rollback request is not restored state and automation rate is not value.
Link owner transfer, acceptance, specialist or emergency route, decision, affected service, physical or customer confirmation, residual impact, incident, claim, complaint, recurrence, root-cause status and corrective action.
Operating contract: Case closure is not service recovery, restoration is not root cause, no recurrence yet is not prevention, compensation is not absence of harm, completed corrective task is not verified improvement and continuity invocation is not proof of resilience.
Delivery path
Begin where expected state, owners, actions and recovery can be inspected without placing safety or continuity decisions inside the agent.
Select one tenant, process, work-item class, authoritative source, exception condition, owner group and low-impact response with enough historical evidence to inspect missed, false and repeated cases.
Inventory expected and observed states, schemas, units, clocks, freshness, duplicates, correlations, priorities, hard specialist routes, owner transitions, response policies, permissions, approvals and recovery evidence.
Implement source validation, deterministic correlation and case state, minimal context retrieval, explicit prerequisites, pre-authorized reversible actions, idempotency, retry caps, stops, compensation, handoffs and receipts.
Exercise forged and stale sources, duplicates, clock drift, conflicting state, unsafe merges, stale playbooks, revoked permission, partial writes, timeout after commit, concurrent responders, unavailable owners, emergency signals and failed rollback.
Start with detection and owner-visible drafts, compare corrections, accepted cases, safe actions, unresolved age, recovery, recurrence, customer impact and human effort, then expand only steps with current evidence and reliable stop paths.
Release controls
Fast action can deepen a bad signal. These controls keep detection, playbooks and ownership honest.
Outcome evidence
Closing more cases can hide missed exceptions, unsafe merges and false recovery. Proof must follow the affected operation.
Fit test
Source basis
Object Management Group
Business Process Model and Notation, version 2.0.2OMG lists BPMN 2.0.2 as its latest formal version and provides the normative specification. BPMN models error events that interrupt an activity and escalation events that can interrupt or continue alongside it. A process notation does not prove a runtime signal, current process deployment, exception type, priority, owner acceptance, safe action, recovery or outcome.
RFC Editor
RFC 9457: Problem Details for HTTP APIsThis Internet Standards Track document, which obsoletes RFC 7807, defines machine-readable problem details for HTTP APIs. It says the status member is advisory and warns that problem details can expose system, access and privacy information. An HTTP problem does not establish domain state, root cause, business severity, case ownership, physical effect or recovery.
Cloud Native Computing Foundation
CloudEvents 1.0.2The CloudEvents project identifies 1.0.2 as the latest released core specification for describing event data in a common way. A portable envelope does not prove source identity, payload correctness, semantic uniqueness, ordering, complete coverage, delivery, exactly-once processing, current business state, exception priority, owner action or outcome.
International Organization for Standardization
ISO 22301:2019: Business continuity management systemsISO lists this business-continuity management-system requirements standard as published while marked to be revised. Its public description covers planning, operation, monitoring, review, maintenance and improvement for disruptive incidents and recovery. It does not detect a specific exception, validate a signal, define a playbook, authorize continuity activation, prove recovery or certify this agent.
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD
Continue with the work
Stay with the operating question. The technology can wait until the work is clear.
Compare other bounded agent patterns and the evidence, authority and recovery contracts they require.
Open path02Separate work state, exception ownership, action authority, recovery and outcome evidence across operational flows.
Open path03Keep source authority, action permissions, failures, reconciliation and human work explicit across automated steps.
Open path04Route bounded work across systems and people while preserving exact state, permissions, handoffs, failures and recovery.
Open path