Skip to content
Data McFly.
Back to writing

writing

Job Descriptions for Agents: A Template

Jul 29, 2026· 6 min read· Roger Stringer

If you take one thing from how we build agents that actually hold up in production, make it this: write the agent a real job description before you deploy it. Not a prompt. A job description, the same document you'd write for a person you were about to hand real work to.

Most flaky agent behavior traces back to a missing or vague brief. We covered why in Your First AI Agent Is a New Hire. This is the practical follow-up: the actual template we use, with every field explained, so you can write one for your own agents today.

Why a job description, not a prompt

A prompt tends to describe a task. A job description describes a role: what it owns, where its authority ends, what good looks like, and who it answers to. That difference is the difference between an agent that does something and an agent you can actually trust with the work.

The other benefit is that a job description is reviewable. A vague prompt can't be graded, which means it can't be improved or held to a standard. A real spec gives you something to run a performance review against later.

The template

Copy this, fill in every field, and don't skip the ones that feel obvious. The obvious ones are usually where the trouble hides.

Role title. One line. "Inbound lead qualifier," "Tier-1 support drafter," "Invoice reconciliation assistant." Naming the role forces you to decide what this agent is, singular. If you can't name it in a few words, the scope is too broad and you should split it into two agents.

Mission. One or two sentences on why this role exists and what outcome it's responsible for. Not the steps, the point. "Make sure every inbound lead is scored and routed to the right rep within five minutes, so nothing sits in the queue going cold."

Owns (in scope). The specific tasks and decisions this agent is responsible for. Be concrete. "Reads each inbound lead, scores it against our ICP criteria, enriches it from these two sources, routes it to the right rep, and drafts a first follow-up." If it's not on this list, the agent doesn't do it.

Does not own (out of scope). Just as important, and almost always skipped. The things this agent must not do, even if it technically could. "Does not send the follow-up without rep approval. Does not contact a lead already owned by another rep. Does not score enterprise leads, which route straight to a human." This is where you prevent the confident, out-of-bounds mistake.

Tools and access. Exactly which systems, data, and tools the role gets, and at what permission level. Read-only where read-only is enough. Scope this like you'd scope a new hire's logins: enough to do the job, not enough to cause an incident. An agent with more access than its role needs is a liability, not a convenience.

Context it needs. The information the role depends on to do good work: your ICP definition, examples of well-qualified versus poorly-qualified leads, the routing rules, tone guidelines. This is the onboarding wiki. Underfill it and the agent does generically-correct work that misses how your business actually operates.

Definition of good. What a great output looks like, concretely enough to grade. Include a couple of real before-and-after examples if you can. This is the standard every future review measures against, so if you can't write it, that's the first work to do.

Failure handling. What the agent does when it's unsure, when data is missing, or when an input is outside its scope. The default should almost always be escalate to a named human, not guess. "If the lead is missing a company name, or matches an existing account, or scores in the ambiguous middle band, flag it to the rep instead of acting."

Human gate. Which decisions require a person to sign off before action, and which run autonomously. Match this to the stakes: reversible and low-cost can run on its own with sampled review, high-stakes or customer-facing gets a human before the action fires.

Owner. The named person accountable for this agent's output. Not "the team." A person. If something goes wrong, this is who owns it and who decides what changes. An agent without an owner is an open accountability question waiting to surface at the worst time.

A worked example

Here's the template filled in for a single agent, so you can see the shape it takes in practice:

  • Role title: Inbound lead qualifier
  • Mission: Score and route every inbound lead to the right rep within five minutes, so nothing sits in the queue going cold.
  • Owns: Reading each lead, scoring it against our ICP criteria, enriching it from our data provider and CRM, routing to the right rep, drafting a first follow-up.
  • Does not own: Sending the follow-up (the rep approves), contacting a lead already owned by another rep, scoring enterprise leads (those go straight to a human).
  • Tools and access: Read access to the CRM and the enrichment API. Write access only to the lead record and a draft-email field. No send permission.
  • Context it needs: The ICP definition, ten examples of well-scored versus poorly-scored leads, the routing map by territory and segment, first-touch tone guidelines.
  • Definition of good: Correct score and routing on 95% of leads measured against rep feedback. Follow-up drafts a rep would send with only light edits.
  • Failure handling: Missing company name, a match to an existing account, or a score in the ambiguous middle band all get flagged to the rep instead of acted on.
  • Human gate: The rep approves every outbound email. Scoring and routing run autonomously.
  • Owner: The RevOps lead.

That's a real job. It can be onboarded, measured, coached, and held to a standard, which is everything a bare prompt can't be.

Use it as a living document

A job description isn't write-once. When you coach the agent by improving its context or tightening its scope, update the spec. When a review shows it's earned more autonomy, widen the scope on paper first. The document should always describe what the agent is actually responsible for right now.

This is the foundation of the 70/30 Method in practical form. A clear job description is what lets an agent safely own its 70, because you've defined exactly where the 30, the human judgment, takes back over.

If you want help turning a pile of clever prompts into a set of agents with real job descriptions, scoped access, and owners, that's the Agentic OS work I do with clients. Let's talk.