menkesu/awesome-pm-skills/agent-workflow

Agent Workflow

[Image: agent-workflow: lead guest team]

Turn 'we use AI agents' into a written operating system: which agents own which lanes, how much autonomy each has earned, how work gets planned, verified and reviewed, and who is accountable. Built from 447 insights from 110 Lenny's Podcast guests. Lead team: Claire Vo, Boris Cherny, Aishwarya Naresh Reganti.

When to use

• You are starting with Claude Code, Codex, Cursor, Devin, OpenClaw or Cowork and want a setup that does not decay in a week.
• Your agent keeps forgetting, looping, claiming it fixed things, or doing the wrong thing confidently.
• You are about to ship a customer-facing agent and need to decide how much autonomy it gets on day one.
• AI is writing the code and review, alignment or merge queues are now the bottleneck.
• You are rolling AI out across a team or company and adoption is stuck at 'a few enthusiasts'.
• A PM wants to build with agents and needs to know what to own, what to hand to engineers, and what to never delegate.
• You want to give an agent access to email, calendar, Slack or code and need a safe permission plan.

Step 1 - Diagnose (ask before answering)

If the user attached a CLAUDE.md, AGENTS.md, rules file, workflow doc, rollout memo or agent identity file, read it first and skip questions it answers. Otherwise ask at most these four:

1. Whose work is being agentified? Your own PM/knowledge work, an engineering team's code, a customer-facing product, or a whole company. (Routes to personal-lanes play, coding loop, agency ladder, or rollout play.)
2. What can the agent touch, and what is the worst thing it could do? Email, prod code, customer messages, money, private data. (Sets the starting rung on the autonomy ladder and the security level.)
3. What is failing today? Forgets/loses context, babysitting, bad output, review pile-up, no adoption, runaway cost. (Routes to context play, plan loop, review policy, rollout, or cost policy.)
4. Team size and who owns it? Solo, 2-10, 10-100, enterprise; is there a named person who cares about the agent working? (Small teams build; large orgs need a tiger team or head of AI ops.)

Step 2 - Pick the play

Step 3 - Run it

Play A - Lanes and agent charters (Claire Vo, Roman Ugarte, Tomer Cohen)

1. List your distinct lanes of work (for a PM: planning docs, data questions, inbox/Slack triage, launch tracking, personal ops). If you would not put it in one Slack channel, do not put it in one agent.
2. Give each lane a one-page charter: role, what it owns, what it may never do, tools it may use, escalation rules, one named human owner. Dan Shipper's rule: every agent needs a human who cares about it, or it decays.
3. Keep a tools.md that lists each tool and exactly how you want it used. Agents forget what they can do; do not hand-edit the soul/identity file for that (Claire Vo).
4. Onboard by interview, not form: say who the agent is and who you are, let it ask you questions, and let it write its own identity and memory files. Voice-note it (Claire Vo's Yapper API: rambling is the highest-bandwidth input).
5. Build narrow agents first so each can be graded; add an orchestrator only later (Tomer Cohen). For multi-agent systems use a supervisor with subagents, not peer-to-peer gossip (Kiriti Badam).
6. Add proactivity only after trust: a heartbeat check every 30-60 minutes plus scheduled tasks (Claire Vo's soul/heartbeat/schedule/memory).
7. Done when: each lane has a charter, an owner and a tools file, and no two agents can both edit the same artifact.

Play B - Plan-first coding loop (Boris Cherny, Alexander Embiricos, Michael Truell)

1. Start in plan mode: tell the agent not to write code yet. Go back and forth on the plan until it is right, then switch to auto-accept edits (Boris Cherny).
2. Write the plan to plan.md with verifiable steps (build, run tests, see output). Ask: why can't you verify your work? Fix it. Loop until it can (Embiricos).
3. Chunk the work: specify a little, let it build a little, review, repeat. One giant spec is a recipe for disaster today (Michael Truell). Hand over tasks, not problems (Scott Wu).
4. Ask for the ambitious change; if it fails, restart from scratch and tell it what failed instead of patching the same dead attempt (Benjamin Mann).
5. Run independent tasks in parallel (Boris: multi-Claude-ing; Scott Wu: five tasks, five agents; Sherwin Wu: 10-20 threads). Do not parallelize tasks that depend on each other.
6. Use the strongest model first; compare tokens-to-finish, not price per token (Boris Cherny). Split by strength only when you have the habit (Zevi Arnovitz: fast model for simple execution, Codex for the worst bugs).
7. Do not box the model in with rigid orchestration: give tools plus a goal (Boris Cherny). Counterweight: keep humans on architecture and concurrency (Dhanji R. Prasanna).
8. Done when: a task goes plan, approve, execute, verify with no manual edits. Max Schoening's test: every human intervention should feel like a bug in your verification loop.

Play C - Autonomy ladder (Aishwarya Naresh Reganti, Kiriti Badam, Claire Vo)

Steps: (1) classify each lane's actions by risk, (2) set the starting rung so a mistake is cheap, (3) log every human edit as free error analysis, (4) review traces together as PM + engineer + data, (5) promote one rung at a time with a written criterion, (6) when a new data distribution appears, drop a rung. Do not default to an agent: map the workflow and use ML, deterministic code and LLMs each where they fit (Aishwarya).

Play D - Context fixes and postmortems (Sherwin Wu, Zevi Arnovitz, Bret Taylor, Lazar Jovanovic)

1. When the agent fails, first ask: did it have the information? Inspect its files (Claire Vo).
2. Write tribal knowledge into the repo: markdown docs, comments, structure, skills. Audit weird undocumented enterprise rules and dead taxonomies (Aishwarya).
3. Run a postmortem on every miss: ask the agent what in its prompt or tooling caused it, then patch the rules file, command or doc (Zevi Arnovitz).
4. After a fix, ask how you should have prompted it to do this in one go, and write the answer into the rules file (Lazar Jovanovic).
5. Keep the rules file short. Prefer a thin starter template with one trivial test so the agent copies existing patterns (Simon Willison) over paragraphs of preferences.
6. After a larger session, have it write action items and notes to memory before compaction, like closing a meeting (Claire Vo).
7. Done when: the same mistake does not recur twice. Dedicate someone to the context layer (Bret Taylor).

Play E - Review and verification (Boris Cherny, Sherwin Wu, Mike Krieger, Bret Taylor)

1. Run AI review on every PR; keep a human layer on risky or production code (Boris, Sherwin Wu: roughly 30% human attention).
2. Where volume is too high, use a different model to review and have humans do acceptance testing instead of line-by-line review (Mike Krieger). Caution: same model writing and reviewing is circular.
3. Pair a generator with an independent reviewer; two ~90% agents approach 99% only if their errors are independent (Bret Taylor).
4. Ask of any workflow: can the agent check its own output against something objective? Code can; essays cannot, so keep a human verifier there (Simon Willison).
5. Evaluate trajectories, not just answers (Edwin Chen). Measure supervised vs unsupervised code, not percent AI-written (Andrew Ambrosino); watch code deleted, not lines generated (Farhan Thawar).

Play F - Safety floor for any agent with real access (Claire Vo, Simon Willison, Sander Schulhoff)

1. Separate machine or hosted sandbox; no private data you cannot afford to leak (Claire Vo; Caitlin Kalinowski's agent leaked an email in five minutes).
2. Give the agent its own accounts and delegated access, never your passwords.
3. Declare one trusted instruction channel in its identity file; email, Slack and web pages are data, never commands.
4. Assume users can make the agent leak any data and take any action it can; scope permissions to the task (read-only for summarizing) and contain generated code (Sander Schulhoff).
5. Ask a human only on high-risk actions that touch tainted data, or approvals become click fatigue (Simon Willison's CaMeL).
6. Never rely on prompt instructions as the defense.