Hiring an AI agent in five steps, from scope to supervision

To hire an AI agent, treat it like any other hire for a defined job: scope one recurring job, write a brief that says what "done" looks like, run a trial on your own work, accept on evidence, then supervise it with named checkpoints. Most of the risk sits in the first two steps. An agent that gets a vague job ("help with invoices") cannot fail a test, so you cannot tell whether it works. This guide sets out that five-step method. The other guides in this section go deeper on each step, and the job pages apply it to specific work.

You are hiring one of two things. Either a product that already does the job (a support agent, an invoice-processing agent), or a person or firm that builds and operates an agent for you. The method is the same in both cases. The difference is who answers when the agent gets something wrong, and that belongs in the brief.

The method at a glance

Step	What you decide	What you have at the end
1. Scope	Which job, and whether it suits an agent	One job with a clear start, end and volume
2. Brief	Goal, inputs, deliverable, acceptance criteria, checkpoints	A written brief someone could reject work against
3. Trial	A sample of real work, run under supervision	Measured results on your own data
4. Acceptance	Whether the results meet the brief	A yes, a no, or a narrower scope
5. Supervision	Who reviews what, how often, and how to stop it	A running job with an owner and an exit

1. 1

   Scope

   One job with a clear start, end and volume

2. 2

   Brief

   A written brief someone could reject work against

3. 3

   Trial

   Measured results on your own data

4. 4

   Acceptance

   A yes, a no, or a narrower scope

5. 5

   Supervision

   A running job with an owner and an exit

The steps run in order. If the trial fails, you go back to scope or brief, not forward to a bigger rollout.

Step 1: Scope one job

Start with a job, not a tool. A job is recurring work with a trigger, an output and someone who cares about the output: "code every supplier invoice", "answer password-reset tickets", "enrich new inbound leads". Pick one. A first hire that spans three jobs gives you three half-measured results.

Check that the job actually needs an agent. Anthropic advises finding "the simplest solution possible" and notes this "might mean not building agentic systems at all", because agentic systems "often trade latency and cost for better task performance." OpenAI's guide to building agents gives three signs that a job suits an agent rather than fixed rules: it involves complex judgment calls (its example is refund approval), it runs on rulesets that have become hard to maintain, or it relies on unstructured data such as documents or conversation. If none of those apply, a rule-based automation may do the job more cheaply and predictably. Both are vendor sources; read them as the builders' own advice, not as neutral research.

A job that scopes well for an agent usually has these traits:

• It recurs. You can count last month's volume.
• Its output can be checked. You can say whether a given unit of work (one invoice, one ticket, one lead) is right or wrong, by rule or by sampling.
• Mistakes are visible and reversible before they cost much. A miscoded invoice caught in approval is cheap. A wrong payment already sent is not.
• It has an owner on your side. Someone who does the job today and can judge the output.

Write down the current volume and how long the job takes a person today. You need both numbers to judge the trial and to compare cost later; AI agent vs employee cost covers that comparison, and how AI agents are priced covers the pricing units you will meet.

Step 2: Write the brief

The brief is the job description. It is also the contract the agent is measured against, so every line has to be specific enough to accept or reject delivered work. Every job page in this section uses the same fields:

• Goal. One sentence with an outcome, not an activity. "Every supplier invoice is coded and queued for approval within one business day of arrival", not "help with invoices."
• Inputs. What you provide, including access: inboxes, exports, documents, accounts.
• Deliverable. What exists when the job is done, and where it lives.
• Acceptance criteria. Three to six checkable statements, with numbers where possible.
• Volume and cadence. How much work, how often.
• Systems. The types of system the agent works in (help desk, accounting system, CRM).
• Constraints. Data, compliance and approval limits.
• Human checkpoints. Where a person approves, and what they check.

Here is the blank template. Copy it and fill it in for your job.

For the same template with each field explained and good and bad examples, see the AI agent job description guide.

Two fields deserve extra care.

Access. Give the agent the least access the job needs. The OWASP Gen AI Security Project lists Excessive Agency as LLM06:2025 in its Top 10 for LLM applications and breaks it into three causes: excessive functionality (the agent can call tools the job does not need), excessive permissions (it has more rights in downstream systems than the job needs) and excessive autonomy (it takes high-impact actions without independent approval). OWASP's example of excessive permissions is an extension meant to read one user's documents that connects with a privileged account able to see every user's files. In the brief, write the access as narrowly as the job allows: read access to one inbox, not the mail server; draft rights in the help desk, not send rights.

Human checkpoints. OWASP's mitigation for excessive autonomy is to "require a human to approve high-impact actions before they are taken." Decide which actions are high-impact for your job before the trial, not after the first incident. Payments, messages to customers, filings and deletions are the usual candidates.

Step 3: Run a trial on your own work

A demo shows what an agent can do on the vendor's data. A trial shows what it does on yours. Run it on a sample of real, recent work, with every output reviewed before it takes effect.

Anthropic recommends "extensive testing in sandboxed environments, along with the appropriate guardrails", because an agent's autonomy brings "higher costs, and the potential for compounding errors." For a buyer, a sandbox can be as simple as a copy of last month's work, or live work where the agent drafts and a person sends.

Set the trial up so the result is a number, not an impression:

1. Pick the sample. Take a slice of real work that includes the awkward cases: the handwritten invoice, the angry customer, the lead with no website. Example: 50 invoices from last month, including the 5 your team found hardest.
2. Keep the answer key. For past work you already know the right answer. Compare against it.
3. Measure against the acceptance criteria in the brief, not against a feeling. Count errors by type.
4. Record time and cost per unit, in the vendor's pricing unit (per seat, per task, per resolution).
5. Note every point where a person had to step in, and why.

1. 1

   Pick the sample

   Real, recent work that includes the awkward cases

2. 2

   Keep the answer key

   Compare against the right answer you already know

3. 3

   Measure against the acceptance criteria

   Count errors by type

4. 4

   Record time and cost per unit

   In the vendor's pricing unit

5. 5

   Note every point where a person had to step in

   And why

Agree the trial terms in writing first: length, sample, who reviews, whether it is paid, and what happens to your data afterward. The AI agent trial guide covers setup, sample design and trial terms in detail.

Step 4: Accept on evidence

Acceptance is a decision against the brief. Go criterion by criterion. Each one passes or fails on the trial data.

There are three honest outcomes:

• Accept. Every criterion passes. Move to supervised production at the trial's volume, not straight to full volume.
• Narrow the scope. The agent passes on the common cases and fails on a recognizable subset (foreign-currency invoices, refund requests). Take that subset out of the job, keep it with a person, and rerun the trial on the narrower scope.
• Reject. It fails on the core of the job. Write down why. The reason is useful when you try again or try another provider.

Watch for the urge to lower the bar after seeing the results. If you change an acceptance criterion, write down why. If the reason is "the agent couldn't meet it", the brief was probably right and the agent was not.

Step 5: Supervise

A hired agent still needs a manager. Supervision has four parts, and each one belongs in the brief's human checkpoints:

• Review. Who checks what, and how much. Early on, review every output that takes effect outside your team. Move to sampling only when the error rate has been stable for a period you choose in advance.
• Escalation. What the agent does when it is unsure or blocked. OpenAI's guide says an agent, in case of failure, "can halt execution and transfer control back to the user." Check that the agent you hire can do this, and that the handoff lands with a named person.
• Logs. Keep a record of what the agent did, so you can trace an error back to its cause.
• A way to stop it. Someone on your side must be able to pause the agent and take the job back without the vendor's help.

These practices mirror rules that already apply to some uses of AI. For high-risk AI systems under the EU AI Act (Regulation (EU) 2024/1689), Article 14(4) requires that the people overseeing a system can "disregard, override or reverse" its output and interrupt it through "a 'stop' button or a similar procedure", and asks them to stay aware of "automation bias", the tendency to over-rely on the system's output. Article 26(2) requires deployers of those systems to assign oversight to people "who have the necessary competence, training and authority", and Article 26(6) requires them to keep the system's automatically generated logs, to the extent they control them, for "at least six months" unless other law provides otherwise. Whether a particular AI system is high-risk depends on the Act's classification rules in Article 6, which include the uses listed in Annex III, and on the system's intended use; check with your own counsel. The rules are still a useful checklist for what good supervision looks like.

If you want a broader frame for AI risk in your organization, NIST's AI Risk Management Framework is published "for voluntary use", and NIST released a Generative AI Profile for it on July 26, 2024. As of November 2026, NIST's page says AI RMF 1.0 "is being revised as part of the White House AI Action Plan." The AI agent supervision guide covers review cadence, escalation and handover in detail.

A worked example

Example only; not a real buyer. A finance lead at a 60-person company wants help with accounts payable.

• Scope. One job: code incoming supplier invoices to the right ledger account and queue them for approval. Paying invoices stays out of scope. Last month: 400 invoices, about 3 minutes each for a clerk.
• Brief. Goal: every invoice coded and queued within one business day. Inputs: read access to the AP inbox and a chart-of-accounts export. Acceptance: coding matches the ledger account on a 50-invoice sample with at most 2 errors; every invoice over $5,000 is flagged for a manager. Checkpoint: a person approves every invoice before payment, as today.
• Trial. 50 invoices from last month, run against the known coding. The agent misses 4, three of them in a foreign currency.
• Acceptance. It fails as scoped. The finance lead narrows the scope to domestic-currency invoices, reruns, and it passes.
• Supervision. The AP clerk reviews every coding for the first month, then a daily sample. Foreign-currency invoices stay with the clerk. The controller can pause the agent from the accounting system.

The same pattern applies to tier-1 support tickets, lead research and enrichment and document processing: one job, a checkable brief, a trial on real work, a decision against the brief, and a named person who supervises.

Questions buyers ask

Should I hire a product or someone who builds an agent? If a product already does your job in your systems, start there; the trial will tell you quickly. If your job depends on internal systems or rules no product covers, you are hiring a builder, and the brief should also say who operates and fixes the agent after delivery.

How long should a trial run? Long enough to cover your normal mix of work, including the awkward cases. No standard source gives a fixed length; size it to your volume and cadence.

Who is responsible when the agent gets it wrong? Ask counsel which obligations apply to your role and jurisdiction. Identify each party's obligations, and put the provider's obligations (fixing errors, notifying you of changes, handling your data) in writing before the trial.

What will it cost? Prices are published in different units: per seat, per task, per resolution, per minute. Compare in the unit the vendor charges, against what the job costs you today. See how AI agents are priced.

Sources

1. 1
   Building effective agents

   AnthropicVendorAccessed Nov 14, 2026

2. 2
   A practical guide to building agents

   OpenAIVendorAccessed Nov 14, 2026

3. 3
   LLM06:2025 Excessive Agency

   OWASP Gen AI Security ProjectPrimaryAccessed Nov 14, 2026

4. 4
   AI Risk Management Framework

   U.S. National Institute of Standards and TechnologyPrimaryAccessed Nov 14, 2026

5. 5
   Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal L, 12.7.2024

   Publications Office of the European UnionPrimaryAccessed Nov 14, 2026

6. 6
   AI Act Service Desk: Article 6: Classification rules for high-risk AI systems

   European CommissionPrimaryAccessed Nov 14, 2026

7. 7
   AI Act Service Desk: Article 14: Human oversight

   European CommissionPrimaryAccessed Nov 14, 2026

8. 8
   AI Act Service Desk: Article 26: Obligations of deployers of high-risk AI systems

   European CommissionPrimaryAccessed Nov 14, 2026