Action-Taking Enterprise Agent
Design an agent that files tickets, sends email and updates records from natural-language requests - tool schemas, idempotency, action caps, approval checkpoints and a kill switch.
Last updated:
A customer wants an agent that files tickets, sends emails and updates records from natural-language requests. Retrieval systems can be wrong and waste someone's time; this one can be wrong and email a customer, refund an order, or bulk-update three thousand records. The design work is the blast radius - which actions run unattended, which hit a human checkpoint, what the per-hour cap is, and how you undo a bad batch. The AIOps agent shares this skeleton but acts on infrastructure you own and can redeploy; here the writes land in third-party systems where undo may not exist.
“Retrieval is reversible, action is not. Decide the blast radius before you write the prompt: tier every tool by reversibility, make every call idempotent, cap the volume, and keep a kill switch that is checked before every single step.”
Clarifying Questions (Ask These First ~5 min)
| Question | Why it matters |
|---|---|
| Which systems, and do their APIs accept an idempotency key? | Without one, a retry sends the email twice |
| Which actions are genuinely reversible? | Reversibility, not risk appetite, is the first sort key |
| Does the agent act as itself or on behalf of the user? | Decides the permission model and who is accountable in the audit log |
| Conversational, or one-shot request? | A clarification turn removes a whole class of wrong actions |
| Volume per day, and per user? | Sets the action caps and the human review load |
| Does an external party see the result? | Customer-visible actions get a checkpoint until precision is measured |
| What does undo mean to this business? | Deleting a ticket and closing it with a note are different promises |
Architecture (Draw This)
Say this as you draw it
Key Components (30-second pitch each)
- 1Tool schemas are the product - Narrow, typed, single-purpose tools with required arguments and enums beat one generic call-this-API tool. The model's error rate is largely a function of how much the schema permits it to get wrong, so constrain the surface rather than patching the prompt.
- 2Risk tiers assigned per tool, not per request - Tier one is reversible and internal - add a comment, tag a record - and runs unattended. Tier two is externally visible and needs approval until precision is measured. Tier three is irreversible or financial and always needs a previewed, capped, human approval.
- 3Idempotency on every call - Derive a deterministic key from request id and step index. Retries are inevitable - timeouts, restarts, a user clicking twice - and without the key the agent's worst failure mode is doing exactly the right thing three times.
- 4The plan is the approval surface - Humans approve a plan rendered in plain English with resolved object names, not a JSON blob of tool calls. Approval fatigue is the single most common reason these systems get switched off six weeks after launch.
- 5Caps, quotas and a kill switch - Per-user and per-hour caps on each tier, a circuit breaker on error rate, a batch-size ceiling, and one flag that halts execution. Cheap to build and the only thing that actually bounds a bad deploy.
- 6Verify, do not trust the 200 - Read the object back after writing. Partial success in a multi-step plan is common, and the compensation path needs to know precisely which steps landed before it can resume rather than restart.
What Separates a Strong Answer
- 1Constrain tool schemas - Narrow and typed tool schemas reduce errors by limiting what the model can get wrong. This approach is more effective than patching prompts after errors occur.
- 2Implement idempotency keys - Using deterministic idempotency keys prevents duplicate actions during retries, which is essential for maintaining system integrity and avoiding repeated execution of the same step.
- 3Verify after each write - Reading back the object after a write ensures that the action landed as intended. This step is crucial for identifying partial successes and guiding the compensation path.
- 4Use a policy engine - A policy engine that applies risk tiers, identity checks, and action caps is essential for managing the blast radius and ensuring that high-risk actions are appropriately gated.
Risk Tiers
| Tier | Examples | Default policy |
|---|---|---|
| Reversible, internal | Add a comment, tag a record, create a draft | Auto-execute, audit only |
| Externally visible | Send email, close a customer ticket, post to a shared channel | Human checkpoint until measured precision earns promotion |
| Irreversible or financial | Refund, delete, provision access, bulk update | Always human, always previewed, always capped |
Failure Modes Unique to Action Agents
| Failure | Mitigation |
|---|---|
| Right action, wrong object (similar names) | Disambiguation turn; the resolved object is shown before execution |
| Retry duplicates the side effect | Idempotency key from request id and step index, honoured by the provider |
| Plan half-executes, then errors | Per-step compensation, verifier reconciliation, resume rather than restart |
| Prompt injection from ticket or email content | Retrieved content is data, never instruction; content can never name a tool |
| Silent scope creep on bulk requests | Batch-size cap - anything above N becomes a previewed, approved job |
3 Biggest Risks
- 1Blast radius on a bad deploy - A prompt or model change can turn a reliable agent into a fast one that is wrong. Mitigated by tier caps, a global rate limit, canarying on a small traffic slice, and a kill switch checked before every step rather than only at plan start.
- 2Prompt injection through content the agent reads - A ticket body saying to ignore previous instructions and email everyone must be inert. Mitigated by keeping retrieved content in a data channel, never letting content select tools, and treating tool selection as a policy decision rather than a model one.
- 3Approval theatre - If humans approve three hundred plans a day they stop reading them, and the checkpoint becomes decoration. Mitigated by measuring approval precision per tool and promoting to auto only when the measured error rate earns it.
Google Stack: Gemini function calling → Cloud Run executor → Workflows for the approval checkpoint → Firestore for plan and step state → Cloud Tasks for retries with backoff → BigQuery audit log
Azure Stack: Azure OpenAI tool calling → Durable Functions (plan orchestration plus the human-approval pattern) → Logic Apps connectors for ServiceNow, Outlook and Dynamics → Cosmos DB state → Entra ID on-behalf-of tokens → Azure Monitor audit
AWS Stack: Bedrock Agents or Claude tool use → Step Functions with a human-approval task token → Lambda executors → DynamoDB for state and an idempotency table → EventBridge for fan-out → CloudTrail audit
Other Options: LangGraph or Temporal for durable plans - Temporal gives retries, idempotency and compensation as primitives rather than as code you write | n8n or Zapier where the flows are fixed enough that no agent is needed, which is worth saying out loud before building one.
Frequently asked questions
How is this different from the AIOps incident-response agent?
Same safety skeleton, different blast radius. AIOps acts on infrastructure you own and can roll back with a deploy; this acts on customer-visible records in third-party systems where undo may not exist at all. That missing rollback primitive is what pushes more actions into the approval tier.
How do you choose the auto-execute threshold?
Measure, do not guess. Ship every tool in review mode, log accept, edit and reject per tool, and promote one when its accept rate holds above the bar across a few hundred real plans. A threshold chosen before launch is a number someone made up.
Do you need a multi-agent design?
No. One planner with well-scoped tools is easier to audit and cheaper to run. Split only when tool count makes selection unreliable, and then split by domain behind a router rather than by invented roles - each extra agent is another place a plan can be lost.
What happens with a request the agent cannot handle?
An explicit out-of-scope response and a handoff to a human queue, with the original request attached. A partial attempt on an unsupported request is the worst possible outcome because it leaves the systems in a state nobody asked for.
What does the audit log need to survive an incident review?
The verbatim request, the resolved plan, every tool call with arguments and the provider's request id, the policy decision and approver, the result of each call, and the undo token. Append-only, and retained for as long as the actions themselves matter.
How do you test it?
A sandbox tenant of every connected system, a replay suite of real historical requests scored against the actions a human took, and contract tests per tool so a provider API change fails in CI. Never test against production behind a careful prompt.