Is Your Team Ready for AI Agents? A Readiness Checklist

A team is ready for AI agents when it can answer seven questions in writing before the first assistant connects: where the work lives, who owns each part of it, what the assistant may reach and what data it must never see, which jobs are safe to hand over, who reviews finished work, what gets recorded, and how you undo a mistake. None of that needs new software. It needs an hour with the people who will work alongside the assistant, and a one-page note at the end. If you cannot fill in the page, you are not ready yet, and the page tells you what to fix.

Readiness comes before; an audit comes after

This is the check you run once, before rollout. It is not the same as a periodic audit, which asks whether what each assistant can do, and what it did, still matches what you meant — that is covered in how to audit AI agents in a small team. The readiness check is where you write down what you mean, so there is something for the audit to compare against later. Skip it and the first audit has nothing to measure.

The checklist

1. Where work lives: one place the assistant reads and writes.
2. Who owns what: a named person for each area, and for what gets worked on next.
3. Access and data: what the assistant may reach, and what it must never see.
4. Safe jobs: a short list of work it may do, and a list it may not.
5. Review: who checks finished work, and when.
6. Records: how you will know afterwards what it did.
7. Rollback: how you stop it and undo a mistake, rehearsed once.

1. Where work lives

An assistant can only work from what it can read. If your team’s work is split across a chat channel, two spreadsheets and somebody’s notebook, the assistant will see a fragment and act on it confidently. Pick one place where work is written down — a board, a tracker, a single list — and make it true before anything connects. The test: could a new colleague find out, from that one place alone, what is being worked on and what is next? If not, fix that first. It helps people as much as it helps assistants.

2. Who owns what

Write down a person for each area of work and one person who decides what moves into Next Up. An assistant is good at doing the next thing; it is poor at deciding what the next thing should be, and it will cheerfully pick something if nobody else does. Ownership also answers the question every refusal and every surprise raises: who do I ask? If the answer is “the team”, nobody will be asked.

3. Access and data rules

List every system the assistant would reach — the board, the code, email, a cloud account — and for each, the least it needs: read only, read and comment, or write. Then list the data it must never see: customer records, payment details, credentials, anything under a contract or a regulation. Keep that data out of tasks entirely. A note that says “see the customer file” is safer than one that pastes it.

The OWASP Top 10 for LLM applications names this risk Excessive Agency↗ (opens in a new tab) and traces it to three causes: too much functionality, too many permissions, and too much autonomy. Your access list addresses the first two. How to set roles so an assistant gets less than a person is covered in roles and permissions for humans and AI agents; the readiness question is only whether you have decided, per system, before connecting.

4. Which tasks are safe

Sort the work you have in mind into three groups and write them down.

• Safe to finish alone: reading and reporting (summaries, inventories, duplicate hunts), and small changes whose check is mechanical (a failing test, a broken link).
• Safe to prepare, not to finish: anything a customer will read, anything that spends money, anything that changes live data. The assistant drafts; a person sends, pays or runs.
• Not yet: decisions about scope or priority, deleting data, anything touching personal or customer records.

Twenty worked examples, each with its group, are in AI agent task examples.

5. Review rules

Decide who moves finished work to done, and write the rule where the assistant will read it. The MCP specification↗ (opens in a new tab) itself says there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations. That covers individual calls. Your review rule covers outcomes: the assistant finishes, comments what it changed and how it checked, and leaves the card for a named person. Human in the loop for AI agents sets out the three points where people should step in.

6. Record keeping

You need to be able to answer, a month later, “what did the assistant change, and when?” That means a record kept by the tool, not by the assistant, with each change signed by who made it — and a way to tell an assistant’s changes from a person’s. Decide too how code changes link back to work: quoting a task’s ref in every commit message is the cheapest link there is. What a good record contains is in an audit trail for AI agents.

7. A rollback plan

Write down, for each system, how you stop the assistant and how you undo its work. Then rehearse it once, before you need it. Stopping should be one action that does not also lock out the person the assistant acts for. Undoing should be known in advance: moving a card back, restoring a deleted item, reverting a commit, restoring a backup. If one of those has no answer, move the related jobs to “not yet” until it does.

AI assistant readiness, <team>, <date>
Work lives in:      <one place>
Owners:             <area> - <person>; Next Up decided by <person>
Access:             board read+comment; code write on branches only
Never sees:         customer records, payment data, credentials
Safe / prepare / not yet:  <three short lists>
Review:             <person> moves work to done after reading the comment
Records:            tool history + task ref in every commit
Rollback:           revoke in <place>; restore from <place>; tested <date>

Keep this note where the team keeps its work. It becomes the baseline your first audit reads.

Signs you are not ready yet

• Nobody can say in one sentence where the current list of work is.
• The only way to limit what the assistant can do is not to connect it.
• Finished work is whatever someone says is finished.
• Taking access away would mean changing a shared password.
• Nobody knows how to restore something deleted by mistake.

Each of these is a fix you can make in a day, and each makes the team better with or without assistants.

How fenbs answers the checklist

On a fenbs team board the answers are mostly settings rather than habits. Work lives in four fixed lanes — To Do, Next Up, In Progress and Completed. Roles are defined per company: you make them from plain-language permissions, and moving tasks between lanes is its own permission, separate from adding and editing, so an assistant can be allowed to write and comment without being able to move anything. An assistant connects with a browser sign-in and holds the role of the person who connected it, narrowed by the scopes ticked at approval: read, write and comment. Every change is recorded with who made it, an assistant’s as “Claude via” its person. Revoking a connection in Settings stops it at once without signing that person out, and a deleted task can be restored. AI context notes are where the review rule and the “never” list go, so every assistant reads them before it starts.