AI Employee Job Description: The One-Page File That Tells an Agent What the Role Owns and Where It Stops

Most people hire an AI agent the way they would hire a stranger on a busy Friday: a vague request, no boundaries, and a hope that it works out. Then the agent does something nobody asked for, or nothing at all, and the verdict is that AI is not ready.

The fix is the same one you would use for a human hire. Write the job description first. An AI employee job description is a short file the agent reads at the top of every run. It says what the role owns, what it never touches, when it works, and what a finished day looks like.

This post walks through what goes in that file, using the structure of the open source kit I teach, so you can write one for any role in your own business.

What is an AI employee job description?

It is a plain text file, written in ordinary sentences, that defines one role. The agent loads it before doing any work. Think of it as the difference between telling a contractor "handle my marketing" and handing them a one page charter.

A good one answers five questions:

• What does this role own?

• What does it read, and what does it write?

• Where does it stop and ask a human?

• When does it run?

• What does a good result look like?

If a reader cannot answer all five from the file alone, the agent will fill the gaps with guesses. Guesses are where the damage comes from.

If you want the broader picture of what makes an agent an employee rather than a chat window, the AI chief of staff post covers the role I would hire first.

Why does an AI employee need a written role at all?

A chat prompt disappears when the window closes. A role file does not. It sits in the project, and every scheduled run starts by reading it. That is the whole trick behind an agent that behaves the same way on Tuesday as it did on Monday.

The Claude Code documentation on memory describes the same idea at the tool level: instruction files that load at the start of a session so the agent starts every run with the same context. A role file is that mechanism pointed at a business job.

Without it, you get three predictable failures:

• Drift. Each run interprets the job a little differently.

• Scope creep. The agent decides a nearby task is also its job.

• Silent gaps. Nobody wrote down a duty, so nobody does it.

What goes in the first paragraph?

One sentence on what the role is for, and the single question it answers on a schedule.

The Chief of Staff role in the open source AI Employees kit is a good model. Its charter says the role watches the other employees. It owns one question every weekday morning: what actually ran yesterday, and what did not. It owns a second question every week and a third every month.

Notice what that does. The role is not "help with operations." It is three named questions on three named rhythms. A reader, human or agent, can tell in ten seconds whether a task belongs to it.

Write yours the same way. Finish this sentence: "This role exists to answer ___ every ___." If you cannot, the role is not one role yet.

How do you set the boundaries?

Boundaries are the most valuable part of the file, and the part most people skip.

The Chief of Staff charter is blunt about it. The role is read only toward the world and read only toward every other employee. It posts nothing, sends nothing, deploys nothing, and spends nothing. The brief it writes is the product.

That is a complete boundary in one paragraph. You can copy the pattern:

1. List what the role may read.

2. List what the role may write, and where.

3. List the verbs it never uses, in plain words: send, post, publish, delete, pay, deploy.

4. Name the one place it stops and waits for a person.

The fourth item is the human checkpoint. I wrote about the mechanics in the AI agent approval workflow post: the agent stages the work, a person presses the final button. A job description is where that rule gets written down so it survives every run.

What is the contract file, and do you need one?

In the kit, a second file called the contract sits beside the role file. It is the spine: it says which files exist, which routine writes to which file, and what the format of each one is.

Its first rule is worth stealing. One writer per rewritten file, and named appenders for any file that only grows. Two routines never write to the same file, so two routines never overwrite each other.

You do not need a contract file for your first role. You do need the idea. Before you schedule anything, decide where the agent writes its output and make sure nothing else writes there. Most "the agent broke my notes" stories are two jobs sharing one file.

How do you write the schedule?

Put every clock time in one place and nowhere else. In the kit, a schedule file holds the cadence, the window each routine may fire in, and the budget for each run. The routine instructions themselves never carry a clock time.

The reason is practical. When you want to move the morning run from seven to eight, you change one line in one file, and no routine instruction goes stale.

A schedule row needs four fields:

• The days it runs.

• The window it may start in.

• The budget for the run, so a stuck job cannot run all night.

• What it does if it cannot find its own row. The kit's answer is to record a failure and exit rather than guess.

That last rule is the one to copy. An agent that cannot find its instructions should stop and say so, not improvise.

What should the job description say about failure?

Say what happens when the run does not finish. Three lines cover most of it:

• Record a status of failed, with the blocker named in a sentence.

• Do not retry the same blocked step on the next run without new information.

• Surface the failure in the next morning brief instead of hiding it.

The AI morning briefing post shows the format I use for that brief. The point here is only that failure handling belongs in the role file. If it lives in your head, the agent will not know it.

How do you keep the file useful after week one?

Treat every correction as an edit to the role file, not a chat message. When the agent does something you did not want, write one sentence in the file that prevents it, then move on.

The one sentence fix for repeated mistakes post covers how to phrase those sentences. A role file that gains one good sentence a week is a very different thing after two months than the one you started with.

Keep three habits:

• Read the file top to bottom once a month and delete anything that no longer applies.

• Keep precedence explicit: your own workspace rules beat the kit, the contract beats the role file, and so on down the list.

• Never put a secret or a password in the file. It is read on every run.

A template you can copy today

Open a blank file and write these headings in plain text, then fill each one with two or three sentences:

1. Purpose. The question this role answers, and how often.

2. Reads. The places it may look.

3. Writes. The one folder it may change.

4. Never. The verbs it does not use.

5. Stops and asks. The single checkpoint where a person decides.

6. Schedule. Pointer to the schedule file, not a clock time.

7. Done means. What a finished run leaves behind.

That is enough to hire a first employee. Run it for a week, correct it in the file, and it will be a better role on day eight than day one.

Where can you see real job descriptions?

The eight roles in the AI Employees kit each have a full role file, a contract, a schedule and an install prompt. The repo is open source under an MIT license, so you can read them all for free at the AI Employees repository on GitHub. Reading the Chief of Staff role file next to the Sales role file shows how the same skeleton adapts to a different job.

I walked through the eight roles in a live session, and the full replay is available instantly on the Open Source AI Employees session page. If you would rather see it than read it, start there.

FAQ

How long should an AI employee job description be?

Long enough to answer the five questions and no longer. A first version fits on one page. The kit's role files are longer because they define a full role with many routines, but you can start with the seven headings above and grow from there.

Should the job description be written for the agent or for me?

Both, and that is the benefit. Plain sentences that a new human hire could follow are also the sentences an agent follows best. If you could not hand the file to a person and have them understand the job, rewrite it.

Can one agent hold several roles?

You can, but it is easier to debug one role per file. When a run goes wrong you want to know which charter it was following. Keep the roles separate, and let a coordinator role read across them if you need an overview.

What if the agent ignores part of the file?

Make the rule shorter and more specific, and move it nearer the top. Vague rules get skipped. A rule like "never send anything" holds up better than "be careful with outbound messages."

Do I need a paid tool to do this?

No. The role file is text, and the kit is free and open source. It runs inside the agent app you already use.

Start with one role, in writing

If you want the eight roles already written, with schedules and install prompts, the Agent Ops Club has a free plan, and the AI Employees page shows each role and what it covers. Pick one, read its charter, and change a sentence to fit your business. That is a faster start than a blank page.