Build your own
AI team.

1. Give each AI a job

These are the roles in my workflow. Choose your own coordinator and switch roles when another tool has better access or context. This is how I route work, not an objective ranking of the models.

My Grok fleet separates collection, research and critique into distinct lanes. For your first setup, those can simply be three clearly named chats. You do not need a fleet to try the workflow.

All of these tools can do more than one job. The best owner is the one with the right tools, context and available capacity for this task. Verify browser access in that actual session before promising browser work. Keep one driver in a shared logged-in browser and one owner editing each file.

2. Start in one afternoon

First: choose a small, real deliverable

Try a one-page guide, a simple webpage or a source-backed comparison. Write down what useful completion looks like. Keep your first run to draft and review. Use public or sample information so you can learn the handoff without moving private records between apps.

Next: open the tools you already have

Open Claude, ChatGPT or Codex, and Grok in the environments available to your account. You can start with ordinary chats and manual file transfers. Installing every app, connector and automation is optional.

If you want Claude Code locally, follow Anthropic's quickstart. Its Windows PowerShell installer is irm https://claude.ai/install.ps1 | iex; on macOS, Linux or WSL it is curl -fsSL https://claude.ai/install.sh | bash. Read the official page before running an installer. Open a new terminal, run claude --version, then start claude in your project folder and follow the account login prompts. Use /help inside the session. Account access and authentication still apply.

For the OpenAI environment you choose, follow the official quickstart. For Grok, start with its official overview. My custom bridge is additional infrastructure. A normal Grok chat does not automatically inherit my fleet, local files or authenticated browser sessions.

Then: make one shared folder

Create this small structure locally or in a Drive folder you control:

AI-Team/
  HANDOFF.md
  day/
    YYYY-MM-DD.md
  tasks/
    guide-01.md
  results/
    guide-01-v1.md
    guide-01-review-v1.md
  skills/
    multi-ai-team/
      SKILL.md

Keep the working record in one place. Drive can be the shared file location or a mirror. Choose one writer for each record. Other agents return new task/result files instead of simultaneously changing the same board. Share only the material this assignment needs; keep secrets outside shared folders.

Run one handoff by hand

Give the coordinator the brief. Move its task packet and required inputs to the producer. Put the returned artifact in results/, then give that exact version to a fresh critic. Have the coordinator read the result back and say what passed, what changed and what remains open.

Your first win is a useful reviewed file, with a clear owner and a receipt. Add automation after you can complete that cycle by hand.

3. Write the brief once

You should be able to paste the packet into another app without explaining the entire conversation. This example is deliberately a draft-only task. Replace the sample task, sources and filenames with your own.

TASK: guide-01 / revision 1
GOAL: Make a one-page guide to using AI to organize meeting notes.
AUDIENCE: Busy small-business owners trying this for the first time.
COORDINATOR: My main work chat.
PRODUCER: My selected build chat.
INPUTS: My sample notes and the linked official product documentation.
CONSTRAINTS: Plain language. Use sample data. No invented product claims.
DELIVERABLE: results/guide-01-v1.md
DONE WHEN: A reader can try the workflow, copy an example prompt,
and tell which claims came from current official sources.
REVIEW: Fresh critic checks usefulness, facts and clarity.
MAX CORRECTION ROUNDS: 2
PERMITTED ACTIONS: Draft and save the guide only.
RETURN: File, source links with access dates, checks, blockers and next action.
First acknowledge the task and list any inputs you cannot open.

Acknowledged means the receiving agent actually replied. A file appearing in a folder means queued. Keep those states separate.

4. Share the current state, not the whole chat

My setup uses a short HANDOFF.md, yesterday's day file and today's day file. That gives the next agent enough to continue without replaying every old conversation. Put deeper work in separate files and link to it only when needed.

Copy this starting handoff:

# HANDOFF
Updated: YYYY-MM-DD HH:MM timezone
Current outcome: Finish guide-01.
Coordinator: Main work chat.
Owner: Build chat; accepted at HH:MM.
Current artifact: results/guide-01-v1.md
Reviewer: Fresh critic; review queued.
Authorized scope: Draft and local file preparation only.
Open decision: None.
Next action: Read the critic result, repair supported findings, recheck.
Sources: tasks/guide-01.md

And this day board:

# YYYY-MM-DD
## User said
HH:MM | USER | Make a one-page guide from my sample notes.
## Assigned
HH:MM | COORDINATOR | guide-01 -> build chat | tasks/guide-01.md
## Done + receipts
HH:MM | BUILDER | v1 saved | results/guide-01-v1.md | review pending
## Blocked + decisions
HH:MM | CRITIC | Missing source for a product claim | remove or verify

Check the timestamp before treating a handoff as current. Read the named artifact rather than guessing from a status line. A mirror is only current after you verify the copied file's timestamp and content. A connected Drive folder does not prove that every chat can open it; ask each receiver to read one harmless file and quote its task label.

5. Turn the repeatable parts into skills

A skill saves the instructions for a workflow you use again. Keep the shared purpose and decisions in SKILL.md; add references or scripts only when they help. For this package, the skill teaches routing, bounded handoffs, source checks and independent review. It does not install a bridge or grant tools access.

Download multi-ai-team.zip, which contains multi-ai-team/SKILL.md. Review it before installing.

In Claude on the web: If needed, enable Code execution and file creation in Settings > Capabilities. Open Customize > Skills, click the + button, choose + Create skill, then Upload a skill. Upload multi-ai-team.zip and turn the skill on. Ask Claude to use multi-ai-team on your brief. Organization policy and your interface may affect access; follow Anthropic's upload guide if the option is missing.

In Claude Code: In your project, place that folder at .claude/skills/multi-ai-team/, then invoke /multi-ai-team with your task. This follows Anthropic's skills documentation.

For a Codex project, place it at .agents/skills/multi-ai-team/ and ask Codex to use multi-ai-team. The folder contains the required YAML name and description. See OpenAI's skill guide for supported locations and interfaces. If discovery fails, verify the filename, folder and current environment against that guide.

For an ordinary chat that cannot load local skills, attach or paste the SKILL.md and ask it to follow the workflow. This is a manual instruction handoff, not a native installation. Do the same in Grok when a skill loader is not available. Always test discovery with a harmless task before trusting it.

Use the multi-ai-team workflow for guide-01.
Read the brief and confirm which files and tools you can access.
Pick one producer and a fresh reviewer.
If you cannot reach another app, prepare a packet I can paste there.
Do not claim a worker has started without its acknowledgment.
Return the reviewed guide and an evidence-based completion receipt.

6. Choose the cheapest capable route

Start with the smallest capable option already available to you. Cost includes your attention, corrections and waiting, as well as usage. My rule is to use code for predictable housekeeping and spend stronger reasoning on ambiguity and review.

This is a routing method, not a price chart. Check your account's current models, allowance and billing before deciding. More agents do not automatically save money; workers may share the same allowance. A bigger model is worth using when it resolves a problem the smaller route cannot handle reliably. Keep task packets short and avoid repeated full-context polling.

7. Use a gauntlet for substantial work

For a simple task, build and get one fresh review. For a complicated plan, I start with independent plans. Each planner receives the same brief and sources, researches the problem, writes a plan and critiques its own assumptions before seeing the others.

The coordinator then merges the strongest supported pieces. Keep a short decision table: where the plans agree, where they conflict, what was selected and why. Disagreement is useful when it exposes a missing source or an untested assumption. Do not average contradictory claims into a confident answer.

Write an independent plan for this brief using the supplied sources.
Do not read another planner's answer first.
Return your plan, assumptions, source gaps, risks and self-critique.
Explain what would make you choose a different approach.
Keep this to planning. Do not publish, send, deploy or spend.

After the merge, give a fresh critic the brief and actual artifact. Keep the producer's defense and other critics' verdicts out of the first review.

Review this artifact independently against the brief and sources.
Check usefulness, accuracy, clarity and practical feasibility.
Open primary sources for material factual claims.
Return PASS or REDO, specific defects, evidence and concrete fixes.
For a visual, inspect the final export at phone and desktop sizes.
For a tool, try the relevant user flow and report what you tested.
Name the exact artifact revision you reviewed.
If asked for a 1-10 score, explain it. A score alone is not a pass.

Repair findings supported by evidence, export the new version and send it back for independent review. Set the correction cap before starting, such as two rounds. If the target remains unmet, report the actual result and remaining issue. Never invent a second-model review because the other app was unavailable.

8. Fact-check and inspect the real output

Ask the researcher for a small claim table: claim, primary source, supporting passage or location, access date, and verified / inference / unresolved. Search snippets are leads. Open the source. For product setup, prefer official documentation. For a claim that cannot be verified, remove it or label the uncertainty.

Find the primary source for each material claim in this draft.
Return claim / source URL / what it supports / accessed date / status.
Separate facts from your inference.
Do not treat an AI answer, search snippet or repeated blog claim as proof.
Flag outdated or contradictory sources for the coordinator to resolve.

For creative work, my gate reviews the final rendered export against the chosen reference and current corrections. Look at phone reading size, alignment, spacing, cropping, labels, links and unsupported claims. A screenshot of an old draft cannot approve a changed page. Attach the verdict to the exact revision or file hash.

For software, test the meaningful path: open the page, use the main control, follow the link or download, and confirm the result. Tell the user what was actually tested and what remains unverified.

9. Add schedules after the manual run works

In my setup, schedules handle recurring intake, context mirroring and result collection. You can begin with a calendar reminder and run the same checklist manually. Choose a scheduler only after confirming that the needed runtime and inputs are available when it fires.

Use this specification before installing any recurring job:

JOB: morning-review
TRIGGER: Weekdays at 08:30 in my chosen timezone.
OWNER: Coordinator.
INPUT: HANDOFF.md, yesterday and today's day files, new result files.
ACTION: Summarize changed items and identify the next useful action.
OUTPUT: results/YYYY-MM-DD-morning-review.md
RUNTIME: The actual local or cloud environment that will execute it.
DUPLICATE GUARD: One run per date; skip already processed result revisions.
FAILURE SIGNAL: Write the error and notify the designated human channel.
TEST: Run once manually and verify the output before enabling recurrence.
SCOPE: Read and draft only. No sending, publishing or financial actions.

A local job depends on the local machine and session conditions. A cloud job needs its own accessible inputs and authentication. Verify both with a harmless run instead of assuming a local folder is visible remotely. Watch for stale outputs, missed runs and duplicate execution. Use a lightweight script for routine file checks when a model adds no value.

10. Bridge the apps when repetition earns it

My bridge uses task files in an inbox, returned files in an outbox and a wake signal. The file carries the assignment; the wake signal tells a worker to look. A watcher brings the result back to the coordinator. This is custom infrastructure you can build around supported tools, not a standard feature automatically connecting these three apps.

Start with a manual file transfer. If you later add a webhook, have the builder implement authentication, limited scope, a task reference, duplicate protection and error handling. Store secrets in the chosen runtime's protected credential mechanism. Never paste them into task files or shared Drive.

Design an optional bridge for our existing manual handoff.
Use supported tools available in our accounts.
Task -> inbox -> wake -> acknowledgment -> result -> verification.
Keep one executor per task and one writer per record.
Keep credentials out of shared files, logs and command arguments.
Define duplicate handling, timeouts, failure reporting and a manual fallback.
Prove it with a harmless draft-only task before claiming it works.
Return the design first; do not install or enable it yet.

Track the stages separately. HTTP success means the endpoint accepted the request. Acknowledgment means the worker accepted the task. A returned artifact means work came back. Verified completion means the coordinator checked that artifact against the brief. If a worker is silent, flag it and decide on a reassignment; do not quietly launch a duplicate.

11. Run your first example

Try a public guide called "Turn meeting notes into next actions." Give the producer fictional notes containing decisions, owners and dates. Ask it to create a one-page checklist and a reusable prompt. Give a separate researcher any current product claims. Have a fresh critic check that each action has an owner, the draft preserves uncertainty and the prompt is easy to reuse.

Return the reviewed guide to the coordinator, save it with a revision and add a receipt to the day board. On the next meeting, reuse the same prompt with new notes. If the workflow repeats, keep it as a skill. If collection becomes predictable, consider a schedule. If app-to-app handoffs become frequent, consider a bridge.

You have a working team when the assignment moves, the owner responds, the result comes back and someone checks it.

Troubleshooting

Downloads and next step

• PLAYBOOK.md: This full guide in editable Markdown.
• SKILL.md: The workflow instructions, ready to read or attach.
• multi-ai-team.zip: A folder containing the skill for installation.
• Learn AI Faster: Build the habits behind better prompts and feedback.
• AI tools and playbooks: Find another practical workflow to try.

To upload the ZIP in Claude, open Customize > Skills > + > + Create skill > Upload a skill, then enable it. See the setup instructions in section 5.

This package helps you coordinate the work. It does not connect accounts or authorize sending messages, publishing, spending or moving money. Keep those actions inside your actual permission boundaries.

Official setup references

Checked October 5, 2026. Product interfaces and account access can change; use the current official guides when installing.

• Anthropic: upload and use skills in Claude
• Anthropic: Claude Code quickstart
• Anthropic: Claude Code skills
• Anthropic: project memory and CLAUDE.md
• OpenAI: quickstart
• OpenAI: build skills
• Grok: official overview
• xAI: API web-search tool, for an API implementation rather than a promise about every chat's tools.