Agent Design, Tools, and Integration
What this domain tests
Agent Design, Tools, and Integration tests tool contracts, function calling, API security, error handling, and when to keep work deterministic. You need to design an agent that can act without giving it unstructured control.
Core rules
- Define each tool with a narrow name, typed inputs, typed outputs, a clear description, and explicit error codes. The model selects tools from this contract; ambiguous schemas cause wrong calls.
- Keep business logic in the tool, not the prompt. The tool should validate, enforce authorization, and return a stable result; the model should not compute prices, taxes, or eligibility from memory.
- Use least privilege for each tool: scoped tokens, separate service accounts, and per-action permissions. A read tool should not inherit write scope.
- Make actions idempotent where retries are possible. Pass an idempotency key, check for duplicate execution, and define compensating actions for partial failure.
- Require human confirmation for irreversible or high-value actions, and log the proposed action, approver, and result.
Worked example
A refund agent has three tools: get_order(order_id), check_refund_eligibility(order_id), and issue_refund(order_id, amount, idempotency_key). The model may call the first two freely. issue_refund is allowed only after eligibility returns eligible, the amount is within the agent's limit, and a human approves amounts above that limit. The reasoning is that the tool enforces the financial control; the prompt only guides sequencing. The idempotency key prevents a retry after a timeout from refunding twice.
Traps
Do not pass free-text blobs between tools when a schema is possible. Do not give one execute-anything tool. Do not rely on the model to retry without backoff and a cap. Do not omit the compensating action when a multi-step process fails midway.