Skip to content
Back to Index

Notes / Before an agent ships

What should be clear before an AI agent ships?

Define the job, access, review decisions, evaluation cases, ownership, and fallback before expanding an agent's responsibility.

Nino Amor · Working note

Before I would put an agent into a business workflow, I would want six things to be clear.

The job. Describe the input, the expected output, and the stopping point. A narrow job is easier to inspect than a promise to handle an entire department's work.

Access. Reading information, proposing an action, and taking that action are different responsibilities. For an illustrative support agent, drafting a reply does not automatically imply permission to send it or change an account.

Review. Decide which choices need a person and what they need to see. An approval screen should show the proposed action, the relevant evidence, and the consequence of proceeding. The review needs to change what the workflow does.

Evaluation. Start with representative examples: ordinary requests, incomplete information, conflicting instructions, and cases that should be handed off. Describe what a satisfactory result looks like before checking the output. Keep examples that expose a failure so the team can retest them after a change.

Ownership. Name who reviews failures, updates instructions, and decides whether the agent can take on more responsibility. That ownership has to survive the initial build.

Fallback. A workflow needs somewhere to go when it cannot finish. It might ask a question, prepare a handoff, or stop before an external action. The fallback should retain enough context for the next person to continue.

I would use those six questions to scope the first release and its review. The purpose is to make the system's responsibility understandable. As the team learns from actual use, it can decide which boundaries should change.