Write the Job Description Before You Deploy the AI Agent

If you're deciding how to deploy AI agents in your business, the answer is: write the agent's job description first. Not the prompt, not the integration — the job description: the exact tasks it owns, the systems it can touch, when it must hand off to a human, and the numbers that decide whether it keeps the job. Nearly every failed agent deployment we've been called in to fix skipped this step; the successful ones almost always did it, formally or not.

Agents fail like bad hires, not like bad software

When software breaks, it throws an error. When an agent is badly scoped, it does something — confidently, at volume, in your name. That's a people problem, not a tech problem, and it's why the hiring analogy is more than a metaphor.

Think about what you'd never do with a human hire: bring someone in with no defined responsibilities, give them admin access to your CRM and billing on day one, tell them "use your judgment" on customer refunds, and then check in after a quarter. Companies do exactly this with agents because a demo went well. The demo tested capability. It didn't test scope.

The pattern we see with clients is consistent. One founder who came to us had churned through three agent tools in six months and concluded "agents aren't ready" — and none of the three had ever been given a written scope. The teams that get real leverage do the opposite: they spend about a day on definition before deployment.

The four sections every agent job description needs

Write this as an actual document. One page is enough. It becomes your system prompt's backbone, your integration checklist, and your review criteria — three artifacts from one page of thinking.

1. Tasks owned — and tasks explicitly excluded

List the specific, recurring tasks the agent owns end to end. "Handles support" is not a task. "Drafts replies to tier-1 billing questions using the pricing doc, sends after human approval for the first 30 days" is.

Just as important: write down what the agent does not do. The exclusion list is where most incidents hide. An agent scoped to "answer customer emails" will eventually answer the angry legal-threat email unless you told it that thread type is out of scope. Exclusions we routinely write for clients: no refund commitments, no pricing exceptions, no statements about roadmap or timelines, no replies to anything mentioning lawyers, press, or regulators.

When picking the first tasks, the best candidates share three traits: high volume (the task happens 20+ times a week, so ROI is measurable), low blast radius (a wrong output is embarrassing, not catastrophic), and clear ground truth (you can tell right from wrong without a debate). Invoice-data extraction, lead enrichment, inbox triage, first-draft reporting, and meeting-notes-to-CRM hygiene all qualify. "Talk to our biggest customers" does not — not first.

2. Systems and permissions

For each system the agent touches, write down the access level: read, draft, or execute. Then grant the minimum and widen later.

The rule we use: an agent earns write access the same way a junior hire does — by producing correct drafts long enough that reviewing them becomes rubber-stamping. Start read-and-draft everywhere. An agent that can read your CRM and draft updates for one-click approval delivers most of the value of full write access at a fraction of the risk.

Also decide identity. Does the agent act as itself ("Ava from Acme, automated assistant") or impersonate a person? We push clients hard toward the former. It sets honest expectations with customers, and it means a mistake damages a bot's credibility, not a teammate's.

3. Escalation paths — the human in the loop, specified

"Human in the loop" fails as a vibe and works as a spec. The job description should answer: on which conditions does the agent stop and hand off, to whom, through what channel, and with what context attached?

Concretely, define three tiers:

• Proceed: routine cases matching known patterns. The agent acts and logs the action.
• Draft and wait: anything involving money, commitments, or situations it hasn't seen. The agent prepares the action; a named human approves it in Slack or the queue.
• Stop and escalate: defined tripwires — sentiment cratering, legal or security keywords, a customer above a revenue threshold, confidence below a set bar, or the same case looping twice. The agent tags a human and does nothing else.

That's what guardrails look like in practice: not a philosophy, a routing table. If you can't write the routing table, the agent isn't ready to deploy — and the process underneath it may not be either. That's a big enough problem to deserve its own piece, and we've written it: AI Won't Fix a Broken Process: Audit Your Workflow First.

4. KPIs that decide whether it keeps the job

Give the agent the same deal a human gets: measurable targets and a review date. Pick two or three, not ten:

• Quality: approval rate on drafts (what share ship without edits), error rate on executed actions, escalation accuracy (did it hand off the right cases).
• Throughput: tasks completed per week against your pre-agent baseline, and human hours actually recovered — measured, not assumed.
• Trust: how often humans override it, trending down over time.

Then honor the review. At 30 days, one of three outcomes: expand scope, hold and fix, or fire the agent and redesign the role. Firing an agent costs you a config, not a severance package — which is exactly why you should be quicker to do it, not slower. Teams that let a mediocre agent linger poison the whole org on the idea.

A worked example: inbox triage at an agency

Agencies are a good stress test for agent scoping because they run on client trust — the blast radius of a bad message is a relationship, not a ticket. Here's the shape of a job description we've deployed for a 15-person agency's shared inbox:

• Owns: classify inbound client email (request, approval, complaint, FYI), draft replies for scheduling and status questions, update the project tracker with commitments made.
• Excluded: anything touching scope changes, budget, or dissatisfaction — flagged, never answered.
• Access: read on email and the PM tool; draft-only on replies; write on the tracker fields it owns.
• Escalation: complaints and budget threads go to the account lead within the hour, with a summary and the full thread linked.
• KPIs: 90%+ classification accuracy sampled weekly, edit-free draft approvals trending up, zero out-of-scope sends. Review at day 30.

That agent survived probation and earned scope expansions. A prospect once described the opposite approach at another shop — "handle the inbox" with full send access — which, as they told it, ended shortly afterward in an apology call to a client.

The mistakes we keep seeing

Three failure modes cover most of the wreckage. Scoping by capability, not by role — deploying everything the tool can do instead of the job you need done. Permissions before trust — execute access on day one because approval queues feel slow; they're slow for two weeks, and then they're empty because the drafts are right. No owner — an agent is an operational hire and needs a manager: one named person who reviews its output, tunes its instructions, and answers for its KPIs. "Everyone's agent" is nobody's agent, and it drifts.

Start with the document, not the tool

Scoping an agent this way is about a day of work, and it determines whether your next six months of automation compounds or embarrasses you. Pick one high-volume, low-blast-radius task, write the one-page job description — tasks, exclusions, permissions, escalation table, KPIs, review date — and only then evaluate tools against it. If you want a second set of eyes on which role to hire an agent into first, or CTO-level help pressure-testing the scope, that's the kind of working session we run with founders at Startupp every week. Write the job description first. Everything after it gets easier.