In 30 seconds

Defining an agent's job means writing down what it is for, what it is not for, what it may do, and where it must stop. A clear, narrow job is safer and more useful than a broad, vague one.

Why this comes up

"Build an agent to handle support" is a wish, not a job. Without a defined scope, the agent's boundaries are whatever the model happens to do, which is exactly what you do not want. Defining the job is what turns an open-ended idea into something you can build, test and trust.

Write the job as a scope and its edges

The job: what it is for

State the goal in one or two plain sentences. "Answer common customer questions from the current help articles and draft replies for an agent to approve." Specific enough that you can tell whether a given task is in scope.

The non-goals: what it is not for

Non-goals are as important as goals. "It does not handle billing disputes. It does not change customer records. It does not make promises about delivery dates." Naming what the agent will not do prevents scope from quietly expanding into risky territory.

The allowed actions

List what the agent may actually do, and at what autonomy level: what it may read, what it may draft, what it may execute. Keep this to the minimum the job needs. See how to define allowed and prohibited actions.

The boundaries: where it stops

Say what the agent does when a case falls outside its job: an unusual request, an uncertain answer, a needed action it is not allowed to take. The answer should be to escalate to a person, not to improvise. See how to design escalation and failure behavior.

Prefer narrow over clever

A narrow agent that does one job well is easier to test, easier to trust and less likely to surprise you than a broad one that tries to do everything. You can always widen its job later, from evidence, once the narrow version is proven.

A small example

A team defined an onboarding agent narrowly: prepare a first draft of the welcome pack from a new hire's details, for HR to review. Non-goals: no sending, no access to payroll, no answering policy questions. That tight scope made it quick to build, easy to check, and safe to run, and it still saved HR real time.

What this does not solve

A clear job definition guides design; it does not enforce itself. The allowed actions, guardrails and escalation still have to be built and tested. A good definition makes that work possible and much easier to get right.

Good enough to move on when

  • The job is stated in one or two clear sentences.
  • Non-goals are written down.
  • Allowed actions and their autonomy levels are explicit.
  • The agent has a defined way to stop and escalate.