Choose one bounded job
“Build us an agent” is not yet a usable brief. A useful first scope names the trigger, the inputs, the systems involved, the output, the human owner, and what improvement should be visible. Document intake, support classification, research preparation, and recurring reporting can all be good candidates when their boundaries are clear.
Capture the current baseline before automating it: elapsed time, manual touches, exception rate, rework, or another observable measure. Otherwise the team may ship an impressive demo without learning whether the workflow improved.
Map tools as contracts
Every tool should describe what the agent can read, what it can change, the required input, the possible failures, and whether a person must approve the action. Narrow tools make agent behavior easier to test and audit than a single broad integration with unlimited access.
Use least-privilege credentials. Keep sending, publishing, deleting, purchasing, or changing customer records behind explicit approval until production evidence supports a different policy.
Evaluate the system in layers
A single “looks good” score hides where the system is failing. Build a small representative test set and score the layers that can break independently.
- Did retrieval return the permitted and relevant context?
- Did the plan respect policy and choose an allowed tool?
- Did the tool call contain valid, complete arguments?
- Did the final state in the source system match the requested outcome?
- Did the agent escalate ambiguous or high-risk cases correctly?
Operate the agent like software
Prompts, models, retrieval indexes, permissions, and connected APIs all change. Production operation needs versioning, traces, cost and latency visibility, regression checks, rollback, and a named owner for exceptions.
Autonomy should expand through evidence. Begin in observation mode, move to drafted actions with approval, and grant narrow automatic execution only where the test set and live review show stable behavior.