Lead>code
AI pods · Leadcode 0.7

A crew of agents.
You hold the gates.

An AI pod is a group of agents with one job. Three of them take an idea to a pull request — asking the hard questions, writing the spec, building the issues — while every agent acts as the mission's accounts and every merge waits for you.

01The definitionidea → brief → spec → issues → PR

What is an AI pod?

An AI pod is a group of AI agents inside a Leadcode mission with one job. Leadcode ships three pod templates — Discovery, Planning and DevOps — that hand work to each other: an idea becomes a brief, the brief becomes a spec and sized issues, and the issues become pull requests that wait for your approval.

Think of a pod as a room. The agents inside it talk to each other, use their own skills and tools, and pass one finished artifact to the next room. You are not in the room. You write the idea at the start and hold the gate at the end.

youone paragraph

The idea

"Guests should check out without an account." You never write a ticket.

idea.md · 4 lines
pod 013 agents

Discovery

Grills the idea in rounds until it survives — or dies with the transcript.

grill-meclaude-designanalytics mcp
brief #7 · survived 3 rounds
pod 022 agents + mcp

Planning

Turns the brief into a spec, then cuts it into sized, dependency-ordered issues.

to-specspec-to-issueslinear mcp
spec v1 · 14 issues in Linear
pod 03agents + subagents

DevOps

One agent per issue, each with scout, coder and tester subagents on its own branch.

gh mcpvercel mcp
14 issues closed · PR #212 open
youhuman-only gate

The gate

Merges, deploys and spend need a person. The PR waits for you — nothing else does.

PR #212 · 11/11 checks · awaiting you
02The walkthrough

How does an idea become a merged pull request?

You write the idea in a paragraph. Discovery questions it in rounds until it survives or is archived with the transcript. Planning turns the surviving brief into a spec and cuts it into sized, dependency-ordered issues in Linear. DevOps gives each issue its own agent, which spawns scout, coder and tester subagents on a branch, and a review agent checks every pull request before it reaches you.

Nothing ships on vibes. A brief that cannot answer its weakest claim is archived, not planned. A spec is checked against the mission's pinned vision before it is cut into issues. And a pull request only reaches your queue after the review agent has seen its checks pass and its preview deploy come up.

Guest Checkout v1 · recent handoffsruns as northwind
09:02 you → Discovery · idea.md
      grill round 1 · 2 · 3 — "prove users abandon at the account wall"
10:51 Discovery → Planning · brief #7 — 38% cart loss at signup
11:13 Planning · to-spec → spec v1 · problem, scope, flows, non-goals, rollout
11:40 Planning → Linear · 14 issues, sized, dependencies as blockers
12:05 DevOps · LEAD-108 → scout · coder · tester on feat/guest-checkout
      $ pytest tests/orders — 47 passed
14:32 Review · PR #212 · 11/11 checks · preview ready
14:33 ✋ calling you — merge approval is human-only
03The vocabularymission ⊃ pods ⊃ agents ⊃ subagents

What is the difference between a mission, a pod, an agent and a subagent?

A mission is one product or client and owns the account bindings. A pod is a room in that mission with one job. An agent is a role with its own model, skills and MCP servers, and can sit in more than one pod. A subagent is spawned by an agent to parallelize a task and ends when the task closes.

missionowns identity

Guest Checkout v1

One product for one client. Holds the bindings — claude@northwind, nw-bot, northwind.co — and the repos and goal every pod inherits.

podone job

Planning

A room with one job. Agents inside collaborate and hand one artifact — here, a spec and its issues — to the next pod.

agenta role

Design agent

A role with a model, skills and MCP servers. The same Design agent sketches flows in Discovery and attaches them to issues in Planning.

subagentone task

coder

Spawned by an engineer agent for one issue, next to a scout and a tester. It lives inside the pod and ends when the issue closes.

04Identity

Whose accounts do pod agents use?

The mission's, never yours. Every pod agent is a real claude or codex session on your Mac, launched through the same credential router as any Leadcode session: ambient credentials are scrubbed, the mission's bindings are injected, and model usage is billed to the account the mission is bound to. No agent holds its own keys, and Leadcode never proxies a token.

So when a DevOps subagent runs gh pr create, it is already nw-bot; when it deploys a preview, it is already the Northwind Vercel account. If a pod needs an account the mission has no binding for, it refuses to start rather than borrow whatever happens to be signed in on this Mac.

The router is the same one described on the security architecture page — pods add agents, not a second way in.

pod 03 · DevOps · coder subagent · LEAD-108
mission: Guest Checkout v1 → persona northwind
scrub ANTHROPIC_API_KEY GH_TOKEN CLAUDE_CODE_OAUTH_TOKEN AWS_*
inject CLAUDE_CONFIG_DIR → accounts/acc_northwind/claude-code
inject GH_CONFIG_DIR → accounts/acc_northwind/gh
keychain → session env (never disk, never repo)
✓ claude on PTY · signed in as Northwind
❯ git commit -m "orders: allow guest_token"
author nw-bot <bot@northwind.co>
❯ gh pr create --base dev
PR #212 opened as nw-bot
05Human gates

What always waits for a human?

Merges, deploys and spend. Those three gates are on by default and cannot be switched off. You can add more — for example approving a spec or the task order before DevOps starts — and pods only call you when they reach a gate.

Everything between the gates is delegated. There is no tab to check and nothing to poll: a pod that is working stays quiet, and a pod that needs you shows up at the top of mission control with the decision already framed — what changed, which checks passed, what happens if you approve.

gates · Guest Checkout v1
always human — cannot be removed
✋Merge a pull requestlocked
✋Deploy to productionlocked
✋Spend moneylocked
optional — add per mission
＋Approve the spec before issues are cut
＋Approve task order before DevOps starts
06The obvious questionclaude --agents …

Why not just run Claude Code subagents yourself?

You can, and pods run the same CLIs. What you would still have to build is everything around them: every agent and subagent acting as the right client's accounts, gates that hold even when an agent is confident, and a view across agents so two of them editing the same file is caught before it becomes a merge conflict.

01Identity doesn't inherit itself

A subagent you spawn by hand inherits whatever shell it was born in — your personal login, a stale GH_TOKEN, the last AWS_PROFILE you exported. In a pod, every agent and every subagent starts from the router's environment, so the ninth subagent of the afternoon is exactly as scoped as the first.

02Confident agents skip steps

An agent that believes its change is safe will merge it if it can. Pod gates are not prompts asking an agent to wait — merge, deploy and spend are simply not actions a pod can take without you.

03Parallel agents collide

Nine subagents across Claude Code and Codex will eventually touch the same file. The repository radar watches every pod in the mission, places a write hold when two agents meet in one file, and calls you to decide — before it turns into a merge conflict nobody can attribute.

07Templates

How much of a pod can you customize?

Pods ship as templates. For each agent you choose the model, the skills and the MCP servers it can use, and an agent can work in more than one pod. Creating new pod types is not available yet.

SettingCan you change it?Example
Agent modelYes, per agentA stronger model for the Discovery lead, a faster one for testers
SkillsYes, per agentgrill-me, to-spec, spec-to-issues
MCP serversYes, per agentLinear for Planning, gh and Vercel for DevOps
Agent in several podsYesThe Design agent works in Discovery and Planning
Extra gatesYes, add onlySpec approval, task order
Merge / deploy / spend gatesNoAlways human
New pod typesNot yetDiscovery, Planning and DevOps are the templates today
08Pricingpriced per human, not per token

Which Leadcode plan includes AI pods?

Every plan, including the free Solo plan. Plans differ in how many accounts per provider can be live at once, not in whether you get pods or mission control.

Model usage is billed by your provider to the account each mission is bound to — Leadcode never sees a token. See Solo, Pro and Team.

09Honest limits

What are the limits of AI pods?

Pods do not bring their own identity, so a pod can only do what the mission's bindings allow. New pod types cannot be created yet. Agents run with process isolation, not containers, and Leadcode runs on macOS only.

Pods also live inside your providers' own limits. When a bound account reaches its usage window, that mission's agents pause and resume on reset — mission control shows the window and the reset time, and no pod borrows another account to keep going.

Security architectureThe router every pod agent launches through, and why it fails closed. Why "Leadcode"You are the tech lead now. The name, the >, and the Moon-C mark. Mission controlWhere pods call you, and where you see every mission at once.

Write the idea.
Hold the gates.

Download for macOS

macOS 13+ · pods on every plan · sign-in starts your 14-day Pro trial