Autonomous AI Agents: How to Give One a Real Job

Search autonomous ai agents and the first page is Microsoft, Salesforce, Snowflake, NVIDIA, AWS, IBM, Teradata and half a dozen platform vendors. Every one of them defines autonomy as something the model has: it perceives, it plans, it decides, it acts without human input. Every one of them is also selling the runtime.

Not one of them tells you what to write down before you turn the thing loose.

That gap is the whole problem. Autonomy is not a property of the model. It is a property of the boundary you drew around it. Autonomous AI agents are autonomous to exactly the degree that someone has written down what they may decide alone, what they must hand back, and where they go when they are stuck. Skip that step and you do not get the agent in the brochure — you get a fast intern with no manager and no job description, which is a different and much more expensive thing.

The artefact that closes the gap is a role package: a folder on disk that defines one job for one of your autonomous AI agents. This article covers what goes in one and why a persona prompt is not a substitute, what it costs to work without one, what sixteen role packages look like when they are in daily use, and how to build your first one tonight in about an hour.

What are AI agents, for the purposes of this article — Any AI doing work on your behalf across more than one step: an assistant you have handed a long job, a coding tool in your terminal, a scheduled process that drafts and files things. The model matters less than you would think. What matters is whether the thing acts repeatedly, because repetition is what turns a vague instruction into a compounding error.

What a role package is, and why autonomous AI agents need more than a prompt

Start with the thing almost everyone tries first, because it is worth knowing exactly why it fails.

Why persona prompts fail autonomous AI agents

The standard advice is to open with an identity claim. You are an expert marketing strategist. You are a senior financial analyst. It is the single most repeated instruction given to autonomous AI agents, and it feels like it should work. It has been tested at scale, and it does not.

Zheng, Pei, Logeswaran, Lee and Jurgens built a set of 162 personas spanning 6 kinds of interpersonal relationship and 8 domains of expertise, then ran them against 2,410 factual questions across four families of large language models. The finding, in the paper's own words, is that adding a persona to the system prompt does not improve model performance compared with the control setting where no persona is added. Some personas mildly hurt. And when a persona did help, no rule predicted which one — picking at random worked about as well as picking carefully (When "A Helpful Assistant" Is Not Really Helpful, arXiv:2311.10054).

This result gets misread as "roles do not work for autonomous AI agents." That is the wrong lesson. What the study tested was the label — the identity sentence and nothing else. Of course the label alone does nothing. Telling a new hire "you are a senior analyst" on their first morning and then walking away does nothing either.

A job description is not the job title. The title is one line at the top. The document underneath is what makes the hire productive, and none of it is flattery:

• what you are responsible for
• what you are explicitly not responsible for
• what to do when the answer is not obvious
• who to escalate to, and when
• where the procedures are kept

Strip those five out and you are left with the persona sentence — the exact thing the research measured and found inert. Keep them and you have a role package.

The five parts a persona does not have

Here is the structure I use, and what each part is actually for.

The do-not list is the one people leave out, and it is the one that does the most work. A capable model asked to write an article will also happily rewrite your pricing page, refactor the publishing script, and invent a competitor comparison — not out of malice, but because nothing told it those belong to someone else. This is what actually makes autonomous AI agents expensive. Not incompetence: competence pointed at work nobody assigned. Every item on a do-not list should name its owner. Does not modify tool code — that belongs to the engineering role. An unowned prohibition just creates a dead end; an owned one creates a handoff.

Autonomous AI agents are defined by a written boundary

The escalation path deserves its own paragraph, because it is where the vendor definition of autonomy and the working definition part company.

Regulators arrived at this before most vendors did. Article 14 of the EU AI Act requires that high-risk systems be designed so a person can decide not to use the system, disregard, override or reverse its output, and intervene in or interrupt operation through a stop procedure that brings it to a halt in a safe state (Article 14, AI Act Service Desk). Read that as engineering guidance rather than compliance text and it says something simple: the design question for autonomous AI agents is not how much the system can do alone, it is where the seam is.

Most people deploying autonomous AI agents never draw that seam, then discover it the hard way. Writing it into the role card is a five-minute job. Here is the escalation path from one real role card, unedited in substance:

• Topic direction unclear → ask the owner
• Anything naming a competitor, or comparing prices → ask the owner
• Before publishing → the workflow's own approval gate, not the role's judgment
• Data anomaly, such as a ranking collapse or a traffic drop → notify the owner immediately

Four lines. Notice that three of the four are not about capability at all — the agent is perfectly capable of writing a competitor comparison. They are about consequence. That is the right axis. An escalation path built around "what is the model bad at" ages badly as models improve, which is why so many teams rewrite the rules for their autonomous AI agents every time they change model. One built around "what is expensive to get wrong" stays correct.

The test for a good escalation rule — If the worst case is a bad paragraph, let the agent decide. If the worst case is a published claim about a named competitor, a wrong price, or a customer email, make it stop. Cost of being wrong, not difficulty of the task.

Where the format is heading

This is not a private convention. The industry converged on it within about a year.

Claude Code defines subagents as Markdown files with YAML frontmatter, each carrying its own system prompt, its own scoped tool list and its own permissions, in .claude/agents/ — and notably, a subagent does not inherit the parent's full default prompt, so what you write is what it is (Claude Code documentation). OpenAI released the AGENTS.md convention in August 2025 and donated it to the newly formed Agentic AI Foundation in December of that year, alongside Anthropic's Model Context Protocol.

Different vendors, same shape: plain Markdown, in a folder, next to the work. That convergence is what makes role packages portable — the same folder is readable by commercial tools and by open source AI agents alike, because none of it is a proprietary format. The jobs you write for your autonomous AI agents are not locked to whichever tool you happen to be running this quarter, which is worth holding onto given how fast that changes.

What it costs to run autonomous AI agents without one

The cost is not dramatic. It is a slow tax, and it comes in three forms.

You re-explain yourself every single morning. Every session opens with the same paragraph: who I am, what we sell, how I like things written, what you must not touch. Five minutes a session, several sessions a day. But the time is the smaller half of the loss.

You never retype it the same way twice. This is the real damage. On Monday you write "don't touch the pricing page." On Thursday, in a hurry, you write "focus on the blog." Thursday's version contains no prohibition at all, so Thursday's agent edits the pricing page, and it is not wrong to — you did not tell it not to. The output quality now varies with how carefully you happened to phrase the setup, which is a variable you cannot see and do not control. People experience this as "the model got worse this week." Usually the model is identical and the briefing drifted.

Nobody knows where the boundary is, including you. Without a written do-not list, the boundary lives only in your head, which means it does not exist for any purpose. Two failure modes follow. The agent oversteps — quietly, into work it is bad at, and you find out downstream. Or it under-steps, checking in on trivia because nothing told it what it may decide alone, and now supervising it costs more than doing the work.

There is a fourth cost that only appears once you run more than one of these autonomous AI agents: you cannot delegate between them. If role definitions live in your head, every handoff routes through you, and you have built a hub-and-spoke system with yourself as the bottleneck. The moment the definitions live in files, one agent can read another's do-not list and route around it without asking.

The cheap diagnostic — Open your last five AI sessions and compare the opening messages. If they say meaningfully different things about the same job, you do not have a role. You have a mood.

Sixteen role packages: what autonomous AI agents look like in practice

Here is the working system, with real counts as of 10 August 2026.

The directory

The roles folder holds 17 directories. Sixteen are roles. The seventeenth, shared/, holds assets that every role reads and none of them owns.

Two design decisions inside that table matter more than the headcount.

The auditor role takes no assignments from anyone but the owner, and its conclusions are not relayed through another role. If a challenge function can be tasked by the thing it challenges, it is not a challenge function. This costs nothing to implement — it is one sentence in a role card — and it is the sentence most multi-agent setups are missing.

The two social-account operators own one account each and never cross. The division is a single line: the content role decides how the platform gets played; the operator role decides what its own account posts today. They share platform mechanics — rate limits, what gets throttled, which scripts break — and share nothing at the account level. Roles that "help out with" each other's accounts produce output where you cannot tell afterwards which set of rules was applied.

Sizes are uneven, and that is correct — autonomous AI agents do not need equal amounts of instruction any more than employees do. The largest role holds 43 Markdown files. The two smallest hold five each. A role package is a job, not a quota — if the job genuinely fits in five files, five files is the right answer, and padding it makes the role slower to load for no gain.

One role card, all five axes

The content role's card is 174 lines. Every section below is quoted in substance from the live file.

Identity. One sentence plus a trust level: an end-to-end content role covering creation, growth and analysis, at trust level L1 — may write files in the knowledge base, may not publish externally. Reports to the owner and to the general-manager role.

Mission. Write, measure, adjust — topic selection through drafting through distribution through review, closed by one role rather than handed across four.

Does. Sixteen items, listed flat, no grouping: writing articles and posts and newsletters; executing scheduled publication; enforcing brand voice; fact-checking; topic planning; platform performance review; growth strategy; search and answer-engine optimisation; link building; choosing the angle on replies; competitor benchmarking; A/B experiments; cross-platform sequencing; metric design; funnel and attribution analysis; anomaly detection.

Does not. Four items, each naming an owner:

Escalation path. The four conditions quoted earlier.

Beyond the five axes the card carries two more sections that turned out to matter as much:

A decision framework for the cases where the do-list and do-not list both apply and the role still has to choose. It is written as if-then, not as principle. Torn between topics: prefer the one on the current strategic line; if both qualify, prefer the one closest to a format that has already worked, and check the record rather than your memory. Priority conflict: already-scheduled beats a time-sensitive item with a three-day window, which beats general backlog — and if the time-sensitive item is not genuinely urgent, do not interrupt the schedule. Vague guidance produces vague behaviour; a rule with a number in it does not.

And an evaluation standard, three grades, written from the reviewer's side rather than the worker's:

• Pass — every workflow gate cleared, on brand, no factual errors, publishable as-is
• Strong — lands a format with a track record or opens a new one, has a route back to the site, reads clearly on first pass
• Fail — assembled without following the process, brand voice contaminated from another brand, factual errors, or needs heavy rewriting by the owner

That last line is the useful one. "Needs heavy rewriting by the owner" is defined as failure, not as normal. Most people accept heavy rewriting as the cost of working with AI. Naming it a failure state is what makes the gap visible enough to close, one accumulated preference at a time.

The manual shelf: 42 files behind one role

The role card says what the job is. It does not say how to do any of it. That lives one level down, in an operating-manual folder holding 42 files, indexed by a single file at the top.

Three things make this shelf work rather than rot.

The index is the source of truth, not the role's memory. The card carries an explicit instruction: the full manual list is in the index — if a manual is not named above, look it up there instead of guessing whether it exists. This is not decoration. Auditing this system for the article, I found the role card referencing a current-month schedule file that does not currently exist in the folder. An agent that trusted the card and skipped the index would have gone looking for a file that is not there. One that reads the index sees the real 42 and moves on. Any role card long enough to be useful will eventually drift from its own folder; the fix is not better discipline, it is making the generated index authoritative.

Manuals load on demand, not at startup. Forty-two files will not fit in a session opening, and should not. This is how autonomous AI agents stay fast as the shelf grows: the map is loaded, the territory is not. The card names the seven files to read on load; the other thirty-five are opened when a task calls for them. This is the practical difference between a role package and a giant system prompt — a system prompt has to carry everything it might need, while a folder only has to carry a map.

Lessons files are append-only and dated. When something goes wrong, the correction goes into the lessons file rather than into a verbal reminder that evaporates. One standing rule keeps that file honest: a one-off success does not become a rule — confirm it two or three times before promoting it. Otherwise the lessons file fills with superstition.

Three places content can live, and the test for which

With sixteen roles, the obvious failure is duplication: the same guidance copied into sixteen folders, updated in four of them, silently contradictory in the rest. The rule that prevents it is a three-way split, decided by one question — what makes this change?

The shared folder holds 7 files — six shared documents plus an index — and every role points at them rather than copying them. Change one file, sixteen roles are current. There is no synchronisation script, because there is nothing to synchronise.

The most valuable of the six is the who-does-what routing table, which spends most of its length on the boundaries people get wrong rather than the ones they get right. Two examples:

• A broken tool goes to the infrastructure role; a broken product feature goes to the development role. The distinction is which folder the code lives in, not how the symptom feels.
• Roles that produce reports do not modify anything. Quality, customer, investment and audit roles return findings. Acting on a finding is a second assignment to a different role. Blur this and your auditor starts editing the thing it was auditing.

That file also carries a rule that reads like organisational politics but is really a routing constraint: before assigning anything, ask whose job description this is in — do not default to the coordinator. A coordinator role is for when you genuinely do not know who owns the work. Used as a default inbox, it becomes a second bottleneck exactly where you were trying to remove the first one.

How a role loads

The mechanism is deliberately dull, which is why it survives tool changes.

You start the agent from inside the role folder, so the role folder is the working directory:

# The role is the directory. Nothing else is configured.
cd ~/kb/dashboard/roles/content-manager
claude

The runner then walks up the directory tree and reads the instruction file at every level it passes:

roles/content-manager/CLAUDE.md   ← this role: identity, does, does not, escalation
roles/CLAUDE.md                   ← how roles work in general, and the full role index
dashboard/CLAUDE.md               ← how the operations layer works
kb/CLAUDE.md                      ← global rules: language, tools, safety limits

Four files, most specific last to load and first to win. Nowhere in this does anyone type "you are the content manager." For autonomous AI agents loaded this way, the identity is the path. That is worth pausing on, because it removes the exact failure the persona research documents — there is no identity sentence to phrase differently on a bad day, and therefore no drift.

The card closes by requiring a read-back before work begins. In English the equivalent is roughly: I am the content role for {brand}. Today's schedule is {item}. I will run it through {workflow}. One line, but it is a checksum — if the brand is wrong or the schedule is empty, you find out in the first three seconds rather than after 5,000 words.

Two properties follow from doing it this way. Roles that are needed constantly get a permanent window and keep their accumulated context; roles that are needed occasionally get loaded into any free window, do the job, and are released. And because the whole definition is files in a directory, switching to a different AI agent platform means changing the launch command, not rebuilding the roles. The platform supplies the runtime; the folder supplies the job.

If your tool has no working-directory concept — Paste the role card as the first message and keep the file as the source of truth. You lose automatic loading and keep everything else. The folder is the durable part; auto-loading is a convenience.

Trust levels, and why they are not permissions

One more field appears on every card: a trust level.

• L1 — may write files inside the knowledge base, may not send anything externally
• L2 — may publish externally within its own defined scope

This looks like an access-control system and is not one. Nothing enforces it at the file-system level. It is a declared level, written into the card, and its purpose is to make the blast radius of a mistake legible before you assign work. When you hand a task to an L1 role, you know the worst outcome is a bad file you can delete. Hand it to an L2 role and the worst outcome is public.

Real permissions belong in the runner and the credentials, and you should set those too. But the declared level is what lets you decide, in the two seconds before assigning something, whether this is a job you can walk away from. That decision happens hundreds of times and needs to be cheap.

Build a role package for autonomous AI agents tonight

About an hour, and you need a folder and a text editor.

Before you start. A role package is a folder the AI reads at startup, so it only pays off with a tool that picks up instruction files from your disk — a web chat window cannot switch roles by directory. If you have not installed one, start here. Any tool on that list will load the folder you are about to build.

Step 1 — Pick a role you already supervise

Not an aspirational one. The best AI agents examples to copy first are jobs you have done yourself often enough to know where they go wrong: a writer, a bookkeeper, a researcher, a support responder. You need the do-not list, and the do-not list only comes from experience.

Skip coordinator and manager roles for now. Coordination is the hardest thing to specify and the first thing to go wrong.

Step 2 — Make the folder

mkdir -p ~/my-work/roles/content-writer
cd ~/my-work/roles/content-writer
touch CLAUDE.md daily-work.md

Two files. The role card, and what the job looks like on a normal day. If you use a tool that reads AGENTS.md, link them so there is only ever one file to edit:

ln -s CLAUDE.md AGENTS.md

Step 3 — Write the role card

Five sections. Keep it under 60 lines the first time; you will add to it as things go wrong, and a short card that gets read beats a long one that gets skimmed. The headings below belong inside your file, not to this article.

# Content Writer

## Identity
I draft and revise written content for {your business}.
Trust level: L1 — I write files, I never publish or send anything.
I report to: {your name}.

## Mission
Take a topic from brief to a draft that needs light editing, not a rewrite.

## I do
- Draft articles, emails and social posts
- Rewrite and tighten existing drafts
- Write headlines and subject lines, three options each
- Check facts against the sources in `reference/`
- Flag anything I could not verify

## I do not
- Touch pricing or offers            → that is {who}
- Send or publish anything           → that is {who}
- Change the brand voice file        → that is {who}
- Contact customers directly         → that is {who}

## I stop and ask when
- The brief conflicts with `standards/brand-voice.md`
- A claim needs a number I cannot source
- The topic names a competitor or compares prices
- I am about to write something I have not written before for this business

## How I decide
- Two angles both fit → pick the one closer to a piece that already performed; check the file, not memory
- Tone unclear → open `standards/brand-voice.md` and find the nearest published example; if still unclear, produce two versions
- Deadline conflicts → scheduled work first, then anything with a real time window, then backlog

## Done means
- Pass: on brief, on voice, facts checked, needs only light edits
- Fail: needs a rewrite, wrong voice, or contains a claim I could not source

Step 4 — Write the daily-work file

Shorter, and easy to underrate. It answers "what does this job normally involve," which is what a fresh session needs in order to stop asking.

# Content Writer — Normal Week

## Regular work
| Job | When | How |
|---|---|---|
| Blog draft | Mondays | Read `standards/brand-voice.md`, then the brief in `inbox/` |
| Newsletter | Thursdays | Reuse the week's blog, cut to 400 words |
| Social posts | As needed | Three options, no links, no hashtags |

## Occasionally
| Job | How often | Note |
|---|---|---|
| Refresh old posts | Quarterly | Check facts and dates first |
| Update the lessons file | After every correction | One line, dated |

## Not mine — send it to
| Request | Owner |
|---|---|
| Anything about price | {who} |
| Images and design | {who} |
| Publishing | {who} |

Step 5 — Run it, then correct it into the file

Point the tool at the folder, or paste the card as the first message. Give it one real task — something you were going to do anyway, so you can compare.

Then the part that decides whether any of this compounds: when you correct the output, put the correction in the file, not just in the chat. This is the only way autonomous AI agents accumulate anything — a correction that stays in the conversation is gone when the conversation ends. Four or five rounds of this and the card starts answering questions before you ask them.

Add a third file when the first correction is worth keeping:

touch ~/my-work/roles/content-writer/lessons.md

One line per lesson, dated, anchored to what actually happened. 2026-08-10 — used a statistic with no source; from now on, unsourced numbers get cut or stated qualitatively. Not "be more careful."

The naming bridge

The system described above runs in Chinese; the file names here are the English equivalents, in case you want to mirror the structure.

The prefix is doing real work: it tells the agent whether a file contains steps to follow, a way to think, or a record of what went wrong — before the file is opened. That is what lets a role with 42 manuals pick the right three.

The prompt

Paste this into any assistant that can write files. Fill the braces first.

Build me a role package: a folder on disk that defines one job for an
AI agent, so that I never have to explain that job again.

Context, filled in before you start:
- My business: {one sentence}
- The role I want: {job title, e.g. content writer}
- What it produces: {the artefact, e.g. blog drafts and newsletters}
- What it must never do: {2-4 things, each naming who owns it instead}
- When it must stop and ask me: {2-4 conditions, chosen by cost of
  being wrong, not by how hard the task is}

Create this structure:

roles/content-writer/
  CLAUDE.md        the role card, read at the start of every session
  daily-work.md    what this job normally involves
  voice-rules.md   how the writing has to sound

The role card carries these sections, in this order, and nothing else:
1. Identity — one sentence, plus a trust level (L1 = writes files
   only, L2 = may publish), plus who it reports to.
2. Mission — the outcome this role owns end to end, one sentence.
3. Does — 5 to 8 items, flat list, specific verbs, no grouping.
4. Does not — 3 to 5 items, each naming the owner it goes to instead.
   An unowned prohibition creates a dead end; an owned one creates a
   handoff.
5. Stops and asks when — the conditions above, written as triggers I
   could check from the outside, not as judgment calls.
6. How it decides — if-then rules for the cases where the do list and
   the do-not list both apply and it still has to choose. Numbers and
   named files wherever possible. No abstract principles.
7. Done means — pass, strong and fail, written from my side as the
   reviewer. "Needs a heavy rewrite from me" goes under fail, not
   under normal.

daily-work.md: three short tables. The regular work and when it comes
round. The work that happens every so often, and how often. The
requests that are not this role's job, each with the name of who
takes them instead.

voice-rules.md: the three adjectives that describe the tone, one real
paragraph that already sounds right, the list of words we never use,
and the format rules — heading capitalisation, longest allowed
paragraph, list style.

Constraints:
- Keep the role card under 60 lines. Short and read beats long and
  skimmed.
- No praise, no "you are an expert", no personality description. The
  identity sentence does nothing on its own; the scope and the limits
  do all the work.

When the three files are written, show them to me and tell me which
sections you had to guess at. Then tell me how to verify the package:
I will cd into roles/content-writer/ and start a session there, have
you read CLAUDE.md before anything else,
and hand you one real task. Tell me exactly what to look for in your
first reply that proves you are running as the role — and what it
would look like instead if the card was never read.

The two closing instructions each earn their place. Whatever it guessed at is precisely the part only you know, and the part any consultant would bill you to extract in a workshop. And the verification test tells you within one reply whether the folder is being loaded at all — which is the failure people usually discover a week later, after blaming the model.

What to expect — The first version will be roughly 70% right and the missing 30% will be your do-not list, because you have not yet hit the mistakes that generate it. That is fine. A role package is not written once. It is written once and corrected fifty times, and the corrections are the asset.

Common questions

What are AI agents, in plain terms?

An AI agent is a model that has been given a goal, a set of tools, and permission to take more than one step on its own. A chat assistant answers a question. An agent reads a task, decides what to do first, uses a tool, checks the result, and continues until the task is done or it gets stuck. Vendors market these as autonomous AI agents. The interesting part is not the model — it is what the agent has been told about the job before it starts.

Does telling an AI model "you are an expert" actually work?

Not for accuracy. Zheng, Pei, Logeswaran, Lee and Jurgens tested 162 personas across 8 domains of expertise on 2,410 factual questions and four model families, and found that adding a persona to the system prompt does not improve performance compared with adding no persona at all. Some personas mildly hurt. The paper is arXiv:2311.10054. What does change behaviour is the rest of a job description: what the role does, what it must not do, and when it has to stop and ask.

What is a role package?

A folder on disk that defines one job for one of your autonomous AI agents. It holds a role card — identity, mission, a do list, a do-not list, and an escalation path — plus a shelf of operating manuals the role reads when it needs a procedure. You point the agent's working directory at the folder, the agent reads the files, and it is now that role. Nothing is stored in the vendor's account, so the same folder works with a different tool tomorrow.

How is a role package different from a system prompt?

A system prompt is one block of text loaded at startup and rewritten by hand each time you change your mind. A role package is a folder: the role card is loaded every session, and the manuals underneath it are loaded only when a task needs them. That split matters, because a role with 42 manual files cannot fit its whole shelf into a system prompt — and does not need to. It needs an index and the discipline to open the right file.

Are there open source AI agents I can use for this?

Yes, and the file format is now close to standard. Claude Code reads role and subagent definitions from Markdown files with YAML frontmatter, and OpenAI's AGENTS.md convention was donated to the Agentic AI Foundation in December 2025. Because a role package is plain Markdown in a folder you own, it is portable across open source and commercial runners alike. Pick the runner on its merits; keep the role definitions in your own repository.

How many roles should I start with?

One. A role earns its own folder when four things are true at once: its boundary is clear, it has a stable source of input, it produces a defined artefact, and no existing role can absorb the work. Splitting before those conditions are met produces roles that overlap, and overlapping roles are worse than no roles because now you have to decide which one to load.

What are good AI agents examples to copy first?

Copy a role you already supervise in real life: a writer, a bookkeeper, a researcher, a support responder. Those have obvious do-not lists — a writer does not touch pricing, a bookkeeper does not send client emails — and the do-not list is the part that makes a role package work. Avoid starting with a coordinator or manager role; coordination is the hardest thing to specify and the easiest to get wrong.

Do I need an AI agent platform to run role packages?

No. A role package is a folder of Markdown files, so the minimum viable version is a folder and any assistant that can read files. A platform adds session persistence, parallel runs and inter-agent messaging, which start to matter somewhere past three or four concurrent autonomous AI agents. Buy the platform when the coordination hurts, not before — and make sure the roles stay in your folder rather than in the platform's database.

Where this fits

Role packages answer the one question every discussion of autonomous AI agents skips: who is doing this work, and what may they decide alone? A role package sits on top of two things and underneath a third.

Underneath it is the folder — the knowledge base the roles read from and write to, which is what makes any of this survive a change of tool. Underneath that are the rules: the written standards a role loads before it acts, which is what keeps sixteen roles producing consistent output rather than sixteen dialects.

Above it is coordination — how work moves between roles, which is a genuinely harder problem and worth having exactly one role before you try to solve it.

Start with one. Autonomous AI agents do not become useful in bulk; they become useful one written boundary at a time. A single folder, five sections, corrected after every job. The compounding starts on about the fourth correction, when you notice you did not have to explain something you would previously have explained every morning.

Related tutorials

• AI for Small Business: The Knowledge Base That Outlasts Every Model — the folder the roles live in
• AI Tools for Business: Four Questions, Ten Folders — where the roles folder sits in the structure
• No Rules, No Results: Why Every AI Agent Needs a Spec — the standards a role reads before it acts

Sources

• Mingqian Zheng, Jiaxin Pei, Lajanugen Logeswaran, Moontae Lee, David Jurgens, When "A Helpful Assistant" Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models, arXiv:2311.10054
• Article 14: Human oversight, EU AI Act Service Desk
• Create custom subagents, Claude Code documentation
• Linux Foundation announces the formation of the Agentic AI Foundation, 9 December 2025