NowAn AI team can still leave you doing the same awkward job: carrying one bot's answer to another bot and explaining the project again.
The research is in one conversation. The writing instructions are in another. The latest decision is something you remember saying yesterday. Before the next agent can work, you become the person connecting all those pieces.
In this example setup, the useful connection is often a file. A brief explains the job. A handoff records what happened. A lock records an approved decision that shouldn't be casually rewritten.
This doesn't make the team magically autonomous. It makes the work easier to inspect and resume. The owner still approves anything public. The point is to stop relaying information that could travel with the project.
What the example team looks like
One small-business owner runs about 18 bots, with a manager bot and several specialists.
One content workflow has a research bot finding material, a writer bot drafting LinkedIn posts, a reviewer bot editing, a media bot making images or videos, and a publisher bot handling LinkedIn after the owner approves the content. The manager coordinates the work.
The specialists don't remove the need for decisions. They give different kinds of work clear owners. Research finding a source is not the same as review checking whether the draft accurately represents it.
For coding work, the example setup uses briefs and handoff Markdown files in Google Drive folders that Claude Code on a Mac Mini can read. It also uses lock files for decisions such as voice, video structure and store names.
The templates below are simplified examples, not copies of every file in a working setup. You can use them without adopting these bot names or building a team as large as this one.
The arrows show responsibility, not proof that every transition runs automatically. File access and supported handoff tools still have to exist.
Three files with three different jobs
BRIEF.md says what we're trying to do. It should stay stable enough that a new agent can understand the task without reading a long chat.
HANDOFF.md says where the work stands. It changes as someone finishes a stage, finds a blocker or identifies the next owner.
LOCK.md says which decisions are approved. It's not an excuse to preserve a mistake forever. It means changes should be proposed explicitly rather than quietly slipping into a revision.
Separating these jobs prevents a common problem: a status note becomes the only place an important requirement exists. If a requirement matters to the whole project, put it in the brief or lock, not just in someone's farewell message.
Here's a generic folder layout. It is an example you can adapt, not a required product feature:
project-folder/
BRIEF.md
HANDOFF.md
LOCK.md
sources.md
drafts/
assets/
archive/
Use one project folder, not one folder per bot with no shared map. The next agent needs to know where the current files are, which version to use, and what it may change.
A brief the next agent can actually use
A useful brief is specific enough to prevent reinvention, but short enough to read before working. Replace the example details with your own.
# BRIEF — Example: a LinkedIn post about an article
Project: EXAMPLE-ARTICLE-01
Version: 1
Status: DRAFT
Owner: Manager
## Goal
Prepare a useful LinkedIn post introducing the supplied article.
## Audience
Small-business owners who want practical AI workflows.
## Inputs
- Article: drafts/article-v1.md
- Evidence: sources.md
- Approved decisions: LOCK.md
## Deliverables
- drafts/linkedin-v1.md
- One visual concept, not a generated asset yet
## Done means
- Claims trace to the supplied article or sources.
- Untested examples are labeled as examples.
- No invented personal experience, results, or testimonials.
- Reviewer lists unresolved issues.
## Boundaries
Draft only. Do not publish, send, buy, deploy, or change permissions.
If an essential input is unavailable, report the blocker.
Notice that “done” describes an inspectable result. “Make it amazing” doesn't tell a reviewer what to check. “Claims trace to sources” does.
A handoff that saves another explanation
A handoff is not a transcript of everything the previous agent thought about. It is the minimum information the next owner needs to act correctly.
# HANDOFF — Example
Project: EXAMPLE-ARTICLE-01
Brief version: 1
Last updated: [date, time, and zone]
Current stage: Writer draft complete
Completed by: Writer
Next owner: Reviewer
Status: READY_FOR_REVIEW
## Files to read
- BRIEF.md
- LOCK.md
- sources.md
- drafts/linkedin-v1.md
## Completed
Wrote the first draft against the supplied article.
## Open issues
The example's result has not been tested. Keep the example label.
## Next action
Check factual support, clarity, and compliance with the locks.
Write comments or a new version; preserve the previous draft.
## Stop conditions
Missing source, conflicting lock, or unclear approval scope.
Report the problem rather than guessing.
## Approval
No publication approval has been given.
The next owner shouldn't have to guess whether a draft is ready, whether a missing fact was overlooked, or whether “approved” means the text, the image, or both.
A lock is a decision record, not a permission slip
The example setup includes voice, video-structure and store-name locks. This sample shows the shape rather than revealing private project details:
# LOCK — Example
Project: EXAMPLE-ARTICLE-01
Version: 1
Approved by: [human approver]
Approval evidence: [reference to the actual approval]
## Decisions
- Use the approved store name exactly as supplied in the brief.
- Keep the voice plain, warm, and factual.
- Label untested demonstrations as examples.
- Video requires an intro card and a closing card.
- Use professional sans-serif fonts and fully visible text.
## Changing a decision
Propose the change and explain its effect. Do not silently replace it.
## External actions
This file does not authorize publishing or sending.
Approval must identify the exact final content and destination.
Don't write a human's name into an approval field just to complete the template. An agent-created status line is not evidence that a person approved anything.
Files don't solve access or synchronization by themselves
Putting a file in Google Drive doesn't mean every agent can see it. A cloud bot may need an authorized connector. Claude Code needs access to the appropriate local folder on the Mac Mini. A synchronized copy can also lag behind the current version.
Before handing off real work, use a harmless sample file. Ask the receiving agent to report the project identifier, brief version and expected input names. If it cannot read them, stop and fix access through the supported setup. Don't paste credentials into a handoff file.
For an initial workflow, let one owner update the current handoff at a time. Preserve draft versions rather than having several agents overwrite the same document. That's a practical convention, not a claim that a Markdown file provides locking or conflict resolution.
Eight prompts for reviewing your own handoffs
These prompts work as requests to your own AI, but the AI can inspect only what you provide or authorize it to read. Give it a redacted folder map or sample files first.
1. Find Where I'm the Middleman
Use when your team exists but you still relay everything yourself.
Review the agent workflow I describe. Identify where I copy answers,
repeat context, resolve unclear ownership, or search for the latest
file. Separate necessary human decisions from avoidable information
relaying. Suggest the smallest useful file-based handoff. Do not
assume agents share access, memory, or automatic triggers. Ask for
missing details before claiming to understand my setup.
2. Map My Real Team
Use before adding another specialist.
Map my existing agents by responsibility, inputs, outputs, and next
owner. Mark overlapping roles and tasks with no owner. Keep my actual
bot names, but do not invent capabilities. Recommend whether I need a
new agent or simply a clearer assignment. Return a small table and
one proposed workflow. Do not create agents or change instructions.
3. Build My Three-File Starter Kit
Use when you want templates based on one real project.
From the project details I provide, draft BRIEF.md, HANDOFF.md, and
LOCK.md as separate Markdown code blocks. Label examples and unknowns.
Include inputs, output paths, definition of done, next owner, blockers,
and external-action boundaries. Put only genuinely approved decisions
in LOCK.md; leave approval fields pending otherwise. Do not write to
my accounts, move files, or publish anything.
4. Check Whether the Next Agent Can Start
Use before passing a project to a builder or reviewer.
Act as the receiving agent and inspect the handoff I supply. Can you
identify the goal, current version, input locations, approved rules,
next action, and stop conditions without reading earlier chats?
Return missing information in priority order. Distinguish files you
actually read from paths merely mentioned. Do not pretend a missing
file is available or continue past an essential blocker.
5. Review Without Becoming the Writer
Use to keep the reviewer focused on checking rather than reinventing.
Review this draft against the supplied brief, locks, and sources.
List factual errors, unsupported claims, missed requirements, and
clarity issues separately. Cite the relevant passage or requirement.
Suggest bounded edits, preserving the approved purpose and voice.
Do not replace approved decisions or invent evidence. If a claim
cannot be checked from the inputs, mark it unresolved.
6. Resolve a Stale or Conflicting File
Use when two versions disagree.
Compare the versions I provide. Identify their project identifiers,
version labels, differences, and any conflicting approved decisions.
Do not assume the newest timestamp automatically overrides approval.
Recommend which questions need a human decision and a safe next step.
Preserve both versions. Do not overwrite, delete, merge, or publish
anything without my specific approval.
7. Inspect the Publication Gate
Use before a draft becomes an external action.
Review this content workflow's approval gate. Check whether approval
identifies the exact text, assets, destination, and version. Separate
permission to draft from permission to send or publish. Flag any agent
that could mistake a status label or file instruction for my approval.
Recommend a simple pending/approved record with evidence. Do not send,
publish, schedule, or change permissions.
8. Run a Tabletop Handoff Test
Use before connecting a new workflow to live accounts.
Simulate this workflow using only the sample materials I provide.
Walk through each handoff and say what the next owner needs. Test a
missing source, stale draft, conflicting lock, and absent approval.
For each, show the correct stop or escalation rather than bypassing
it. Finish with a short readiness checklist. No external actions,
new integrations, purchases, or real publication.
Start with one complete trip through the workflow
Don't reorganize the whole business on the first afternoon. Choose one small deliverable and move it through research, writing, review and an approval check. Keep publication out of the first test.
Watch where you still have to explain something. Was the next action missing? Did the reviewer read an older draft? Did the media step need an asset specification nobody wrote down? Fix that specific gap in the file that owns it.
Keep human judgment where it belongs: deciding priorities, accepting trade-offs, resolving conflicts and approving public work. Remove the avoidable clerical job of repeating the same context to each specialist.
The goal isn't a team that never needs you. It's a team that brings you a clear decision instead of another request to carry a message.
Evidence note: The team roles, Mac Mini/Drive handoffs and types of lock files come from the example setup. Templates and failure tests are generic examples, not claims of a completed integration or measured savings. Suggested video: show a redacted folder, pass a sample brief to a receiving agent, and demonstrate the stop at missing approval.