By Oliver · AI Architect, BuildAClaw · October 16, 2026 · 9 min read

How to Write the Job Description for Your First AI Worker

A 7-part template that turns a vague "automate my inbox" wish into a worker that performs on day one, and keeps performing on day 90.

Of the first-week AI worker deployments we've reviewed, roughly 7 out of 10 problems traced back to the brief, not the model. The hardware was fine. The software was fine. The instructions were a two-line paragraph that would confuse a human new hire too.

Here's the pattern I keep seeing. A business owner buys a Mac Mini M4, installs OpenClaw, types "handle my customer emails," and then wonders why the worker either does nothing or does too much. In our analysis of 138 user pain points, 88 were setup problems. Most of those weren't install errors. They were people not knowing what to tell the thing to do.

If you'd write a real job description for a $20-an-hour hire, you should write one for a worker that runs 24/7 on your desk. Here's how.

Why "Just Tell It What to Do" Fails

An AI worker isn't a chatbot. A chatbot waits for you to type, answers, and forgets. A worker acts on its own schedule, touches your real tools, and makes dozens of small decisions while you're asleep. We cover that distinction in the difference between an AI chatbot and a true autonomous agent.

That autonomy is exactly why a vague brief is expensive. When you ask a chatbot something ambiguous, you see a weak answer and rephrase. When a worker acts on an ambiguous brief, it sends the email, archives the message, or books the slot. The cost of ambiguity moves from "annoying" to "customer-visible."

Three failure modes show up again and again:

• Scope creep by default. "Manage my inbox" can mean sorting, replying, unsubscribing, or deleting. The worker picks one. It may not be yours.
• No definition of done. Without a finish line, workers either stop too early or loop on work that was already complete.
• No escalation rule. The worker has no idea when to stop and ask you, so it guesses on exactly the cases where guessing is dangerous.

One user in our lead data put it bluntly when asking about a Mac Mini setup: they didn't understand what ongoing costs and effort looked like after the install. That uncertainty is a brief problem too. A scoped job has predictable token use and predictable effort. An open-ended one doesn't.

Step 1: Pick One Job, Not a Department

Your first AI worker should have one job title and one measurable outcome. Not "operations assistant." Something like "Inbound Lead Qualifier" or "Late Invoice Follow-Up Clerk."

Use this four-question filter before you write a single line:

• Frequency: Does the task happen at least 20 times a week? Below that, the setup effort rarely pays back.
• Clarity: Can two reasonable people agree on whether it was done correctly?
• Reversibility: If the worker gets it wrong, can you undo it or apologize cheaply?
• Data access: Does the information the worker needs already live in tools it can reach?

If you want a sanity check on whether a task is ready, read 5 signs your business is ready for an AI worker (and 3 signs it is not). The short version: if a human on your team already does the task from a checklist, it's a strong candidate.

Step 2: Write the Seven-Part Job Description

This is the template we use on every deployment. Each part has one purpose. Skip one and you'll find out why within a week.

1. Role and Mission

Two sentences. Who the worker is and what success looks like. Example: "You are the intake coordinator for Lone Star HVAC. Your mission is to answer every new service request within 5 minutes and book qualified jobs onto the technician calendar."

2. Responsibilities (What You Own)

A numbered list of 4 to 8 specific duties. Use verbs and objects. "Read each new inbound email," "Check the technician calendar for open slots in the next 3 days," "Send a confirmation text." Each line should be something you could verify happened.

3. Boundaries (What You Never Do)

This section is the highest-value 100 words in the whole document. List what the worker must not touch: issuing refunds, quoting custom prices, deleting any message, contacting anyone not already in the CRM. If you only have time to write two sections well, make them this one and escalation.

4. Tools and Data Access

Name every tool the worker may use and the level of access: read-only calendar, send-only email from one address, read/write on one spreadsheet. Because OpenClaw runs locally, this is a permission list on your own machine, not a trust exercise with a cloud vendor. Our guide on giving your AI agent access to your email safely walks through the narrowest-permission approach.

5. Tone and Voice

Three adjectives and two sample messages in your real voice. "Friendly, direct, no exclamation points" plus a pasted example does more than a paragraph of description. If you've never defined this, the SOUL.md framework shows how to give a worker durable personality and judgment.

6. Escalation Rules

Spell out exactly when the worker stops and pings you. Use triggers that are checkable: "any message containing the words lawyer, refund, or cancel," "any job estimated over $2,000," "any customer who has written three times without resolution." Also say how to escalate: which channel, what summary format, and how long to wait before sending a reminder.

7. Success Metrics

Two to four numbers the worker, and you, can check weekly. Response time, jobs booked, escalation rate, error count. This is what lets you decide on day 30 whether the worker is earning its place. We lay out the full measurement approach in how to measure the ROI of an AI worker.

Step 3: Add Examples, Because Examples Beat Adjectives

The single fastest upgrade to any brief is a handful of worked examples. In our pilots, briefs with three to five example input/output pairs reached a usable first output about 3x faster than briefs with instructions alone.

Include at least these three types:

• A clean case. The easy 80%: a standard request and the exact response you'd want sent.
• A borderline case. Something that looks routine but should escalate. Show the escalation message too.
• A refusal case. A request the worker should decline, with the exact wording you'd use.

Pull these from real history. Open your sent folder, find five actual messages you're proud of, and paste them in with the customer's message above each. That's a stronger spec than anything you'll write from scratch.

Step 4: Start With a Supervised Week

Even a good brief is a hypothesis. Treat week one as a probation period. We recommend a draft-only mode for the first 5 business days: the worker prepares every action, and you approve it in a single daily review. That review takes about 10 to 15 minutes and produces the best edits you'll ever make to the brief.

This mirrors the approach in the 7-day AI worker pilot and the checklist in your first week with an AI worker. The loop is simple:

• Review: Read the worker's drafted actions each morning.
• Mark: Tag each one approved, edited, or rejected.
• Patch: For every edit or rejection, add one line to the brief. Not a rewrite. One line.
• Graduate: Once approval hits 95% for three straight days, switch that category to autonomous.

In our deployments, the typical first-week approval rate sits around 70%. By the end of week five, with weekly patching, it's above 92% and the escalation rate has dropped from about 31% to under 10%. That curve only happens if you keep editing the brief. The worker doesn't learn from silence.

Step 5: Local Hardware Changes What You Can Safely Put in the Brief

Here's the angle nobody writing about AI prompts covers. Where the worker runs changes what you can ask it to do.

With a cloud assistant, every piece of context you put in the brief (customer names, price lists, internal rules) travels to a third-party server. Many owners quietly leave the good stuff out for that reason, and then wonder why the worker is generic. With OpenClaw on a Mac Mini M4 in your office, the brief, the memory, and the customer data stay on your machine. You can include your real pricing logic, real customer history, and real policy exceptions without a data-sharing conversation.

There's a cost angle too. A tight brief means fewer wasted tokens on clarifying loops and retries. If you pair local models with a hosted one like Claude Sonnet 4.6 only for hard cases, a scoped worker typically runs at a fraction of the cloud-only cost we broke down here. Precision in the brief is the cheapest optimization you have.

One caution from the community: a Reddit commenter warned that people "take it too easy" with these tools, and they have a point. A worker with broad access and a loose brief is a real risk. That's why section 3 (boundaries) and section 4 (tool access) are not optional.

A Complete Example You Can Copy

Here's a compressed version of a real brief structure for a plumbing company's intake worker. Adapt the details, keep the shape.

• Role: Intake coordinator for Austin Pipe & Drain. Mission: respond to every new request in under 5 minutes, 7am to 9pm.
• Owns: Reading new web-form and email requests; checking technician calendar; proposing two time slots; sending confirmation; logging the job in the spreadsheet.
• Never: Quote prices above the published service-call fee; promise same-day service after 4pm; contact anyone outside the request thread.
• Tools: Read-only calendar, send-from intake address, read/write on the "Jobs" sheet.
• Tone: Friendly, plain, Texas-direct. No exclamation points. Sign off with first name only.
• Escalate when: The message mentions flooding, gas, or a lawyer; the customer replies angrily; the job is commercial. Ping the owner by text with a 2-line summary.
• Metrics: Median response time under 5 minutes; 60%+ requests booked; escalation under 10% by week five.

That's about 130 words of skeleton. Add 3 to 5 examples and the changelog, and you land in the 500 to 700 word range that works.

Frequently Asked Questions

How long should an AI worker job description be?

One to two pages, roughly 400 to 800 words. Shorter than that and the worker guesses at edge cases. Longer and the important rules get buried. Our best first-version briefs landed around 550 words and grew 10 to 15 percent as real edge cases surfaced.

Do I need to know how to code to write one?

No. A good job description is plain English, written the way you'd brief a new hire. If you can write a training doc for a part-time employee, you can write this. The technical work of loading it into OpenClaw and connecting tools happens during setup.

What is the best first job to give an AI worker?

Something repetitive (20+ times a week), with a clear right answer and low downside if it goes wrong. Email triage, appointment reminders, lead qualification, and invoice follow-ups are the usual winners. Avoid legal judgment or irreversible payments for the first 30 days.

How often should I update the job description?

Weekly for the first month, then monthly. Each time the worker makes a mistake or escalates something it should have handled, add one line. Most stable workers see escalation fall from around 30% in week one to under 10% by week five.