Agentic Resolution with Tool Access and Guardrails
A support organization wants an agentic assistant that can, on its own, look up order status, issue refunds up to $50, and create replacement orders. The agent is built as a Boomi process exposed as a tool-calling endpoint. It has access to three APIs: order lookup (read-only), refund (write, max $50), and replacement (write, creates a new order). Last quarter, a pilot agent issued a $50 refund to the same customer 14 times in one hour because it misread a retry loop as separate complaints. The business wants autonomy but requires that no customer receive more than one refund per order per day, and that all write actions be reversible or escalated. How would you redesign the agent's tool use and controls?
1. Identify the failure mode in the pilot and propose guardrails at the tool and orchestration layers.
Read the worked answer
The failure mode is unbounded idempotency: the agent treated each retry as a new complaint and the refund tool had no per-order, per-day constraint. At the tool layer, make the refund operation idempotent by requiring an order ID and a client-generated idempotency key, and enforce a server-side rule that rejects a second refund for the same order within 24 hours. At the orchestration layer, add a pre-action check that queries refund history before calling the write tool, and require the agent to state the order ID and reason in a structured plan before execution. Add a step-up control: refunds above a threshold (e.g., $25) or a second refund attempt require human approval. Log every tool call with inputs, outputs, and the agent's stated rationale.
2. How would you decide which actions remain fully autonomous versus requiring human approval, and how would you test the boundary?
Read the worked answer
Classify actions by reversibility and blast radius. Read-only lookups are fully autonomous. Reversible writes with a hard cap (refund up to $50, once per order per day) can be autonomous if the cap is enforced server-side, not by the agent. Irreversible or high-blast-radius actions (replacement order creation, refunds above cap) require human approval or a two-step confirmation. Test the boundary with adversarial scenarios: repeated identical requests, slightly varied requests for the same order, requests that combine a valid refund with an invalid replacement, and tool failures mid-action. Verify that the server-side caps hold even if the agent ignores instructions, and that the approval path cannot be bypassed by prompt injection. Measure false-approval and false-rejection rates before expanding autonomy.