Operational Agent Pattern
A public-safe pattern for agents that read context, prepare work, verify evidence, request approval, and then act.
Right page if: you need a generic operational-agent pattern that maps runtime decisions, rulesets, Workflow Gates, approvals, audit evidence, replay, SDKs, Gate, and the reference stack into one implementation shape. Wrong page if: you only need the raw Workflow schema -- see https://docs.edictum.ai/docs/reference/workflows. Gotcha: this is a pattern, not a customer case study. Keep real customer names, private systems, and internal runbooks out of public docs unless approved.
Operational agents usually need to read context, prepare work, verify evidence, ask for human approval, and then act. Edictum should enforce that process at runtime instead of trusting the model to remember it.
Pattern
Use this structure when an agent touches production systems, code, tickets, infrastructure, customer data, or other stateful tools.
| Step | Runtime control |
|---|---|
| Read approved context | Rulesets restrict read tools and data scopes |
| Prepare the change | Workflow Gates require the read stage before write tools unlock |
| Verify evidence | Workflow Gates require command, file, or MCP result evidence |
| Route approval | ask rules or workflow approvals keep humans in the review path |
| Execute bounded action | Rulesets and sandbox rules restrict the write target |
| Record proof | Audit events and workflow snapshots record every decision |
Minimal Workflow Shape
apiVersion: edictum/v1
kind: Workflow
metadata:
name: operational-agent
stages:
- id: read-context
tools: [Read, "mcp__docs__*"]
exit:
- condition: file_read("/workspace/RUNBOOK.md")
message: Read the runbook before preparing work
- id: prepare
entry:
- condition: stage_complete("read-context")
tools: [Read, Edit, Write]
- id: verify
entry:
- condition: stage_complete("prepare")
tools: [Bash, "mcp__ci__*"]
exit:
- condition: command_matches("^pnpm\\s+test")
message: Run the verification command before review
- id: approve
entry:
- condition: stage_complete("verify")
approval:
message: Human approval required before production action
- id: done
entry:
- condition: stage_complete("approve")
terminal: trueRuleset Boundaries
Pair the workflow with rulesets that answer the single-call questions:
- Which files, commands, domains, or APIs can the agent touch?
- Which roles or principals can perform destructive actions?
- Which actions need
askinstead of automatic allow? - Which outputs should warn, redact, or block?
- Which retry loops or tool-call volumes should stop the session?
Where Each Feature Fits
| User problem | Edictum feature family |
|---|---|
| Should this action run now? | Runtime Decisions |
| What can the agent touch? | Rulesets And Policy-As-Code |
| Did the agent follow process? | Workflow Gates |
| Which actions need review? | Human Approval Gates |
| Can we prove what happened? | Audit, Evidence, And Reporting |
| What would a stricter rule have changed? | Replay And Blast-Radius Preview |
| How does this fit my stack? | SDKs And Framework Adapters |
| Can this govern a coding assistant? | Gate CLI And Coding Assistants |
| How do teams coordinate across agents? | Reference API/App Stack |
| What common risks are covered? | Security And Compliance Starters |
Related
Last updated on