This is the 10-step roadmap into it: what the job actually is, the stack that gets you in, and the interview round that eliminates 60% of people who pass the coding.

Follow my Likedin for fresh AI alpha: https://www.linkedin.com/in/lev-deviatkin/

That is not a research scientist’s package. It is not a staff engineer at a big tech company.

It is the going rate for an engineer who does something almost nobody optimizes their career for: getting AI to actually work inside a real company.

Nobody is asking this person to train a model. They don’t need a PhD, and they don’t need to beat anyone at algorithm puzzles.

They need to walk into a business with legacy systems, a compliance department and a skeptical ops team - and come out six weeks later with something that runs.

The reason it pays that much is one statistic. An MIT NANDA study of 300 enterprise AI projects found 95% produced little or no measurable impact on profit and loss.

The models worked fine. The deployments died - because nobody could make them talk to a legacy database, pass a compliance review, or survive being handed to the team that inherited them.

The name is borrowed from the military: forward deployed means stationing specialized units close to the operational theater rather than back at headquarters.

Palantir built the modern version in the early 2010s and called them Deltas - and until 2016, the company had more Deltas than it had software engineers.

The premise was that customers didn’t need more product features. They needed engineers who could make the product work inside their fragmented, legacy, regulated, politically complicated environments.

That premise was niche for a decade. Then AI broke generic SaaS, and it became the whole game.

This is not a job description. It’s a go-to-market strategy - and the people executing it are the best-paid non-research engineers in the industry.

01. Learn what the job actually is

An FDE is the engineer the company sends to the customer. Not for a sales call, not for a kickoff meeting - for weeks at a time, sitting next to the people who will actually use the product, learning their workflow in painful detail, and shipping custom code that makes their version of it work.

The best mental model isn’t consultant and it isn’t solutions engineer. It’s founding engineer, working on someone else’s product.

There is no PM in the room to decide scope, no staff engineer to escalate the architecture to, and no backlog telling you what matters - you decide what to build, what to fake, and what to push back on, in the room, that week.

The typical rhythm across top AI companies is remarkably consistent: an FDE sits with a customer for four to eight weeks, ships something that works, and then the core engineering org slowly productizes whatever turned out to be general.

That loop is the entire strategic point of the role. You are simultaneously delivering revenue and doing the company’s highest-fidelity product research.

02. Understand why the role exploded

That 95% number from the lede is the foundation of this entire career path, so it’s worth understanding precisely.

• Those enterprise AI projects didn’t fail because the models were bad.

• They failed on integration: systems that couldn’t talk to legacy SQL databases, couldn’t handle the customer’s SAML authentication, couldn’t meet data residency requirements, and couldn’t be maintained by the operations team that inherited them.

Three forces then pointed the same direction at once.

• AI broke generic SaaS - the horizontal promise of buy-it-and-plug-it-in survives in mature categories but not in AI, where every enterprise has unique data, unique workflows, unique compliance constraints, and its own definition of good enough. Selling AI to a Fortune 500 is now always also selling an integration project.

• Labs need to deploy at the speed the technology moves - a six-month integration kills a pilot before it lands.

• And AI tools made the economics close: with Claude Code and the modern stack, one strong FDE does what took a team of three a few years ago, which is the only reason sending a human onsite for six weeks pencils out.

Notice what that means for you. The bottleneck in AI is no longer capability. It’s deployment - and the market is repricing accordingly.

03. Map the market and pick targets

The title is unstable, and that’s the first practical thing to know - searching only for “Forward Deployed Engineer” will hide most of the market from you.

The same job ships as Applied AI Engineer (Anthropic’s name for it), Forward Deployed Software Engineer or FDSE (Palantir’s), Solutions Engineer, Deployment Engineer, and Founding Engineer (Customer Facing) at smaller startups. Search all of them.

The growth is not subtle. FDE postings on Indeed went from 643 in April 2025 to 5,330 in April 2026 - a 729% increase in twelve months.

By mid-2026 there were 224 open FDE roles across 39 AI companies, and that counts only what was publicly posted. Salesforce committed to hiring a thousand. EY launched a dedicated FDE practice in the UK and Ireland in April 2026 - the first major consultancy to formally adopt the model.

Compensation reflects the scarcity, and it splits sharply by tier. Levels fyi data puts average US total comp around $238,000, with a typical range of $205,000–$486,000 and staff-level FDEs clearing $630,000. Palantir’s median sits near $215,000.

At the frontier labs it’s a different market entirely: senior FDEs at Anthropic and OpenAI clear $785,000, with Anthropic’s Applied AI Engineers above $300,000 base at senior levels and total comp regularly crossing $500,000.

One planning note worth having early: Anthropic typically does not negotiate offers.

04. Build engineering breadth

This is the counterintuitive part, and it’s where engineers coming from a specialist track get it wrong.

The strongest FDEs are not the deepest engineers their company has.

They’re the ones who can hold six domains in their head at once and switch between them cheaply. Depth in one area is worth less here than being genuinely solid across all of it.

Concretely, the floor looks like this. Python and TypeScript cover most of the ground you’ll touch. One cloud - AWS, GCP, or Azure, pick whichever your target customers actually run.

One database you know well and can debug under pressure, and one frontend framework you can throw a working interface together in.

That’s enough to start. You do not need to be the best engineer in the room; you need to be the only person in the room who can do all of it.

Two softer layers matter as much as the technical ones, and they’re what the interview will actually probe.

Product judgment, because you are the PM in the room and nobody else will decide what to build versus what to fake.

And business acumen - someone will ask what the ROI of this is, and they’ll need the answer to defend the project to their own leadership.

Framing your work in dollars and hours saved is a real, learnable skill that most engineers never practice.

05. Learn to ship AI, not train it

Here is the single most common misconception standing between engineers and this job: they assume they need to be able to train models.

You do not. Nobody is asking an FDE to fine-tune anything. You absolutely do need to ship them - which is a completely different and far more learnable skill set.

The AI-native layer is well defined at this point. Strong prompt engineering. Fluency with the major model APIs.

• RAG patterns - and specifically, knowing when retrieval is the wrong answer.

• Structured outputs, because production systems need validated shapes, not prose.

• Basic eval discipline, which is the layer that separates people who demo from people who ship.

And at least one agent framework you’ve actually built something in.

Weight your preparation toward evals and failure modes, because that’s what enterprise deployment is actually made of. Debugging hallucinations, retrieval failures, bad tool calls, brittle multi-step workflows.

Knowing how to reason about latency, cost, reliability, and security as tradeoffs rather than checkboxes.

# Rate 1-5. Anything below 3 is your next month of work.

## Engineering breadth          # solid, not elite
[ ] Python // backend, scripts, data
[ ] TypeScript // integrations + a usable frontend
[ ] One cloud, deployed something real to it
[ ] One database, can debug it under pressure
[ ] Can stand up a working UI in a day

## AI native                     # ship, don't train
[ ] Prompt engineering beyond trial and error
[ ] Model APIs: streaming, tool use, token budgets
[ ] RAG // and knowing when retrieval is the WRONG answer
[ ] Structured outputs + schema validation
[ ] Evals // the layer that separates demo from production
[ ] One agent framework, something actually built

## The half nobody practices
[ ] Ran a workshop with a non-technical stakeholder
[ ] Said "we should not build that" to a paying customer
[ ] Expressed your work in dollars or hours saved
[ ] Learned an unfamiliar industry well enough to ship in it
6
Build the stack

Anyone can get a demo working; the entire value of an FDE is being the person who knows why the demo won’t survive contact with a real company, and what to do about it.

06. Build the three artifacts enterprises buy

This is where a generic “learn AI” roadmap stops being useful and specifics start to matter.

Anthropic’s own FDE postings describe the deliverables plainly: you embed with strategic customers to build production applications with Claude, and you ship MCP servers, subagents, and agent skills.

Those three artifacts are the concrete unit of work.

• MCP servers are the integration layer - the thing that connects Claude to the customer’s actual systems: their ticketing, their warehouse, their internal API that has no documentation and one person who understands it.

• Agent skills encode the customer’s specific workflow and institutional knowledge so Claude follows their process rather than a generic one.

• Subagents handle the work that would otherwise blow out a context window on a long-running task.

Build one of each, against a real system, and you have something almost no candidate has: a portfolio of exactly the artifacts the job produces.

# The artifact an FDE actually ships: Claude, wired into a system
# nobody designed for it. Legacy API, no docs, one guy who knows it.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("warehouse-ops")

@mcp.tool()
def find_stalled_shipments(hours_stalled: int = 24) -> list[dict]:
    """Shipments with no scan event in N hours. Use when ops asks
    what is stuck, or before a customer escalation review."""
    # The real work: their legacy schema, their timezone quirk,
    # their soft-delete column that nobody documented.
    return query(STALLED_SQL, hours_stalled)

@mcp.tool()
def reroute(shipment_id: str, hub: str, reason: str) -> dict:
    """Reroute a shipment. Writes an audit row — compliance
    requires a reason string on every manual intervention."""
    return post_with_audit(shipment_id, hub, reason)

# Note what makes this an FDE artifact and not a demo:
#   - docstrings say WHEN to use the tool, not just what it does
#   - the audit row exists because their compliance team requires it
#   - the schema quirks are handled here, not left for the model

An MCP server that wraps a genuinely messy API is a stronger hiring signal than any certificate, because it proves the thing they can’t otherwise test for - that you can make a frontier model useful inside a system nobody designed for it.

07. Master Claude Code as your multiplier

Remember the third force from Step 2 - the underrated one. AI tools made FDEs dramatically more productive, and that is what made the role economically viable at scale.

One strong FDE now does work that took a team of three a few years ago. Sending a single human onsite for six weeks only pencils out because of that multiplier.

So the tooling isn’t a nice-to-have on top of the job; it’s load-bearing to the business case for your seat.

Practically, that means fluency with Claude Code is part of the skill stack, not adjacent to it.

The specific leverage points map directly onto FDE work: ramping into an unfamiliar codebase fast when you land at a new customer, writing the integration glue that makes up most of your output, and delegating research to subagents so a long deployment task doesn’t collapse under its own context.

There’s a hiring-signal reason to get good at this too, and it’s unusually direct. In Anthropic’s technical use-case screen, you may be given access to Claude and asked to work through the problem with it - deliberately, because it mirrors the actual job.

How you drive the model is part of what’s being evaluated. Practicing that is preparing for the interview and doing the work at the same time.

› Use a subagent to map how orders flow from intake to fulfillment in 
this repo. I need the data model, the integration points, and anywhere 
state can be written twice. Write it to notes/orders.md. 

● Spawning research subagent · separate context window 
● Read 23 files · 41.2k tokens — none of it in your window 

✓  Returned 680-token summary → notes/orders.md Found: intake writes to `orders` AND `legacy_orders`. Reconciliation job runs 
nightly. Anything failing between 18:00 and the 02:00 job is invisible to ops.

 › That gap is the customer's actual complaint. Draft the MCP tool 
that surfaces those in-flight orders, then we walk ops through it. 
day 2. the previous vendor took six weeks to find this.

08. Ship one real deployment for a real user

Every FDE job posting screens for the same phrase in some form: shipped production AI systems. Not studied, not prototyped - shipped, to someone who depended on it.

That’s the wall most candidates hit, and it’s the one thing on this list you cannot read your way past.

So manufacture the experience deliberately. Find one real workflow belonging to someone who is not you - a small business, a nonprofit, a team inside your current company, a friend’s ops process.

Sit with them. Watch them work. Build the thing that removes the worst part of their week, deploy it where they actually use it, and then stay long enough to fix what breaks.

That last part is not optional the whole job is what happens after the demo.

Then write it up the way an FDE reports, because the write-up is half the artifact. Not “built a RAG chatbot with LangChain.”

Instead: what their workflow cost before in hours, what constraints you couldn’t change, what you deliberately chose not to build, what broke in week two, and what it costs them now.

# Dispatch triage for a 14-van plumbing company
// Structure this like an FDE post-mortem, not a project README.

## The workflow before
Dispatcher spent ~2.5h/day reading job notes and reassigning vans.
Two people quit over it in a year. Nobody had ever timed it.

## Constraints I could not change
- Scheduling data lives in a hosted tool with a read-only API.
- Dispatcher will not use a new app. It had to live in SMS.
- Owner would not approve anything touching customer payment data.

## What I deliberately did NOT build
Auto-reassignment. They didn't trust it and would have turned it
off in week one. Suggestion + one-tap approve instead.
// Being right about this mattered more than the model choice.

## What broke in week two
Job notes had inconsistent van nicknames ("big blue" vs "V-3").
Fixed with an alias table the dispatcher edits herself.
// This is the part that separates shipped from demoed.

## After
~40 min/day. Ran 5 months. She still uses it. Owner added 2 vans.

That document is your interview. Every hiring manager reading it learns more about you than any résumé line could tell them.

09. Learn customer discovery

This is the step to read twice. Anthropic’s Applied AI Engineer loop includes a customer-conversation round, and it carries a hidden weight: it filters out roughly 60% of candidates who already passed the coding stages.

Strong engineers, eliminated at the round they didn’t prepare for. Meanwhile 73% of frontier-lab FDEs report that running discovery conversations was the skill they were least prepared for coming from a traditional software background.

The failure mode is predictable and almost universal: the candidate hears a customer problem and starts solving it. They propose an architecture. Some open an editor.

• The candidates who advance do the opposite - they run the round like a research interview. They ask about the buyer’s current evaluation criteria.

• They ask about previous failed AI deployments, which is where all the real constraints are buried. They ask what genuinely cannot change: compliance, latency, data residency.

• They ask which specific workflow this would replace and who loses work if it succeeds. They take notes. They reflect back what they heard. They do not write code.

Anthropic screens for this explicitly because enterprise Claude deals don’t close on technical depth alone. It’s a learnable skill - and you can practice it in the exact same sessions from Step 8.

# Run the round like a researcher. Solving too early is the tell.

## Surface the real constraints
- What have you already tried here, and why did it stop?
  // failed deployments hide every constraint that matters
- What can't change no matter what we build?
  // compliance, latency, data residency, the union contract
- Who has to approve this, and what will they object to?

## Find the actual workflow
- Walk me through the last time this went wrong.
- Who does this today, and what does it cost them per week?
- What happens downstream if we get it wrong at 3am?

## Define "good enough" — theirs, not yours
- What accuracy would make you turn this off?
- How will you know in 90 days whether this worked?
- What does the person doing this today do instead, after?

## Close the loop
- Reflect back what you heard. Get it corrected.
- Name what you would NOT build, and why.
// Saying "we shouldn't build that" is a senior signal, not a dodge.

Every time you sit with the person whose workflow you’re fixing, you’re rehearsing this round.

10. Run the interview loop

The loop is unusually consistent across the top companies, and it’s built to filter in both directions at once - against pure algorithmic engineers who can’t communicate, and against smooth consultants who can’t code.

Expect roughly five stages:

• A recruiter screen on motivation, background, and level fit.

• A technical use-case screen - at Anthropic, a practical scenario around deploying Claude with MCP tooling, where you plan and execute a long-running task and reason about reliability, context-window management, and consistency in production.

• A coding round that is practical rather than LeetCode: a rate limiter, streaming data processing, a distributed job queue, a token-budget allocator, a structured tool-use orchestrator - often with new customer constraints layered in mid-exercise to see whether you refactor cleanly.

• A hiring manager round on past projects and customer reasoning. Then a final panel on solution design and values.Two preparation notes that people skip.

• Mission alignment is screened seriously at Anthropic - read the Core Views on AI Safety, the Responsible Scaling Policy, and recent interpretability work before you apply; generic enthusiasm does not pass.

And their postings ask for “calibrated judgment about model risks,” which is the bullet that quietly eliminates otherwise strong candidates. Being able to say clearly where you would not deploy a model, and why, is part of the bar.

Six starting points - find yours

• Add the AI layer, keep the rigor. Your production instincts are the scarce half - most AI-native candidates have never run anything real. Add prompting, model APIs, structured outputs and evals, then ship one MCP server against a messy internal system.

• Stop training, start landing. You’re overqualified on modeling and underqualified on everything else. The job is integration, constraints and stakeholders. Deliberately build something boring that survives a compliance review and an ops handoff.

• Go where the deployments are. Frontier-lab FDE roles are rarely entry level. Aim one ring out - the startups and consultancies deploying AI into enterprises - where you’ll do the same work with less gatekeeping, then move up in two years.

• Close the coding gap, fast. You already have the half that eliminates 60% of applicants. Now get past the coding round: practical exercises, not LeetCode - rate limiters, streaming, job queues, tool-use orchestrators, written cleanly under changing constraints.

• Prove you can actually build. Discovery and stakeholder management are already yours. The loop is explicitly designed to filter out smooth talkers who cannot code - so your entire preparation is one shipped, maintained, publicly documented system.

• You may be doing this job already. Internal platform engineers who sit with business units are running the FDE motion under a different title. Rewrite your experience in the role’s language - workflows changed, hours saved, constraints navigated - and you’re a live candidate today.

Conclusion:

The scarce thing was never the model. It’s the person who can land it.

Capability stopped being the bottleneck somewhere in the last two years.

What’s scarce now is the engineer who can walk into a company with legacy systems, a compliance department, and a skeptical ops team -and come out six weeks later with something that actually runs.

That’s a strange combination of skills, which is exactly why it pays like it does. Engineering breadth over depth. J

udgment with no PM to lean on. The patience to sit in someone else’s messy reality long enough to understand it before writing a line.

Most engineers will keep optimizing for the roles that existed in 2020. The ones who learn to deploy will own the decade - because every model that ships from here still has to survive contact with a real company.

9/10 notice that half those steps never needed to wait at all.

They don’t route. They don’t branch. They don’t parallelize. They just queue - one head, one context, one thing at a time, until the window fills up and the agent forgets what it was doing.

Follow my Likedin for fresh AI alpha: https://www.linkedin.com/in/lev-deviatkin/

This is the 14-step roadmap that turns that single-file line into a graph: one that fans out across a fleet, verifies its own findings, and converges on a result a lone agent could never hold.

Here’s the shift nobody spells out. A prompt is a sentence. A loop is a cycle. A harness is the floor the agent stands on.

But the shape of the work itself - what runs before what, what can run at the same time, what has to wait for everything else - that shape is a graph. Nodes do the thinking. Edges carry the results.

Claude Code shipped the tooling to build these graphs directly: dynamic workflows.

Claude writes a plain JavaScript orchestration script, then spawns a coordinated fleet of subagents to execute it - and the coordination itself costs zero model tokens, because it’s code, not a conversation.

01. Nodes are jobs. Edges are what flows.

A graph has exactly two things, and getting them straight fixes most of the confusion. A node is a unit of work - one agent, one bounded job, one input in and one output out.

An edge is a dependency: it says this node’s output feeds that node’s input. Nothing more.

The mistake is treating “and then” as an edge. “Summarize the file and then tell me the weather” has no edge between the two - the weather doesn’t consume the summary.

That’s two disconnected nodes that a linear script needlessly chains. The edge only exists when data actually moves across it.

Learn to ask, for every “and then” in your agent: does the next step read the last step’s output? If not, there is no edge, and the wait is wasted.

python

Draw it as boxes and arrows. A box is an agent() call. 
An arrow is a variable passed from one call’s return into another’s 
prompt. If you can’t draw the arrow - if no variable crosses - the two 
boxes are independent, and independence is the thing you’ll exploit 
for the rest of this course.

02. Your linear script is a degenerate graph

When you write an agent as “do A, then B, then C, then D,” you’ve drawn a graph - a single unbranching chain. Every node has exactly one edge in and one edge out.

It runs correctly. It also runs slowly and fragile, because a chain has no redundancy: if C stalls, D never happens, and A’s work is trapped upstream with nowhere to go.

The first real skill of graph engineering is redrawing the chain. Take your linear agent and, for each arrow, ask the Step 1 question.

Most chains have two or three arrows that don’t carry data - they’re just the order you happened to type things in.

Cut those arrows and the chain collapses into something wider: a few independent nodes that could all run at once, feeding a single node that needs them all.

03. Give every node a contract

A node you can’t reason about is a node you can’t parallelize. The fix is a contract: bounded input, bounded output, exactly one job.

The input is whatever the node reads - passed in explicitly, never assumed from a shared window. The output is a defined shape, ideally validated, so the next node can consume it without guessing.

In a workflow this contract is enforced with a schema. When you hand Claude an agent() call with a JSON schema, the subagent Claude spawns is forced to return validated structured data - validation happens at the tool-call layer, so Claude retries on mismatch instead of handing you free text you have to parse and pray over.

This is the difference between a node Claude can wire into a graph and a node that only works when a human reads its output.

// A node with a real contract: bounded in, validated out, one job.
const ITEM = {
  type: 'object', additionalProperties: false,
  properties: {
    title:   { type: 'string' },
    url:     { type: 'string' },
    impact:  { type: 'string', enum: ['high', 'medium', 'low'] },
  },
  required: ['title', 'url', 'impact'],
};

const result = await agent(source.prompt, {
  label:  `research:${source.key}`,
  schema: ITEM,           // forces validated structured output
  agentType: 'general-purpose',
});
// result is now a shape the next node can trust — not free text.

04. Treat the edge as a data contract

An edge isn’t just “B comes after A.” It’s a promise about what crosses: A produces this shape, and B is built to consume this shape. When you name the edge by its data - not its order - two things get easier.

You can see instantly whether the edge is real (does data actually move?), and you can swap the node on either end without breaking the graph, as long as the shape holds.

In practice, the edge lives in plain JavaScript. The reduce step between fan-out and synthesis - flatten, dedupe, filter - is just code operating on the shapes your nodes returned.

No agent needed. One of the quiet wins of graph thinking: a huge amount of what people burn model tokens on is really an edge, and edges are free.

The temptation is to spawn an agent to “combine the results.” Resist 
it. If combining means flatten-and-dedupe, that’s results.flatMap(...) 
and a Set — deterministic, instant, zero tokens. Save agents for 
judgment, not for plumbing. A graph where every edge is an agent is a 
graph paying rent on its own wiring.

05. Fan out with parallel()

This is the move that pays for everything. When you have N independent nodes - N sources to check, N files to review, N routes to audit - you don’t chain them.

You tell Claude to fan them out and run them at once. In a workflow that’s parallel(): Claude takes an array of thunks and spawns one subagent per thunk, all executing concurrently, then hands you back the array of results.

Two details make it robust. First, parallel() is a barrier - it waits for every thunk before it returns, so the next stage sees the complete set. Second, a thunk that throws resolves to null instead of rejecting the whole batch, so one flaky agent can’t sink the run.

Always .filter(Boolean) the results. Concurrency is capped around your core count and the excess queues, so you can pass a hundred thunks and they’ll all finish - just a handful at a time.

phase('Research');

// Nine sources, nine agents, all at once.
const raw = await parallel(
  SOURCES.map((s) => () =>
    agent(s.prompt, {
      label: `research:${s.key}`,
      phase: 'Research',
      schema: ITEM_SCHEMA,     // each node returns validated JSON
      agentType: 'general-purpose',
    }),
  ),
);

const collected = raw.filter(Boolean);  // drop the nulls from failed agents

The fan-out lives in code Claude wrote, not in a model conversation. Claude’s own context never holds nine sources at once - each subagent carries its own, and only the final answer comes back.

That’s what lets Claude scale a workflow to dozens or hundreds of subagents without drowning the session. The orchestration layer costs zero tokens because it isn’t another turn of Claude thinking.

06. Fan in at a barrier

A fan-out is only useful if something gathers it. The fan-in is the node where edges converge - where one agent (or one piece of code) sees all the upstream results at once and does something that requires the whole set: dedupe across sources, rank by impact, early-exit if the total came back empty. This is the one place a barrier earns its wall-clock cost.

The rule that keeps graphs fast: use a barrier only when a stage genuinely needs every prior result together. Deduping across all sources? Barrier - correct.

// The edge: plain JS, no agent, zero tokens.
const flat = collected.flatMap((c) => c.items);
log(`Collected ${flat.length} items`);

phase('Curate');
// The barrier node: needs the WHOLE set to dedupe + rank.
const curated = await agent(
  `Dedupe and rank these by impact:\n${JSON.stringify(flat)}`,
  { phase: 'Curate', schema: CURATED_SCHEMA },
);

Just flattening a list? That’s an edge, do it inline. The smell test is brutal and simple: if you wrote parallel → transform → parallel, and that middle transform has no cross-item dependency, you should have used a pipeline and skipped the barrier entirely.

07. The diamond: split → work → merge

Put fan-out and fan-in together and you get the workhorse topology of every serious agent graph: the diamond.

One node splits the job, many nodes do the work in parallel, one node merges. It’s the shape behind a market scan, a dependency audit, a code review, a research report - swap the sources and prompts and the same skeleton adapts.

The canonical form has a name worth memorizing: fan out → reduce → synthesize. Fan out to gather breadth, reduce with plain code to compress it, synthesize with a final agent to write the answer.

Once you see the diamond, you stop asking “how do I make my agent do more steps” and start asking “where’s the split, where’s the merge” - which is the question that actually scales.

08. Route the edge at runtime with a conditional

Not every graph is fixed. Sometimes the edge to take depends on what a node found. A router node inspects a result and decides which downstream path fires - classify the ticket, then branch to the right handler; check the diff size, then either do a quick review or spin up a full audit.

In a workflow this is just a JavaScript if or switch on a node’s validated output, because control flow lives in code.

This is where determinism becomes a feature, not a limitation. The router’s decision can be Claude-powered (a subagent classifies), but the routing is code Claude wrote - so it runs the same way every time for the same classification.

You get Claude’s judgment at the node and the script’s reliability at the edge. No emergent “Claude decided to skip the audit” surprises - because the skip would have to be written into the graph, and it isn’t.

// Router node: an agent classifies, code picks the edge.
const { severity } = await agent(
  `Classify this diff's risk:\n${diff}`,
  { schema: { type: 'object',
      properties: { severity: { enum: ['low', 'high'] } },
      required: ['severity'] } },
);

let review;
if (severity === 'high') {
  // heavy path: full parallel audit
  review = await parallel(FILES.map((f) => () => agent(`Audit ${f}`)));
} else {
  // light path: one quick pass
  review = await agent(`Quick review of ${diff}`);
}

09. Put a verifier on the edge

The real leverage of a graph isn’t more agents - it’s the structure you can wrap around them to produce confidence.

A verifier node sits on the edge before a result is allowed downstream, and its only job is to try to kill the finding. If it survives, it passes. If not, it never reaches the answer.

Three patterns are worth having in your hands.

• Adversarial verify: for each finding, spawn N independent skeptics prompted to refute it; keep it only if a majority survive.

• Perspective-diverse verify: give each verifier a distinct lens - correctness, security, does-it-reproduce - because diversity catches failure modes that N identical checks never will.

• Judge panel: generate N attempts from different angles, score them with parallel judges, synthesize from the winner while grafting the best of the runners-up.

This is exactly the pattern that let a real team port the Bun runtime with adversarial code review baked into the loop.

10. Isolate nodes so one failure can’t poison the graph

In a chain, a failure cascades - C dies, D never runs, the whole thing halts. In a graph, failure should be contained to its node.

That’s already partly true: a thunk that throws inside parallel() resolves to null, so eight good agents still return while one bad one drops out. Your .filter(Boolean) is the containment.

Design every fan-in to tolerate missing inputs rather than assume a full set.

The subtler failure is nodes stepping on each other. When agents write files in parallel, they can collide.

The fix is isolation: “worktree” - each agent runs in its own git worktree, does its work in a sandbox, and merges cleanly.

Reach for it only when nodes actually write in parallel. it’s the seatbelt for the one topology that needs it, not a default tax on every run.

11. Add a cycle - but make it converge

Sometimes you don’t know how big the job is until you’re in it: unknown-size discovery, a bug sweep where finding one bug reveals three more. That needs a cycle - a controlled edge back to an earlier node.

The danger is obvious: a cycle that doesn’t converge is an infinite loop that spawns agents until your budget is gone

The pattern that converges is loop-until-dry: keep spawning finders until K consecutive rounds surface nothing new, then stop. The one detail that makes or breaks it - and the mistake almost everyone makes the first time - is what you dedupe against.

Dedupe against everything seen, not just against confirmed results. Otherwise rejected findings reappear every round, the loop never runs dry, and you’ve built a machine that pays to rediscover the same dead ends forever.

const seen = new Set(); const confirmed = []; let dry = 0;

while (dry < 2) {                       // stop after 2 empty rounds
  const found = (await parallel(
    FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))
  )).filter(Boolean).flatMap((r) => r.bugs);

  const fresh = found.filter((b) => !seen.has(key(b)));
  if (!fresh.length) { dry++; continue; } // nothing new → toward dry
  dry = 0;
  fresh.forEach((b) => seen.add(key(b))); // dedupe vs SEEN, not confirmed

  // diverse-lens verify each fresh finding before it counts
  const judged = await parallel(fresh.map((b) => () =>
    parallel(['correctness', 'security', 'repro'].map((lens) => () =>
      agent(`Judge "${b.desc}" via ${lens} — real?`, { schema: VERDICT })))
    .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));

  confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));
}

12. Tier the models across the nodes

Not every node needs your best model. A graph makes this obvious in a way a single agent never does: some nodes are bounded and repetitive (extract this field, classify this ticket), and some carry the real judgment (synthesize the report, adjudicate the finding).

Run the boring nodes on a cheaper model and spend your expensive tokens where judgment actually lives.

In a workflow every subagent Claude spawns inherits your session model unless the script overrides it - so by default a big run bills entirely at your session tier. The model option on a single agent() call tells Claude to route just that node elsewhere.

Check /model before a large run, then have Claude route the fan-out’s repetitive nodes down to a cheaper model and keep the merge node up. This is the lever that turns a token-hungry graph from expensive into economical without touching its shape.

13. Topology is your cost and latency

The shape of the graph isn’t cosmetic - it’s the single biggest lever on wall-clock time. The choice that trips everyone up: parallel() versus pipeline(). A parallel() barrier makes everything wait for the slowest node before the next stage starts.

A pipeline() streams each item through all stages independently, with no barrier - item A can be in stage 3 while item B is still in stage 1. Fast items finish early instead of idling behind slow ones.

Default to pipeline(). Reach for a barrier only when a stage truly needs every prior result at once - a cross-set dedupe, an early-exit on the total, a prompt that compares against “the other findings.” “It’s cleaner code” and “the stages feel separate” are not reasons; barrier latency is real, measurable, wasted time. Separate is not the same as synchronized.

14. Let Claude draw the graph - self-routing

The final move is to stop drawing the graph by hand for jobs you can’t plan in advance.

With dynamic workflows, you describe the objective and Claude writes the orchestration script itself- decomposing the task, choosing the fan-out, spawning a coordinated fleet of subagents, and synthesizing the result. You get a graph tailored to this run instead of a fixed one you hoped would fit.

There are three ways in. Say the word “workflow” in your prompt and Claude writes one for the task. Run a saved or bundled one - /deep-research is a real graph shipping in production: scope → parallel search → fetch → adversarial verify → synthesize, the exact skeleton from this course.

Or turn on ultracode and Claude plans a workflow for every substantial task in the session. When a run is good, press s to save its script into .claude/workflows/ - version-controlled, re-runnable by name, a graph anyone who clones the repo can launch.

› Run a workflow to audit every route under src/routes/ for missing 
auth. Spawn one agent per route file, then verify each finding before 
reporting. ● Claude wrote an orchestration script · launching in 
background… /workflows — auth-audit · running ✓ Scope 1/1 2.1k tok · 
4s ✓ Fan-out 18/18 one agent per route file ◯ Verify 11/18 3-vote 
skeptics per finding… ○ Synthesize 0/1 waiting on verify session stays 
responsive — keep working while the fleet runs

Six graphs to build with Claude this week

• Security sweep across every route. Claude spawns one subagent per route file, each hunting for missing auth checks, then a verifier pass confirms every finding before it reaches the report. Breadth no single context could hold.

• Cited report with /deep-research. A graph that ships in Claude Code already. Claude decomposes your question into distinct angles, runs parallel searches, dedupes sources, then adversarially verifies every claim with three-vote skeptics before writing.

• Port a module, file by file. The Bun ceiling, scaled to your repo. Claude fans out translation across files, runs the test suite as a gate on each, and loops the failures back - adversarial review catching what a single pass would ship broken.

• Adversarial review of a diff. Claude routes on diff size: a small change gets one quick pass, a large one triggers a full parallel audit with reviewers on distinct lenses - correctness, security, performance - then a judge panel synthesizes.

• Ecosystem scan on a schedule. Save it once, re-run it forever. Claude checks many sources in parallel - eleases, blogs, discussion - ranks by impact at a barrier, and writes the digest. Version-controlled in .claude/workflows/, launchable by name.

• Discovery of unknown size. You don’t know how many bugs are there. Claude runs finders in parallel, dedupes each new find against everything seen, verifies survivors, and keeps looping until two rounds turn up nothing new - then stops.

Conclusion:

A prompter asks a question. An architect draws a graph.

The linear agent was never the ceiling - it was just the first shape, the one everyone reaches for because it matches how we type. One line, one head, one thing at a time.

Once you can see the nodes and the edges, you stop asking the agent to do more and start asking the graph to do it wider: fan out where the work is independent, gate the edges where confidence matters, tier the models where judgment doesn’t.

Most people will keep queueing steps in a line. The ones who learn to draw the graph will run a fleet - and never notice the ceiling the rest are stuck under.

Then they wonder why their loop produces slop. The truth is simple: a loop is only as good as the harness underneath it. This is the 14-step roadmap to the harness - from one agent to a system that improves itself.

Loop engineering - building a system that prompts your agent on a schedule - got all the attention this month. But Addy Osmani, who wrote the long-form piece on loops, was careful to point at what sits below it:

“Loop engineering sits one floor above the harness. The harness is the environment one single agent runs inside. The loop is the harness, but it runs on a timer, spawns helpers, and feeds itself.”

Harness engineering is designing that environment: the model, the tools, the permissions, the context, the memory.

It’s the unglamorous layer - and it’s the one that decides whether everything above it works. A great loop on a bad harness is a fast way to produce garbage at scale.

14 steps. 3 tiers. The foundation everything else stands on.

Part 1 · what Harness is

01. A harness is the environment one agent runs inside.

Strip away the jargon and a harness is four things: the model doing the thinking, the tools it can reach, the permissions on those tools, and the context it reads at the start of every run.

That’s the whole surface. Everything else - subagents, hooks, memory - is a way of shaping one of those four.

True loop that picks a tool, runs it, looks at the result, and decides the next move.

The harness defines what tools exist, what the agent is allowed to do, and what it knows when it starts. Same model, different harness, completely different agent.

02. The whole harness lives in one folder. .claude/

Everything that shapes your agent sits in a single directory at your project root. Learn this layout and you can read anyone’s harness at a glance:

.claude/
├─ CLAUDE.md          # standing facts — read every session
├─ settings.json      # permissions, model, hooks
├─ .mcp.json          # external tool connections
├─ rules/             # path-scoped behaviors
│  ├─ tests.md
│  └─ python-types.md
├─ agents/            # subagent definitions (~30 lines each)
│  ├─ reviewer.md
│  └─ eval-runner.md
├─ skills/            # reusable workflows
│  └─ pr-checklist/
│     └─ SKILL.md
└─ agent-memory/      # what survives between runs
   └─ STATE.md

One rule that separates a clean harness from a mess: keep it small enough that you can explain why every file exists. If you can’t say what a rule, hook, or subagent is for, delete it.

03. Harness vs loop vs system. Three floors, don’t mix them.

Most “my agent setup is a mess” problems come from confusing the three floors. Keep them straight:

• The harness is the runtime one agent lives in. Static configuration: model, tools, permissions, context. This issue.

• The loop prompts the agent on a timer, spawns helpers, feeds itself. It runs on top of the harness.

• The self-improving system is a loop plus memory that compounds - every run leaves the next run sharper.

The practical version: put standing facts in context, enforcement in hooks, procedures in skills, and isolation in subagents.

Mixing these up - enforcement in CLAUDE.md, procedures bloating context - is the root cause of inconsistent, expensive agents.

04. The default harness. What you get out of the box.

Install Claude Code, open a folder, and you already have a harness - just an empty one. The default gives you a capable model, the built-in tools (read, write, bash, search), and approval prompts on everything risky. No project context, no custom subagents, no memory.

For a one-off task, the default is fine. For anything you do more than once, the default leaves the agent re-deriving your project from scratch every session, asking permission for safe operations, and forgetting everything when you close the terminal.

The next ten steps are about closing that gap.

05. CLAUDE.md: standing facts, kept short.

CLAUDE.md is read at the start of every session. It’s the agent’s standing knowledge of your project - conventions, architecture, the “we don’t do it this way because of that incident.”

The single most common mistake: letting it grow into a giant procedures document that bloats every session.

The rule from practitioners running this daily: keep the main memory file under ~500 tokens. Standing facts go here.

Multi-step procedures go in skills (step 8). Path-specific behaviors go in rules/ files scoped to where they apply. If a section of CLAUDE.md has become a procedure rather than a fact, it belongs somewhere else.

Read your CLAUDE.md out loud. Every line should be a fact the agent needs in every session (“we use pnpm, not npm”). If a line is a procedure (“to add a feature, first…”), move it to a skill.

If it’s a rule for one folder, move it to rules/.

06. settings.json: permissions and model, set once.

The default harness asks before every risky action. That’s right when you’re watching and wrong when you’re not. settings.json is where you pre-approve the safe stuff, deny the dangerous stuff, and pick which model runs.

{
  "model": "claude-sonnet-4-6",
  "permissions": {
    "autoApprove": [
      "Read(*)", "Grep(*)",
      "Bash(npm test)", "Bash(git status)"
    ],
    "deny": [
      "Bash(rm -rf*)", "Bash(git push*)",
      "Edit(.env*)", "Edit(secrets/*)"
    ]
  }
}

The test for what to auto-approve: if this goes wrong, how hard is it to undo? Cheap to undo → auto-approve.

Expensive to undo (force-push, deleting files, touching secrets) → always deny or prompt. The middle ground is fine to auto-approve if you log it.

07. Subagents: isolated context for the dirty work.

A subagent is an independent Claude session launched from the main one - its own context window, its own tool list. The point isn’t parallelism for its own sake. It’s keeping noise out of the main context.

A research task that reads 40 files, a review pass that needs a fresh perspective, an eval run that produces a wall of logs - those belong in a subagent so they don’t pollute the main thread.

The most valuable subagent in any harness is the one that checks work the main agent did. A model reviewing its own output is too easy on itself;

A separate reviewer with a fresh context window catches what the writer talked itself into. This is the writer-vs-checker split that makes every loop above the harness trustworthy.

08. Skills: procedures the agent reuses.

A Skill is a SKILL.md file the agent runs - either when you call it with /skill-name or automatically when the task matches its description.

Unlike a subagent, it runs in the same context window. It’s just reusable instructions that become part of the session.

The trigger to create one: you notice yourself pasting the same instructions into every new conversation. That’s a skill waiting to happen. A PR checklist, an eval procedure, a release process - written once, invoked forever.

And because skills are the reusable unit, they’re what makes the harness improve over time: each time the procedure fails in a new way, you add the lesson to the skill, and the next run inherits it.

09. Hooks: deterministic rules the model can’t hallucinate.

Everything so far depends on the model understanding your instructions. Hooks don’t.

A hook is a shell command that fires at a fixed point in the agent lifecycle - before a tool runs, after a file changes, when the session ends- and its exit code can block the action. Hooks are enforcement, CLAUDE.md is suggestion.

Two hooks earn their place in almost every harness:

• A PreToolUse gate that blocks dangerous commands deterministically — rm -rf, reading .env, pushing to main. Exit code 2 stops the call before it happens. The model can’t talk its way past it.

• A PostToolUse formatter that runs your linter or formatter after every edit. The agent never ships unformatted code because the harness formats it automatically.

"hooks": {
  "PreToolUse": [{
    "matcher": "Bash",
    "command": "./.claude/hooks/block-dangerous.sh"
    // exit 2 = block the call before it runs
  }],
  "PostToolUse": [{
    "matcher": "Edit|Write",
    "command": "prettier --write \"$CLAUDE_FILE_PATH\""
  }]
}

Use hooks for anything that must happen or must never happen - safety, formatting, audit logging.

Don’t use them for judgment calls; that’s what the model is for. A good harness has one or two sharp hooks, not twenty.

Part 3 · make It Compound

10. Add a loop. Now the harness runs on a timer.

A configured harness still waits for you to type. A loop makes it run on its own. The simplest version is /loop in Claude Code - a recurring prompt on a cadence.

Pair it with /goal and the loop keeps going until an objective condition is true, checked by an independent grader rather than the agent grading itself.

> /loop 30m /goal All tests pass and lint is clean.
  Triage new failures, draft fixes in claude/ branches.

▲ Claude uses the harness you built:
  - rules/ for conventions
  - reviewer subagent to check each fix
  - PreToolUse hook blocks pushes to main
✓ Looping. Independent grader decides “done.”

Notice what just happened: the loop didn’t add intelligence. It re-used everything in the harness - the rules, the reviewer subagent, the safety hook. A good harness makes a loop trivial. That’s the whole point of building the foundation first.

11. Add dynamic workflows. The harness writes its own orchestration.

For tasks too complex for a single loop - massively parallel, highly structured, adversaria- Claude can write its own JavaScript harness on the fly.

That’s a dynamic workflow: agent() to spawn, parallel() to fan out, pipeline() to stream. It composes the subagents your harness defines into patterns like fan-out-and-synthesize or adversarial verification.

The connection to harness engineering: a dynamic workflow is only as good as the subagents and skills it can call.

If your harness has a sharp reviewer subagent and a well-written eval skill, the workflow has good pieces to orchestrate. If the harness is empty, the workflow has nothing to work with.

The workflow is the conductor, your harness is the orchestra.

12. Add memory. What the agent forgets, the harness remembers.

This is the step that turns a configured harness into a system that actually improves. The agent forgets everything between runs. The harness doesn’t have to.

A state file - a markdown file in agent-memory/, or a Linear board - records what was tried, what worked, what failed, what rules survived.

The pattern that makes memory compound, drawn from how the strongest agents use it:

• Write before walking away. Every run ends by updating the state file - lessons learned, verified facts, what’s next.

• Read at the start. Every run begins by reading the state file and relevant skills, so it resumes instead of restarting.

• Distill into skills. When a lesson is general (“Windows runners need bash, not PowerShell”), it graduates from the state file into a skill, where it applies to every future project.

# Project memory

## Verified facts # stop guessing about these
- prc is in dollars, not cents (checked via SELECT MIN/MAX)
- auth middleware order: rate_limit -> jwt -> rbac

## Lessons learned # distill the general ones into skills
- Windows CI runners fail TLS 1.2 in PowerShell — use bash
- Migrations on tables >1M rows must batch in 10k chunks

## Last session # resume, don’t restart
2026-06-11 · 3 fixes merged, 2 escalated. Next: verify rate-limit fix.

13. Close the loop. Output → lesson → skill → better output.

Here’s where the three floors lock together into something that improves itself. Each run produces output. The reviewer subagent (step 7) checks it.

The result - what passed, what failed, what was learned - gets written to memory (step 12). The general lessons get distilled into skills (step 8).

The next run inherits sharper skills and richer memory.

That’s the whole self-improving loop, and notice it’s built entirely from harness parts:

• Subagent grades the work - objective check, fresh context.

• Memory records the verdict - survives between runs.

• Skills a runs it again - now with everything the last run learned.

• The loop runs it again - now with everything the last run learned.

The model never changed. The harness around it got sharper. That’s what “self-improving” honestly means - not a model that learns, but a harness that accumulates.

14. Ship the harness. Package it. Share it. Reuse it.

A harness that works on one project is an asset.

Bundle the skills, subagents, and rules into a plugin and your whole team installs the same setup in one step - same conventions, same safety hooks, same reviewer.

The harness stops being your personal setup and becomes shared infrastructure.

The order to build, one last time, because order is the lesson: get one manual run reliable on a clean harness.

Add the context and permissions. Add a reviewer subagent. Add memory. Then and only then wrap it in a loop. A loop on a good harness compounds. A loop on a bad harness just bleeds faster.

§ The harness mistakes that make every loop worse

• Running on the default. No context, no rules, no memory - the agent re-derives your project every session.

• A bloated CLAUDE.md. Procedures stuffed into standing context, bloating every run. Move them to skills.

• Enforcement in CLAUDE.md instead of hooks. The model can ignore a suggestion. It can’t ignore a hook that exits 2.

• One agent writing and grading its own work. Add a reviewer subagent with a fresh context window.

• No memory. Every run restarts from zero. The state file is what makes tomorrow resume.

• Wrapping a loop around a bad harness. The loop just produces slop faster. Build the foundation first.

• Twenty hooks. One or two sharp ones beat a pile nobody understands.

• Shipping a harness without scanning it. Leaked secrets and over-broad permissions spread to everyone who installs it.

Conclusion:

The loop gets the glory. The harness does the work.

Loop engineering is the exciting part - the agent prompting itself, running while you sleep. But a loop is just a harness on a timer.

Everything that decides whether the output is good or garbage lives one floor down, in the model you picked, the tools you allowed, the context you wrote, the reviewer you added, the memory you kept.

Build that floor well and everything above it compounds: the loop re-uses your subagents, the workflow orchestrates your skills, the memory makes each run sharper than the last.

Self-improvement was never a property of the model. It’s a property of the harness you build around it.

Pick one thing you’re not doing - probably a reviewer subagent, a safety hook, or a state file — and add it today. Keep the harness small enough to explain. Then put a loop on top, and watch the foundation do the work.

9 out of 10 users have never run an agent system that compounds - where every run leaves the next run smarter, every state file accumulates, every skill sharpens.

Fable 5 was built to run for days. You’re using it for minutes. This is the 14-step roadmap to build the self-improving system Fable 5 was designed for.

Claude Fable 5 launched June 9, 2026 - the first publicly available Mythos-class model, the tier Anthropic put one rung above Opus.

This is the 14-step roadmap to build the self-improving system Fable 5 was designed for - sourced from Anthropic engineering posts, the team’s public experiments, and verified against the launch documentation as of June 2026.

Three tiers: what Fable 5 actually unlocks, the three primitives that make it compound (loops, dynamic workflows, routines), and the self-improvement layer that turns it into a system.

14 steps. 3 tiers. Stop prompting. Start building a system that compounds.

PART 1 · What Fable 5 actually unlocks

01. Fable 5 is a Mythos-class model. Days-long autonomy is the headline.

Claude Fable 5 launched June 9, 2026 as the first publicly available Mythos-class model - the tier Anthropic introduced one rung above Opus.

Mythos Preview shipped in April through Project Glasswing to a handful of critical-infrastructure partners; Fable 5 is the version Anthropic considered safe for general release, with built-in safety classifiers that decline requests in high-risk areas.

Mythos 5 (without those classifiers) remains Glasswing-only.

What Fable 5 actually does that previous Claude models couldn’t sustain, from Anthropic’s launch documentation:

• Days-long autonomous sessions. Run inside an agent harness like Claude Code or Claude Managed Agents (CMA), Fable 5 can work for days - planning across stages, delegating to sub-agents, and checking its own work.

• Self-verification built in. Writes its own tests to check its work. Uses vision to check outputs against goals. Distills lessons into general rules. Tests its own assumptions.

• Most ambitious code work. Large migrations, complex implementations, multi-day autonomous coding sessions. The headline use case Anthropic puts forward is “hand off large projects and review completed deliverables.”

• Multi-stage knowledge work. Deep research and analysis to deliverables ready for review - with minimal oversight.

The pricing matches the tier: $10 per million input tokens, $50 per million output tokens, with the existing 90% input token discount for prompt caching.

Available on Claude API, AWS, Amazon Bedrock, Vertex AI, Microsoft Foundry, and the consumption-based Enterprise plan. This is not a subscription model. Heavy use earns its own bill.

02. Self-improving is not self-learning.

The phrase “self-improving agent system” gets thrown around carelessly. The version that’s real and the version that’s hype are very different things, and the gap is worth understanding before you build anything.

• Self-learning - the agent updates its own weights based on what it learns. Fable 5 does not do this. No publicly available model does this in production.
  
  Recursive self-improvement (RSI) is the long-term direction Anthropic itself warned about in May 2026, not the capability shipping today.

• Self-improving - the system around the agent compounds. Each session writes lessons to memory. Skills sharpen as edge cases get added.
  
  State files accumulate verified facts. Eval loops refine prompts and rubrics. The model stays the same; the environment it runs in gets sharper.

Self-improvement, in this sense, is a property of the system you build. Fable 5 has the raw capability - long context, sub-agent delegation, vision self-check, days-long stamina - that turns the environment-feedback loop into something that actually compounds run over run.

Anthropic’s engineering team puts it directly:

“Rather than directly prompting and steering Fable 5, it’s often better to design loops that let the model self-correct in response to environment feedback (e.g., /goal or Outcomes) and manage its own context (e.g., via memory).”

03. The compound stack: four layers, one feedback loop.

Figure 1 at the top of this article shows the architecture in one diagram. Read it from the bottom up - that’s the order the system gets built, and the order the leverage compounds.

• Layer 1 · Primitives. Fable 5 itself, sub-agents, worktrees, the tools the agent reaches for. Raw capability with no system around it yet. This is what most people use today.

• Layer 2 · Orchestration. /goal and Outcomes for self-correcting loops. Dynamic Workflows for complex multi-step orchestration. Routines for laptop-off cloud runs. This is what turns the primitives into a workflow.

• Layer 3 · Memory. State files, Skills, Knowledge Bases, lessons written down. Memory is what makes tomorrow’s session resume instead of restart.

• Layer 4 · Self-improvement. Vision self-checks, eval loops, rule distillation. The agent grades its own output, refines the Skill that produced it, writes the lesson back to memory. The loop closes.

The reason this architecture compounds: every output from layer 1 flows up through layer 4, where it gets graded, distilled, and written back to layer 3. Tomorrow’s run at layer 1 inherits the sharpened memory and refined Skills from yesterday. The model is stateless; the system around it isn’t.

04. When to use Fable 5 vs Opus 4.8 vs Sonnet 4.6. The cost-capability matrix.

Fable 5 costs ~5× what Opus 4.8 does per token. Not every step in a self-improving system needs the top tier. The teams running this in production route by task complexity, not by default:

• Fable 5 for the heavy-lift orchestrator role: planning across days, delegating to sub-agents, checking work with vision, distilling rules from accumulated evidence.
  
  Use Fable 5 where the “days at a time” capability earns its pricing.

• Opus 4.8 for hard-but-bounded subtasks the orchestrator delegates: architecture decisions, complex debugging, deep code reviews. Also the explicit fallback for any request Fable 5’s classifiers block (cyber, bio, chem, distillation).

• Sonnet 4.6 for high-volume worker tasks: lint passes, simple refactors, test scaffolding, doc updates. The bulk of fan-out work runs here.
  

• Haiku 4.5 for grader sub-agents and cheap classifiers. Independent context window, low cost - ideal for the verifier role Anthropic explicitly recommends.

The cost pattern that makes a self-improving system economical, used by teams running this in production: orchestrator on Fable 5, workers on Sonnet 4.6, graders on Haiku 4.5, fallback to Opus 4.8 on classifier blocks. Same pattern Anthropic engineers use internally.

PART 2 · The three primitives

05. /goal vs Outcomes. Two implementations of the same idea.

The Anthropic Claude Code team publishes two near-identical primitives for goal-driven loops one in each harness.

They share the same shape: an independent grader checks the work, a not-met verdict starts the next iteration, the loop exits when the grader passes.

The implementations differ in surface details that matter for which you use.

The decision rule between them is short:

• Use /goal in Claude Code when the work happens at your machine and you want a quick, in-session loop with a measurable end state. Best for hands-on coding, debugging flaky tests, refining a single file. Plain text goal, model grader, in-terminal feedback.

• Use Outcomes in CMA when the work needs to run for hours or days on Anthropic-hosted infrastructure with a sandbox, GPUs, or a controlled environment. Best for ML training, long-running migrations, multi-day research. File-based rubric with gradable criteria, sub-agent grader, hard max_iterations bound.

Both share the structural move that makes them work: the agent that wrote the code is not the agent that grades it. We go deeper on why that matters in step 6.

06. Verifier sub-agent beats self-critique.

Anthropic engineer Prithvi Rajasekaran wrote a piece on the engineering blog showing models have a hard time self-critiquing their own outputs. The Claude Code team confirmed this empirically with Fable 5:

“We’ve found that a verifier sub-agent tends to outperform self-critique with Fable 5”

The mechanism is structural, not about “trying harder.” A model evaluating its own output sees its own reasoning trail and prefers conclusions consistent with what it already wrote.

A separate model evaluating the same output sees only the artifact and the rubric. The verifier has no skin in the maker’s game.

What the chart actually shows, beyond the headline numbers:

• Fable 5 made larger structural changes - TRAIN_SEQ_LEN=2048 train+eval (−0.0179), overlapped sliding-window eval (−0.0207), int6 QAT + int6 expo (−0.0163). Each is an architecture-level move, not a constant tweak.

• Fable 5 pushed through a quantization regression to its biggest win - instead of reverting after a failed experiment, it continued investigating.

• Opus 4.7’s first experiment (QK_GAIN_INIT=5.0) produced a small win. Nearly everything that followed used the same template: adjust a scalar, measure, keep if positive. The shape is safer, not better.

The takeaway for system design: Fable 5 with an independent verifier explores larger hypothesis spaces and recovers from negative intermediate results. Without the verifier, the same model has nothing forcing it past the first “good enough.”

07. Dynamic Workflows compose self-correction patterns.

Dynamic Workflows shipped in Claude Code on May 28, 2026.

The idea: Claude writes its own JavaScript harness on the fly - a file with agent(), parallel(), and pipeline() primitives, plus standard JS to process the data flowing between them. The harness is custom-built for the task, not generic.

For self-improving systems with Fable 5, three of the six documented Dynamic Workflow patterns earn their place:

• Fan-out-and-synthesize. Split the work into N independent pieces, run an agent on each in parallel, synthesize results. Best when each step benefits from its own clean context window - e.g., evaluating each rule in a Skill against historical examples.

• Adversarial verification. For each maker agent, spawn an independent verifier with no exposure to the maker’s reasoning. The structural fix for self-preferential bias from step 6, applied per task.

• Loop until done. Loop spawning agents until a stop condition is met -no new findings, no more errors in the logs, theory verified. Pair with /goal to set a hard completion requirement.

The two patterns that don’t typically appear in self-improving systems but are worth knowing: classify-and-act (route the task to the right model based on a classifier) and tournament (pairwise comparison for taste-based ranking). The first is useful for model routing (step 4).

The second is rare in coding loops but useful for design or naming tasks.

08. Worktrees for parallel safety. Days-long Fable 5 sessions, no file collisions.

The moment a self-improving system spawns more than one agent, files start colliding. Two agents writing the same file is the same problem as two engineers committing to the same lines without talking first.

A git worktree fixes it - a separate working directory on its own branch sharing the same repo history, so one agent’s edits literally cannot touch the other’s checkout.

For self-improving systems where Fable 5 spawns sub-agents to verify or specialize, worktrees are non-optional:

• Maker writes in worktree A. Verifier reads in worktree B (or runs against the worktree A checkout with read-only filesystem). No risk the verifier’s exploration touches the maker’s state.

• Parallel structural experiments. If Fable 5 explores multiple architecture changes (like in Parameter Golf), each experiment runs in its own worktree. The orchestrator collects results from all of them; the best one merges.

• Days-long runs with checkpoints. Each major phase can be a separate worktree. A failed phase doesn’t poison the rest.

In Claude Code, worktrees are exposed three ways: git worktree directly, a --worktree flag to open a session in its own checkout, and an isolation: worktree setting on subagents so each helper gets a fresh checkout that cleans itself up after the session ends.

09. Routines for days-long orchestration. Laptop closed. Fable 5 working.

Routines launched April 14, 2026 in research preview. They’re saved Claude Code configurations - a prompt, repositories, connectors, permissions - that run on Anthropic-managed cloud infrastructure on a trigger.

Your laptop can be off. The run still happens.

For Fable 5 specifically, Routines are the trigger layer that earns the model’s capability. Anthropic measures Fable 5’s “days at a time” on Claude Managed Agents - a hosted sandbox with full tools and no local machine constraint.

The Parameter Golf experiment ran for up to 8 hours on 8×H100 GPUs. That class of run doesn’t happen on your laptop.

The three Routine trigger types, mapped to self-improvement patterns:

• Schedule triggers - the morning briefing pattern. Daily at 7am: re-run yesterday’s eval suite, distill any new failure modes into Skills, write the digest to Slack. The agent gets sharper while you sleep.

• API triggers - the “fire on event” pattern. CI fails → fire a Routine to investigate. Sentry alert → fire a Routine to triage. The self-improving system reacts to your real environment, not a fixed schedule.

• GitHub event triggers - the “learn from real work” pattern. On PR open, run an evaluation against the latest Skills. On merge, write any new patterns the PR introduced back to the Skill. Repository state and Skill state stay in sync.

> /schedule daily at 7am, use Fable 5 in CMA
  Goal: Re-run yesterday’s eval suite against the latest skills.
  Any test that newly passes → distill the pattern into the skill.
  Any test that newly fails → investigate, document in STATE.md.
  Post the digest to #engineering. /goal don’t stop until digest is
  posted and STATE.md is updated.

▲ Claude
  Creating routine: nightly-eval-compounding
  - model: claude-fable-5
  - harness: claude managed agent (sandbox)
  - trigger: schedule (0 7 * * *)
  - grader: independent Haiku sub-agent (Outcomes)
✓ Active. First run tomorrow 07:00 local. Skill set will compound.

PART 3 · The Self-Improvement Layer

10. The 5-stage memory progression.

The single most useful framing for what “agent memory” means in practice comes from the Anthropic team’s Continual Learning Bench 1.0 experiment. Effective use of memory requires a progression of five stages. Each stage is a structural move; each model exits the progression at a different point.

• 1. Fail - the agent gets something wrong and documents the failure with enough detail to be useful later.

• 2. Investigate — before moving on, the agent figures out why the failure happened.

• 3. Verify - the agent turns the diagnosis into a checked fact, not a guess.

• 4. Distill - the agent turns the verification into a general rule that applies beyond the specific case.

• 5. Consult - on the next task, the agent reads the rule instead of re-deriving the fact from scratch.

The measured difference between models on a SQL exploration task from the Continual Learning Bench, each model with memory provided:

• Sonnet 4.6 exits at step 1. Its memory store is a list of failure notes and open guesses (“maybe prc instead of prc_usd?”). It rarely consults prior notes. Memory exists but doesn’t compound.

• Opus 4.7 exits at step 3. It creates a schema reference with uncertainty flagged (“possibly prc in cents? Verify.”). Verification coverage runs 7–33% (median ~17%) of questions.

• Fable 5 tends to complete the progression. In its strongest runs, verification coverage reaches 73% (22 of 30), and it distills learnings into general rules that help with future tasks.

11. The state file. Where memory actually lives.

The 5-stage progression is the mental model. The state file is where the model writes each stage’s output. For Fable 5 running in Claude Managed Agents, memory is a mounted filesystem that survives between sessions; in Claude Code locally, a markdown file or a Linear board does the same job.

The structure of a state file that actually supports the 5-stage progression:

# Project memory · trading-platform

## Verified facts # stage 3 — stop guessing about these
- prc is in dollars, not cents. Verified via SELECT MIN(prc), MAX(prc) FROM trades.
- user_id matches auth_users.uid via JOIN, not auth_users.id. Confirmed 2026-06-09.
- Test database uses Stripe sandbox keys; production uses real keys via env.

## General rules # stage 4 — consult before re-deriving
- When querying time-bucketed metrics, always include timezone (default UTC mismatches).
- Auth middleware order matters: rate_limit -> jwt -> rbac. Reversing causes 401s.
- For migrations, never use ALTER on tables >1M rows without batching.

## Open failures (investigate next session) # stage 1 → 2
- 2026-06-09: tests/e2e/checkout flakes ~1 in 50 runs. Hypothesis: webhook race.
  Reproduction steps in debug/checkout-flake.md.

## Lessons learned # stage 4 distillations
- PowerShell hits TLS 1.2 issue on Windows CI runners. Always shell out to bash.
- Stripe webhook tests require STRIPE_WEBHOOK_SECRET. Skip with clear message if missing.

## Last session # stage 5 — resume, don’t restart
2026-06-10 03:30 UTC · 7 failures classified, 3 fixes drafted (claude/fix-*), 4 escalated.
Next: verify the auth middleware fix in claude/fix-rate-limit-order against production load.

The file has five sections matching the five stages. Verified facts is stage 3 output - things the agent stopped guessing about. General rules is stage 4 - distilled rules that apply beyond the specific case. Open failures is stages 1–2 work in progress. Lessons learned is more stage 4 output.

Last session is the resume pointer for stage 5.

Two operational rules that decide whether this file actually compounds or just grows:

• Write before walking away. Every Fable 5 session ends by updating STATE.md - what was tried, what passed, what failed, what new rules survived. If the session doesn’t finish with a write, the next one restarts from zero.

• Read at session start. Every new session begins by reading STATE.md and the most relevant Skills. The Continual Learning Bench data shows that without this, Sonnet-class memory behavior shows up even in Fable 5.

12. Skills that compound. Write the lesson into the Skill, not just the chat.

STATE.md is for project memory. Skills are for procedural memory - the “how to do this kind of thing” that should apply across projects.

The compounding pattern: after any non-trivial failure, write the lesson into the Skill itself. The Skill gets sharper every time the system runs.

A Skill that’s been compounding for two weeks looks different from a fresh one. New sections appear: known failure modes, rules that came out of post-mortems, anti-patterns observed in production.

The Skill is no longer a static set of instructions; it’s an accumulating record of what the team has actually learned.

---
name: ci-triage
description: Classify CI failures, draft fixes for easy ones, escalate the rest.
  Trigger on workflow_run.failure or on the morning triage routine.
---

# CI triage skill

## Classification rules
- env: missing secret, wrong env var. # escalate to human, never auto-fix
- flake: passes on retry without code change. # retry once, then file
- bug: deterministic failure tied to recent commit. # draft fix
- dependency: tied to version bump. # draft rollback
- infra: timeout, OOM, runner issue. # escalate

## Known failure modes # added by the loop over 14 days
- webhook-race: e2e checkout flakes when Stripe webhook arrives mid-test.
  Fix: add 2s settle delay in tests/utils/webhook.ts.
- tls-handshake: Windows runners fail TLS 1.2 in PowerShell. Use bash.
- db-migration: ALTER on trades table >1M rows times out at 30s. Batch in 10k chunks.

## Anti-patterns (do NOT do) # added after real incidents
- Never disable a failing test to make CI green. File it instead.
- Never modify .github/workflows/ without human approval.
- Never touch src/payments/ or src/billing/ without security review.

## State
Update STATE.md after each run with classifications, fixes drafted, escalations.

## Eval suite # step 13 — the loop verifies the skill
Run against eval/ci-triage-cases.jsonl weekly. Any newly-failing case →
add to known failure modes after Outcomes verifier confirms.

The compounding contract: every confirmed lesson goes into a Skill, not just STATE.md. STATE.md is project-scoped and dies with the project. Skills live in ~/.claude/skills/ and travel with you.

Two weeks of disciplined writing produces a Skill that materially outperforms whatever Fable 5 would derive from scratch on a fresh project.

13. Self-verification via vision. Fable 5 checks its own UI against the goal.

One of the headline capabilities Anthropic ships with Fable 5 is “uses vision to check outputs against goals.” This sounds abstract until you see what it actually replaces: the human eyeballing a screenshot to confirm the UI looks right.

Fable 5 does that step itself, in the loop, before declaring done.

The pattern in production:

• Maker sub-agent writes the UI code. Renders the result to a screenshot.

• Verifier sub-agent reads the screenshot with vision, compares it against the goal description, against design tokens in the project Skill, and against the previous screenshot from STATE.md.

• Verdict goes back to the loop. Match → mark task complete. Mismatch → describe the gap, hand back to maker with a structured diff.

This pattern is what Anthropic measured in the Parameter Golf experiment under the same harness: Fable 5 looked at training charts (visual artifact) and decided whether the curve matched the criterion.

No human in the loop reading the chart. The verifier read the chart.

14. The Mythos safety boundary. What Fable 5 won’t do, and how to design around it.

he last step is the one most easily skipped on day one and most expensive to learn the hard way.

Fable 5 ships with built-in safety classifiers that decline to respond in specific high-risk domains - cybersecurity vulnerability research, biology, chemistry, and model distillation. In those domains, Anthropic falls Fable 5 back to Claude Opus 4.8 automatically. This is documented; it’s not a bug.

What this means for a self-improving system that runs autonomously:

• If your system touches security tooling (SAST scans, exploit research, penetration testing logic, even some classes of code review), expect classifier blocks. Architect for the fallback: route those tasks to Opus 4.8 explicitly, or surface the block to a human reviewer.

• Same for biology, chemistry, and distillation domains. The classifier is broad. A scientific computing workflow might trigger it; a code review of crypto primitives might trigger it.

• Design your Skills to surface the fallback gracefully. A Skill should know which kinds of tasks it produces that may hit the classifier and document the expected behavior. A loop that silently fails on a classifier block looks identical to a loop that fails on a real error — until you debug it.

• Audit the system card. Fable 5’s 319-page system card documents the classifier’s scope. The launch generated controversy in mid-June 2026 because some downgrade behaviors were discovered buried in the document. Read it before deploying to production.

The general design principle: treat the safety boundary as a known fallback, not as a failure mode. A self-improving system that ships with explicit handling of the boundary stays robust as the classifier evolves. A system that ignores it produces silent regressions when Anthropic updates the policy.

§ The mistakes that keep Fable 5 at 10% of its potential

• Using Fable 5 like Sonnet 4.6 with more context. A 5-minute prompt-and-close session burns Mythos-tier pricing for no compound effect.

• Self-critique instead of an independent verifier. The maker grades its own homework. Anthropic measured the difference; the team explicitly documents the verifier sub-agent pattern.

• No STATE.md. Every session restarts from zero. The Continual Learning Bench data shows this is where 70%+ of Fable 5’s memory advantage disappears.

• Skills that never get written to. A static Skill is fine; a Skill that doesn’t accumulate lessons after real failures is wasted scaffolding.

• Fable 5 on tasks Sonnet 4.6 would handle. Doc updates, simple refactors, lint fixes. Route by complexity; reserve Fable 5 for the orchestrator role.

• Running long sessions on a laptop. Days-long capability requires cloud infrastructure (CMA or Routines). A closed laptop kills the session.

• Ignoring the Mythos safety boundary. Classifier blocks on cyber/bio/chem produce silent regressions. Architect for the fallback explicitly.

• No vision-verify on visual tasks. UI, dashboards, design fidelity — checking these with text-only verifiers misses the failure mode that matters.

• Skipping /goal or Outcomes. Without an objective stop condition checked by an independent grader, loops stop at “handled enough” instead of done.

• No retention policy review. Sensitive data through a Fable 5 routine without checking the 30-day / 2-year terms creates compliance issues silently.

Conclusion:

Fable 5 isn’t a faster chat tool. It’s the substrate for a system that compounds.

The first publicly available Mythos-class model didn’t ship to be prompted faster. It shipped to be the orchestrator of a self-improving system you build around it.

The capability headlines - days-long sessions, sub-agent delegation, vision self-check, accumulated memory - only earn their pricing if the system around the model is doing its job.

The Anthropic team’s own experiments make the gap visible. Parameter Golf: Fable 5 with an independent verifier explored larger architectural changes and pushed through negative intermediate results to land ~6× more improvement than Opus 4.7.

Continual Learning Bench: Fable 5 with memory completed the full 5-stage progression with 73% verification coverage, against Opus 4.7’s 17%. The model is the same in both halves of every comparison. The system around it is what changed.

Pick one layer of the compound stack you weren’t doing - probably the verifier sub-agent (step 6), the state file (step 11), or vision-verify (step 13) - and add it tomorrow. Then the next.

Self-improvement is a property of the system, not the model. Build the system.

No automation, no state file, no verifier, no schedule. The leverage point has moved - from typing prompts to designing systems that prompt. This is the 14-step roadmap from prompter to loop designer.

This is the 14-step roadmap to make that shift - sourced from Anthropic’s engineering docs, Addy Osmani’s long-form on loop engineering, and recent measurement studies.

Three tiers: figure out if you actually need a loop, learn the five building blocks, then build the smallest one that works without hurting you.

Follow my Linkedin to get fresh AI alpha: linkedin.com/in/lev-deviatkin

14 steps. 3 tiers. Stop prompting. Start designing.

01. Loop engineering is replacing yourself as the prompter.

For two years, the way you got something out of a coding agent was: write a prompt, share the context, read what came back, write the next prompt. The agent was a tool and you held it the entire time. That part is ending.

Loop engineering is building a small system that finds the work, hands it to the agent, checks the result, records what happened, and decides the next move - on its own. You design that system once. The system prompts the agent from then on.

Addy Osmani breaks it into six parts:

Anthropic engineers now merge eight times as much code per day as they did in 2024 - a figure Anthropic itself calls “almost certainly an overstatement of the true productivity gain.”

The number is debated. The mechanism isn’t: the leverage point moved from typing prompts to designing the loop that prompts.

02. Run the 4-condition test before you build anything.

Loops earn their cost under four conditions. Miss one and the loop costs more than it returns. The honest take from AlphaSignal’s analysis, and the part most X-threads skip:

The four conditions in plain English:

• The task repeats. A loop amortizes its setup across many runs. For a one-time job, a good prompt is faster and cheaper. If the work does not recur weekly, you don’t have a loop - you have a script you ran once.

• Verification is automated. The loop needs something that can fail the work without you in the room. A test suite, a type checker, a linter, a build. No automated check means you’re back in the chair reading every diff - the exact job the loop was supposed to remove.

• Your token budget can absorb the waste. Loops re-read context, retry, explore. That burns tokens whether or not the run ships anything. The technique scales with budget, which is why it reads as obvious to people with effectively free tokens and reckless to people on a metered plan.

• The agent has a senior engineer’s tools. Logs, a reproduction environment, the ability to run the code it writes and see what breaks. Without that, the loop iterates blind.

03. Who wins, who loses. Loops favor whoever can spend.

The economics are not universal. The people calling loop engineering obvious tend to have unmetered tokens.

The people for whom it’s reckless are usually on a $20 consumer plan trying to run heavy verification loops without hitting limits or a surprise invoice.

Who actually benefits, in practice:

• Teams with repetitive, machine-checkable work and the budget to run it - continuous test triage, dependency bumps, lint-and-fix passes, issue-to-PR drafts on a codebase with strong test coverage.

• Codebases with strong existing test suites. If a junior engineer could do the task from a checklist and a test suite would catch their mistakes, a loop fits.

• Async-first teams with multi-agent patterns already in use. For these teams, routines are the missing orchestration layer.

Who should skip it, today:

• Solo builders on consumer plans - the token bill arrives before the productivity gain does.

• Anyone working on code with no automated verification. A loop with no real check is the agent agreeing with itself on repeat.

• Teams whose real constraint is review capacity rather than typing speed. A loop generates more code; if review was already the bottleneck, it just makes the queue longer.

For one-off tasks, exploratory work, or anything where “done” is a judgment call, a single well-aimed prompt still wins. The honest version of this article is: loop engineering is real, and most developers don’t need it yet.

04. The 30-second loop check.

The 4-condition test from step 2 is the strategic decision. This is the tactical one - the checklist you run on a specific task before you turn it into a loop.

Miss one box and keep it as a manual prompt.

• 1. The task happens at least weekly. Less than weekly → setup cost will never amortize.

• 2. A test, type check, build, or linter can reject bad output. No automated gate → the agent grades its own homework.

• 3. The agent can run the code it changes. No reproduction environment → iteration is blind.

• 4. The loop has a hard stop. Token budget, iteration count, or time limit. Without one, the loop runs until someone notices the bill.

• 5. A human reviews before merge, deploy, or dependency changes. Anything irreversible needs a human approval gate before action.

Good first loops:

• CI failure triage - nightly, scan failures, classify causes, draft fix PRs for the easy ones.

• Dependency bump PRs - weekly, scan for updates, test compatibility, open PRs.

• Lint-and-fix passes - on every PR open event, apply style fixes automatically.

• Flaky test reproduction - loop until a theory survives the test.

• Issue-to-PR drafts on code with strong tests, where bad output gets rejected by the suite.

Bad first loops - these need a human in the chair:

• Architecture rewrites

• Auth or payments code

• Production deploys

• Vague product work

• Anything where “done” is a judgment call

05. Automations: the heartbeat.

Automations are what make a loop an actual loop and not just one run you did once. They fire on a schedule, on an event, or on a trigger condition. They’re the heartbeat - everything else in the loop hangs off them.

What this looks like in the two tools that matter:

• Codex. The Automations tab - pick a project, set a prompt, set a cadence, choose local checkout or background worktree. Runs that find something land in a Triage inbox; runs that find nothing archive themselves.

• Claude Code. Three primitives that compose into the same shape:
  
  /loop for session-scoped cadence, Desktop scheduled tasks for restart-survival, Routines for laptop-off cloud runs. Pair with hooks for lifecycle events.

Two primitives inside an automation that separate working loops from expensive ones:

• /loop re-runs on a cadence. Use it when you want regular checks regardless of state.

• /goal keeps going until a condition you wrote is actually true. A separate small model checks completion, so the agent that wrote the code isn’t the one grading it.

This is the maker-vs-checker split applied to the stop condition itself.

> /loop 30m /goal All tests in test/auth pass and lint is clean.
  Scan src/auth for new failures, propose fixes in claude/auth-fixes,
  open draft PR when goal condition holds.

▲ Claude
  CronCreate(*/30 * * * * : auth quality loop)
  Stop condition: tests pass + lint clean (verified by checker)
✓ Scheduled. Will continue past intermediate completions
  until /goal condition is met by independent checker.

06. Worktrees: parallel without chaos.

The second you run more than one agent, the files start colliding. Two agents writing the same file is the same headache as two engineers committing to the same lines without talking first.

A git worktree fixes it - a separate working directory on its own branch sharing the same repo history, so one agent’s edits literally cannot touch the other’s checkout.

How it shows up in both tools:

• Codex builds worktree support in - several threads hit the same repo at once without bumping into each other.

• Claude Code exposes git worktree directly, a --worktree flag to open a session in its own checkout, and an isolation: worktree setting on subagents so each helper gets a fresh checkout that cleans itself up after.

Worktrees take away the mechanical collision, but you are still the ceiling. Your review bandwidth decides how many parallel agents you can actually run - not the tool.

07. Skills: write project knowledge once. Read on every run.

A Skill is how you stop re-explaining the same project context every session like a goldfish. Both tools use the same format: a folder with a SKILL.md inside, holding instructions and metadata, plus optional scripts, references, and assets.

Why this matters specifically for loops: a loop without skills re-derives your whole project context from zero every cycle. With skills, intent compounds.

The conventions, build steps, “we don’t do it like this because of that one incident” - written once on the outside, read by every run.

name: ci-triage
description: Classify CI failures by root cause (env, flake, real bug,
  dependency, infra), draft fixes for the easy ones, escalate the rest.
  Trigger whenever a workflow run fails or on the morning triage loop.
---

# CI triage skill

## Classification rules
- env: missing secret, wrong env var, infra not provisioned. # human
- flake: passes on retry without code change. # retry once, then file
- bug: deterministic failure tied to recent commit. # draft fix
- dependency: failure tied to a version bump. # draft rollback
- infra: timeout, OOM, runner issue. # escalate

## Fix patterns
- Auth tests → check src/auth/middleware first
- Database tests → verify migration applied in CI env
- E2E tests → check selectors against the latest UI snapshot

## Never do
- Disable failing tests — always file as escalation instead
- Modify CI config without human approval
- Touch src/payments/ or src/billing/ (in claude/permissions.md)

## State
Update STATE.md after each run: file paths checked, classifications,
PRs opened, items escalated.

08. Connectors: the loop touches your real tools. Via MCP.

A loop that can only see the filesystem is a tiny loop. Connectors, built on the Model Context Protocol (MCP), let the agent read your issue tracker, query a database, hit a staging API, drop a message in Slack.

Codex and Claude Code both speak MCP, so the connector you wrote for one usually just works in the other.

This is the difference between an agent that says “here is the fix” and a loop that opens the PR, links the Linear ticket, and pings the channel once CI is green.

The connectors are the reason the loop can act inside your actual environment, not just tell you what it would do if it could.

The connectors that pay back fastest for loop work, in order:

• GitHub - read repos, create branches, open PRs, comment on issues, react to webhook events. The single biggest day-one win for any code loop.

• Linear or Jira - update tickets as the loop progresses, link PRs back to issues, close items automatically when verification passes.

• Slack - post triage results, ping humans on escalations, summarize overnight runs in the morning.

• Sentry / your error tracker - let the loop investigate live alerts and draft fixes for the high-frequency ones.

09. Sub-agents: keep the maker away from the checker.

The most useful structural thing in a loop, by far, is splitting the agent that writes from the agent that checks.

Osmani’s framing is exact: the model that wrote the code is “way too nice grading its own homework.” A second agent with different instructions and sometimes a different model catches the stuff the first one talked itself into.

This is the evaluator-optimizer pattern from Anthropic’s December 2024 engineering post under a new name. One model generates, another critiques, repeat. The vocabulary going viral in 2026 was documented eighteen months ago.

How sub-agents land in both tools:

• Codex only spawns subagents when you ask, runs them at the same time, then folds results back into one answer. You define your own agents as TOML files in .codex/agents/ - name, description, instructions, optional model and reasoning effort.
  
  Your security reviewer can be a strong model on high effort while your explorer is some fast read-only thing.

• Claude Code does the same with subagents in .claude/agents/ and agent teams that pass work between them.
  
  The usual split: one agent explores, one implements, one verifies against the spec.

The reason it matters specifically inside a loop: the loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away.

Sub-agents burn more tokens since each one does its own model and tool work - spend them where a second opinion is worth paying for.

10. The state file. The agent forgets. The file does not.

This is the piece that sounds too dumb to matter and is actually the spine of every working loop. A markdown file, a Linear board, a JSON state -anything that lives outside the single conversation and holds what’s done and what is next.

Why this matters: agents have short memory by default. What they learn this session is gone tomorrow unless you write it down.

Osmani’s rule: the agent forgets, the repo does not. A loop without persistent state restarts every run; a loop with state resumes.

# Loop state · ci-triage

## Last run
2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated

## In progress
- claude/fix-auth-token-refresh — tests passing locally, awaiting CI
- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring

## Completed today
- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)
- claude/lint-fix-pass-june-9 → merged

## Escalated to humans
- src/billing/refund.ts — tests failing in 3 ways, root cause unclear
- ci/staging-runner — infra timeouts, not a code issue

## Lessons learned (write here, not in chat)
- 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash.
- 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env. Skip if missing.

## Stop conditions met since last review
- /goal “all tests pass + lint clean” achieved on commit 3a7b8c1 at 02:14 UTC

Two patterns for where the state file lives:

• Markdown in the repo - STATE.md at the root or inside .claude/. Version-controlled. Simple. Diff-readable. Best for solo or small team work.

• External system (Linear, GitHub Issues, a database) - survives across repos, queryable, supports team-wide visibility. Best for production loops where multiple humans need to see what the loop is doing.

For long-running loops that risk drifting off the goal, pair the state file with a standing high-level spec - VISION.md or AGENTS.md - that the agent rereads each run. State tells the agent where it is. The spec tells it where to go.

11. The minimum viable loop.

If you passed the 4-condition test in step 2, build the smallest loop that works before anything fancy. Four parts, no swarm.

The four parts, in plain language:

• One automation. A scheduled run that fires on a cadence and stops on a clear condition. Use /loop in Claude Code or an automation in Codex. Pair with /goal when you want it to run until a stated condition holds.

• One skill. A single SKILL.md that stores the project context the agent would otherwise re-derive from zero every run.

• One state file. A markdown file or a Linear board that records what is done and what is next. Tomorrow’s run resumes instead of restarting.

• One gate. The test, type check, or build that fails bad work automatically. This is the part that decides whether the loop helps or just spends.

Order matters: get one manual run reliable first. Turn it into a skill. Wrap it in a loop. Then schedule it. Skipping ahead is how loops fail in production.

The metric that matters is cost per accepted change - not tokens spent, not tasks attempted, not loops scheduled. If your accepted-change rate is below 50% you’re doing review work the loop saved you from, and the loop is losing.

12. The Ralph Wiggum loop. Loops that fail quietly.

Engineer Geoffrey Huntley documented this failure mode and named it. An agent meant to emit a completion token only when finished emits it early, and the loop exits on a half-done job. Without a hard gate, loops fail quietly and keep spending.

The Ralph Wiggum loop is what happens when:

• No real verifier. Just a second agent asked to “review,” no objective signal. Two optimists agreeing.

• Soft completion conditions. “Done” defined by the agent’s judgment, not by a test, build, or type check.

• No hard stops. Loop continues until something external kills it (rate limit, you noticing) rather than until success is verified.

The fix is the gate from step 11 - something objective that can fail the work. A test that passes or fails. A build that compiles or doesn’t. A linter that returns zero or non-zero. Not a verifier that has an opinion.

Other measured failure modes worth knowing:

• Goal drift over long sessions. Each summarization step is lossy; “don’t do X” constraints disappear at turn 47. Mitigation: a standing VISION.md or AGENTS.md reread each run.

• Self-preferential bias. The agent that wrote the code is too nice grading its own homework. Mitigation: a separate verifier subagent with no exposure to the maker’s reasoning.

• Agentic laziness. The loop declares “done enough” at partial completion. Mitigation: /goal with an objective stop condition checked by a fresh model.

13. Comprehension debt and cognitive surrender.

This is the failure mode that gets sharper as the loop gets better, not worse. Two named risks, both from Osmani’s essay:

• Comprehension debt. The faster the loop ships code you didn’t write, the larger the distance between what the repository contains and what you understand. The bill that hurts is not the token bill. It is the day you have to debug a system no one on the team has read.

• Cognitive surrender. The pull to stop forming an opinion and accept whatever the loop returns. Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking. Same action, opposite result.

The mitigations are not technical:

• Read the diffs. If you don’t read what the loop ships, you’re renting comprehension debt at compound interest.

• Spot-check the gate. Pick a few PRs the loop opened and verify the test that approved them actually catches the failure mode you care about. Gates rot.

• Block the loop from architecture work. Keep it on small, machine-checkable changes. The moment you let it touch judgment calls, comprehension debt accelerates.

• Pair-design loops with a teammate. A second pair of eyes when designing the loop catches blind spots the loop will exploit forever otherwise.

14. The security tax. An unattended loop is an unattended attack surface.

A loop running unattended is also an attack surface running unattended.

The threat model your loop has to defend against:

• Generated code shipping unreviewed. The loop opens PRs faster than a human can read them. Without a gate that includes security checks (SAST, dependency audit, secret scanning), insecure code merges automatically.

• Skills as injection vectors. A loop that auto-installs skills inherits every prompt injection hiding in their descriptions. Audit skill sources before installing.

• Credentials in logs. Debug logging during a long-running loop scatters secrets across logs you don’t monitor. Disable verbose logging in production loops; sanitize what does get logged.

• Permission scope creep. A loop tested with read-only permissions gets “just one” write permission added for convenience, then never re-audited. Re-audit permissions every 30 days.

§ The mistakes that turn loops into money pits

• Building a loop without running the 4-condition test. Step 2 exists for a reason. Most developers fail at least one condition.

• No objective gate. A second agent asked to “review” without a test, type check, or build is just a second optimist.

• One agent doing both writing and verifying. Self-preferential bias. The maker grades its own homework and it’s always “A+.”

• No state file. Tomorrow’s run restarts from zero instead of resuming.

• Vague stop conditions. “Done when it looks good” never holds. Use a test, a type pass, or a passing build.

• No token budget cap. Loops re-read context and retry. Without a cap, ambitious loops burn 5-10× the tokens you expected.

• Running loops on a consumer plan with heavy verification. Token bill or rate limit, one of them gets you.

• Auto-installing community skills. 520 of 17,022 audited skills leak credentials. Read the source before installing.

• Loops on judgment-call work. Architecture, auth, payments, vague product decisions. Keep the loop on lint-and-fix, not strategy.

• Not reading the diffs. Comprehension debt at compound interest. The day you debug a system no one has read costs more than the tokens ever did.

Conclusion:

The leverage moved. Your job did too.

For two years, the leverage in working with coding agents was at the prompt. Better prompts, better context, better one-shot output.

That phase is ending. The agents got good enough that the next leverage point is one floor up: the system that decides what they work on, when, with what gate, and what state survives between runs.

But the honest version of this story is not that everyone should rush to build loops. Most developers don’t need one yet - not until the task repeats, verification is automated, the budget can absorb the waste, and the agent has senior engineer tools.

Miss one condition and the loop costs more than it returns.

If you pass the test, build small. One automation. One skill. One state file. One gate. Get a manual run reliable. Turn it into a skill. Wrap it in a loop. Then schedule it. Order matters. Skip ahead and you’re paying for a system no one understands.

Cherny’s point isn’t that the work got easier. It’s that the leverage point moved. Build the loop. Stay the engineer.

No /loop, no scheduled tasks, no Routines, no triggers. The tool that’s supposed to work while you sleep is still waiting for you to type. This is the 14-step roadmap to the full automation stack - and the hours back in your week.

Claude Code has been quietly shipping an entire automation stack over the last three months. /loop launched.

Auto Mode landed March 24. Cloud Routines opened in research preview April 14. By May 2026, the picture is complete: three layers of automation that go from your terminal to Anthropic’s cloud, each one earning its place by removing a different reason for you to babysit.

This is the 14-step roadmap to all three layers - every detail verified against the official docs at code.claude.com/docs as of June 2026. The arc is simple: get the manual loop right, make it persist across restarts, push it to the cloud where your laptop doesn’t matter.

14 steps. 3 tiers. One Claude that works while you sleep.

01. The /loop command. Explicit and natural language, both work.

The fastest way to make Claude Code do anything on a schedule. Inside any session, run /loop <interval> <prompt>.

Under the hood it calls three native tools: CronCreate, CronList, CronDelete. The intervals use a number plus unit: m for minutes, h for hours, d for days. The minimum is 1 minute - 30s rounds up.

> /loop 1m say hello

▲ Claude
  CronCreate(*/1 * * * * : say hello)
✓ Scheduled c21d95a0 (Every minute)
  - Job: say hello
  - Cadence: Every 1 minute (*/1 * * * *)
  - Job ID: c21d95a0
  - Duration: Recurring tasks auto-expire after 7 days
  - Cancel anytime: CronDelete c21d95a0

You don’t actually need to type /loop at all. Claude understands natural language schedules just as well:

• every 10 minutes, check the deployment status

• every weekday at 7am, summarize the overnight commits

• at 6:30pm today, post a status update to Slack

Times use the local machine’s time zone, not UTC. Any slash command available in Claude Code can be placed inside a /loop - including /run, /review, even another /loop if you’re feeling adventurous.

02. Real cron expressions for real schedules.

The CronCreate tool accepts standard 5-field cron expressions: minute hour day-of-month month day-of-week. All fields support wildcards (*), single values (5), steps (*/15), ranges (1-5), and comma-separated lists (1,15,30). Day-of-week uses 0 or 7 for Sunday through 6 for Saturday.

What is NOT supported: extended syntax like L (last day), W (weekday), ?, or name aliases like MON or JAN. When both day-of-month and day-of-week are constrained, a date matches if either field matches - standard vixie-cron semantics.

Cron patterns worth memorizing:

# Cron patterns that earn their keep

# every 5 minutes (only during business hours)
*/5 9-17 * * 1-5

# every weekday at 7am
0 7 * * 1-5

# first day of the month at 9am
0 9 1 * *

# every 15 minutes
*/15 * * * *

# nightly at 2:30am
30 2 * * *

# every Friday at 4pm
0 16 * * 5

# every 6 hours, on the hour
0 */6 * * *

03. Auto-expire and stop conditions

Four hard constraints that decide whether /loop is the right tool for the job. Memorize them or burn time figuring them out later:

• 7-day auto-expire. Every recurring task auto-deletes 7 days after creation. The task fires one final time, then removes itself. This bounds how long a forgotten loop can run. If you need it to live longer, cancel and recreate before the deadline - or use Routines (step 10).

• 50 tasks max per session. Plenty for individual workflows. If you’re building something more elaborate, count your tasks; you won’t get a warning until you hit the wall.

• No catch-up firing. If a task is due while Claude is busy on a long-running request, it fires once when Claude becomes idle, not once per missed interval. A 5-minute loop that hits during a 20-minute refactor produces one fire after, not four.

• Session-scoped. Closing the terminal cancels everything. Restarting Claude Code clears all scheduled tasks. There is no persistence across sessions - that’s what Tier 2 and Tier 3 are for.

To list and cancel tasks mid-session, just ask in natural language - Claude routes to CronList and CronDelete:

> show running cron jobs

▲ CronList()
   ID         JOB                       CADENCE
   c21d95a0   say hello                 Every 1 minute
   8f3aa412   check deploy status       Every 10 minutes
   bb7c0d91   morning summary           0 7 * * 1-5

> kill the deploy status check

▲ CronDelete(8f3aa412)
✓ Cancelled. 2 jobs remaining.

For CI environments or shared servers where background scheduling is undesirable, set CLAUDE_CODE_DISABLE_CRON=1 in your environment. The cron tools and /loop become unavailable, and any already-scheduled tasks stop firing.

This is the right move for any environment where the user who runs Claude isn’t the user who owns the schedule.

04. Pair /loop with /goal

A /loop on its own asks Claude to do something repeatedly. A /loop paired with /goal asks Claude to do something repeatedly until a specific condition is met - and to keep looping past intermediate “done enough” declarations.

This pairing solves agentic laziness inside a recurring task. Without /goal, a loop might address 20 of the 50 items it’s meant to handle and call the rest “handled.” With /goal, the stop condition is explicit and enforced:

A /loop on its own asks Claude to do something repeatedly. 
A /loop paired with /goal asks Claude to do something repeatedly until a specific condition is met — and to keep looping past intermediate “done enough” declarations.

This pairing solves agentic laziness inside a recurring task.
Without /goal, a loop might address 20 of the 50 items it’s meant to handle and call the rest “handled.” With /goal, the stop condition is explicit and enforced:

The three patterns where this pairing earns its keep:

• Flaky test debugging. Reproduce, form theories, test them, until one holds.

• Long-running migrations. Process items, save progress, continue until the queue is empty.

• Inbox-style triage. Process pending items, continue until nothing new arrives in a full cycle.

Four steps and you have a working manual loop. Now make it survive a restart.

05. Desktop scheduled tasks.

The Claude Desktop app has its own scheduler, separate from the CLI’s /loop. Create scheduled tasks from Schedule → New task → New local task.

You define a name, prompt, frequency, permissions, and working folder. Each fire starts a fresh Claude Code session - no shared context with anything else.

What this layer gives you that /loop doesn’t:

• Survives restarts. Reboot your machine, close all terminals - tasks still fire when their time comes.

• Fresh context each fire. No accumulated state from previous runs. Each task is essentially independent.

• Pre-configured permissions. Allowed tools, working folder, model, all locked in per-task.

What it still requires: your machine has to be awake. If your laptop is asleep when a task is due, the run is skipped. When the machine wakes or you reopen Claude Desktop, it checks the last 7 days for missed runs, starts one catch-up run for the most recently missed time, and shows a notification.

To prevent idle-sleep, enable Keep computer awake in Desktop Settings under General. Closing the laptop lid still triggers sleep.

Desktop scheduled tasks are macOS and Windows only. Linux users have two options: (1) use the CLI’s /loop for session-scoped scheduling, or (2) set up system cron jobs running claude -p <prompt> in headless mode for persistent scheduling. Routines (step 10) work everywhere because they run in the cloud.

06. Token budgets and rate limits.

The single biggest surprise on a Pro plan: every scheduled fire starts a full Claude Code session, and each session counts toward your usage limits. A 5-minute loop running for 24 hours is 288 sessions.

They’re not tiny - each one loads context, calls tools, possibly invokes subagents. Factor this in before you set up anything ambitious.

Three habits that keep automation affordable:

• Set explicit token budgets in the prompt. “Use at most 5k tokens. If you can’t complete in that budget, save partial progress and exit cleanly.” This caps each fire individually.

• Match the model to the task. Don’t default to Opus for everything. Most automation runs well on Sonnet. Cheap exploration runs on Haiku. The model picker inside the task config defaults to whatever the panel default is - not what your interactive sessions use. Set it explicitly per task.

• Pick the right plan for the volume. Pro plan tightens fast under heavy automation. Max gives 5× the headroom; Team and Enterprise more. If you’re shipping real automation, the upgrade pays for itself in not getting rate-limited at 3pm Tuesday.

07. Configure permissions for unattended runs.

By default, Claude Code asks for approval before running any bash command, writing any file, or calling any external API.

That’s fine when you’re watching. It’s a disaster when no one is. Three configuration patterns turn the default into something that can actually run unattended:

• Pre-approve specific tools via settings.json - an allow list of safe commands and a deny list of forbidden ones.

• Use .claudeignore at the project root to block access to credentials, environment files, and sensitive directories before any unattended task touches them.

• Enable audit logging to record every autonomous action. Read it the next morning instead of trusting the run blind.

{
  "permissions": {
    "autoApprove": [
      "Read(*)",
      "Grep(*)",
      "Bash(npm test)",
      "Bash(pytest)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "WebFetch(domain:docs.python.org)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push*)",
      "Bash(*--force*)",
      "Bash(curl*)",
      "Edit(.env*)",
      "Edit(secrets/*)"
    ]
  },
  "auditLog": true
}

The right test for what to auto-approve: if this turns out wrong, what does it cost to undo? Cheap to undo (a comment on a draft PR) - auto-approve. Expensive to undo (a force-push to main) - never.

The middle ground (creating a branch, opening a PR) is fine to auto-approve if you also have audit logs you actually read.

08. Auto Mode - AI-classified permissions

Auto Mode is the alternative to --dangerously-skip-permissions. Instead of blanket approval, an AI classifier evaluates each tool call against the active permission policy and decides whether to auto-approve, prompt, or block.

Anthropic measured that users approve 93% of permission prompts; Auto Mode automates the 93% and keeps the human in the loop for the 7%.

How it works in practice:

• Three tiers. Permissive, Balanced, Restrictive. Pick the one that matches your risk tolerance for the project.

• Two layers of defense. A server-side prompt-injection probe scans tool outputs before they enter Claude’s context. Then a classifier evaluates each proposed action.

• Audit trail. Every autonomous decision is logged. You can review what was approved and why after the fact.

Plan availability as of May 2026: Max, Team, Enterprise, and API plans (through the Anthropic API). Not currently available on Pro, Bedrock, Vertex, or Foundry.

Check code.claude.com/docs/en/auto-mode before planning around it. Once enabled, Auto Mode joins the Shift+Tab mode cycle alongside Accept Edits and Plan.

Auto Mode is still in research preview. The classifier’s decision logic is being refined and behavior may change between releases.

Pair it with .claudeignore and audit logs - Anthropic strongly recommends both. Don’t use it on shared team environments without additional safeguards.

09. Pick the right scheduler for the job.

Three schedulers, easy to confuse. The decision rule is one question: where does this need to run, and who needs to be awake for it?

The compounding pattern: start with /loop in a session to find what works, then promote to Desktop tasks for daily use, then promote to Routines when you want it running independent of your hardware.

Each tier earns its place by removing a different reason for you to be there.

10. Cloud Routines.

Released April 14, 2026 in research preview. Routines are saved Claude Code configurations - a prompt, repositories, connectors, permissions - that run on Anthropic-managed cloud infrastructure on a trigger.

Your laptop can be off. The run still happens.

Available on all paid plans (Pro, Max, Team, Enterprise). Create them at

claude.ai/code/routines

or with /schedule inside the CLI. The CLI creates schedule-triggered routines only; to add API or GitHub triggers, edit on the web.

What a routine actually contains:

• A self-contained prompt. The routine runs autonomously with no follow-up questions, so anything ambiguous becomes a coin flip on every run. Spell out what to do, what success looks like, where to send the result.

• One or more repositories. Cloned at the start of each run.

• Connectors. Slack, Linear, Drive, GitHub, anything you have wired up.

• An environment. Controls network access and secrets. Default is Trusted - allows package registries but not arbitrary outbound calls.

• One or more triggers. Schedule, API, GitHub event, or any combination.

By default, routines can only push to branches prefixed claude/. A poorly written routine cannot accidentally push to main. Disable this only if you have a downstream review process you actually trust. The default exists for a reason.

11. Schedule-triggered Routines

The most common trigger and the one to start with. Set a cadence - hourly, daily, weekdays, weekly, or a one-shot future time - and walk away.

> /schedule weekdays at 7am
  Goal: pull yesterday’s GitHub issues, classify by severity,
  draft fixes for any "P0" or "P1," open draft PRs for review.
  Post a digest summary to #engineering on Slack.

▲ Claude
  Creating routine: morning-briefing
  - trigger: schedule (0 7 * * 1-5)
  - repositories: org/api, org/web
  - connectors: github, slack
  - environment: Trusted
✓ Active · first run Monday 07:00 local time.
  View at claude.ai/code/routines

Three patterns that pay for themselves fast:

• Morning briefing. Pull yesterday’s metrics and incidents, summarize new GitHub issues, post a digest to Slack. By 8am you know what happened overnight, without you opening anything.

• PR review pass. Every weekday at 9am, scan open PRs assigned to you, leave a first-pass review comment with security and style flags. Human review starts pre-cleaned.

• Documentation drift detection. Weekly, scan code changes and flag any docs that haven’t been updated alongside them. Open a draft PR with the corrections.

Times are in your local zone and converted automatically. Runs may start a few minutes after the scheduled time due to stagger - consistent per routine.

12. API-triggered Routines

An API trigger gives a routine a unique HTTP endpoint and a bearer token. POST to it from anywhere - alerting systems, deploy pipelines, monitoring tools, your own apps - and the routine runs. Optional JSON body becomes one-shot context appended to the routine’s prompt.

# Fire a routine from anywhere with HTTP access
curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

# Response includes claude_code_session_id + URL to watch live

Two operational details that matter:

• The token is shown only once at creation. Store it immediately in a secret store - you can’t retrieve it later.

• Watch the beta header. The /fire endpoint ships under experimental-cc-routine-2026-04-01. Request and response shapes may change during preview. Anthropic guarantees the two most recent header versions keep working - migrate during the deprecation window.

What this trigger pattern actually unlocks: Claude becomes a callable workflow from any system in your stack.

CI fails → fire a routine to investigate and open a fix PR. PagerDuty alert → fire a routine to triage and post initial context.

Stripe webhook → fire a routine to update an internal dashboard.

13. GitHub-triggered Routines.

The GitHub trigger hooks a routine into the Claude GitHub App webhook. Supported events are broad: pull request, push, issue, check run, workflow run, discussion, release, merge queue.

Each matching event starts an independent session - no session reuse across events.

Where this trigger earns its place:

• PR open events → routine runs a code review pass, flags security and style issues, leaves a first-pass comment. Authors get pre-review feedback before human reviewers arrive.

• Issue create events → routine triages new issues, applies labels, links related code, drafts a first response. Backlog stays clean without anyone managing it manually.

• Workflow run events → routine investigates CI failures, identifies likely root causes, opens a draft fix PR. Failed builds stop being a manual chore.

• Release events → routine drafts release notes, posts to the changelog, notifies stakeholders. No more “who’s writing the changelog this sprint.”

Pull request filters let you scope precisely: author, title, body, base branch, head branch, labels, draft state, merged state, from-fork.

A routine that only fires on PRs labeled needs-security-review against main is one filter set away.

14. Compose with Skills and Dynamic Workflows.

The last step closes the loop with everything Claude Code shipped before. Each layer of automation gets more powerful when you pair it with the rest of the stack.

• Skills inside Routines. A Skill is a reusable instruction file. Drop your “PR review” or “morning briefing” Skill into ~/.claude/skills/, then point the routine prompt at it: “Use the morning-briefing skill.” The skill is your reusable recipe; the routine is the trigger that runs it.

• Dynamic Workflows inside Routines. For complex automation that benefits from parallel subagents - deep verification, tournaments, fan-out research - have the routine prompt invoke a workflow. Routines provide the scheduling; workflows provide the structure.

• Routines triggered by other Routines. One routine’s output (a PR open, a Slack message, a label change) can be the trigger for another routine. The composition isn’t a feature you toggle - it’s a pattern you set up by pointing one routine’s output at another’s trigger.

• Permissions per routine, not global. Each routine carries its own permission configuration. The morning-briefing routine reads everywhere but can’t push. The auto-fix routine pushes only to claude/ branches. The security-scan routine has the deny list maximized. Treat each routine’s permission file as part of its security boundary.

The whole stack at peak looks like this: Skills as your recipes, Dynamic Workflows as the orchestration, Routines as the trigger layer, Auto Mode as the permission classifier, Audit logs as your morning review. Every step in this article configures one slice of that stack.

You don’t need all of it on day one. Start with /loop. Promote to Desktop. Promote to Routines. Pair with Skills. Add Workflows when complexity demands it.

The habits that waste money on Claude automation

• Never trying /loop in the first place. The easiest tier of automation costs nothing and you’ve been ignoring it for three months.

• Forgetting the 7-day auto-expire. Set up a critical loop, walk away, wonder a week later why nothing happened.

• Using /loop for tasks that should outlast your terminal. The whole point of Tier 2 and 3 is exactly this case — promote it.

• Letting Automations default the model. Opus on every fire when Sonnet would do the same job for less. Check the model picker per task.

• No /goal on loops that should run until done. The loop stops at “handled enough” instead of the actual stop condition.

• Blanket approval via --dangerously-skip-permissions. One bad prompt away from a git push --force origin main. Use Auto Mode or an allow list.

• Vague routine prompts. A routine runs autonomously with no follow-up. Ambiguous prompts produce coin-flip behavior on every fire.

• No audit logs. “Trust the automation” without reviewing what it did is how silent failures become loud incidents.

• Disabling the claude/ branch prefix. The default exists for a reason. Don’t turn it off until your downstream review process is actually solid.

• Running automations on Pro. Heavy automation hits rate limits fast. If you’re shipping real workflows, the Max upgrade pays for itself in not getting blocked.

Conclusion:

Claude does not stop working when you stop typing.

The automation stack has been shipping in pieces for three months. /loop in March. Auto Mode two weeks later. Routines in April. The whole thing is live, documented, and available on plans you’re already paying for.

The only thing standing between “Claude as expensive chatbot” and “Claude as workforce” is fourteen steps of configuration.

Most users will keep typing prompts manually and stop there. That’s fine for casual use and bad at everything else. The 1% running real automation have Claude triaging issues at 7am, refreshing dashboards every hour, drafting Slack replies every 10 minutes - all while they sleep. They’ve set up the manual loop, promoted it to Desktop, promoted that to Routines.

Pick one step you weren’t doing - probably your first /loop in the terminal - and add it tomorrow. Then the next. The output of Claude follows the configuration of Claude. Configure it for autopilot, and that’s what you get.

9 out of 10 builders haven’t tried Dynamic Workflows even once, even though they shipped two weeks ago.

They write 50 prompts when one workflow would do. This is the 14-step roadmap and the 6 patterns Anthropic’s own engineers actually use - for migrations, research, sorting, root-cause, triage, and evals.

Dynamic Workflows shipped in Claude Code on May 28, 2026. The default Claude Code harness is built for coding - and that works well for most coding tasks. But there are classes of work where one context window starts to break down: long-running, massively parallel, highly structured, or adversarial.

For those, Anthropic used to build custom harnesses themselves (Research, Code Review, agent teams). With Dynamic Workflows, Claude writes that harness for you on the fly, custom-built for your task, in JavaScript.

14 steps. 6 patterns. One workflow instead of fifty prompts.

Part 1 · The Mental Model

01. A workflow is a harness Claude writes.

The default Claude Code harness has Claude plan and execute in the same context window. For most coding work, this is great. For long-running, parallel, or adversarial work, it breaks down.

A Dynamic Workflow is Claude writing its own custom harness for the task - a JavaScript file with a few special functions that spawn and coordinate subagents, plus standard JavaScript (Math, JSON, Array) to process the data flowing between them.

Three things this gives you that the default harness cannot:

• Per-agent isolation. Each subagent gets its own context window with one focused goal. No cross-contamination.

• Per-agent model choice. The workflow picks which model each subagent uses - Opus for hard reasoning, Haiku for cheap exploration, Sonnet for the middle.

• Per-agent isolation level. Worktree (isolated git checkout) or remote (no checkout). The workflow decides what each agent needs.

Start one by either asking Claude directly (“make a workflow that…”) or with the trigger word ultracode. If a workflow is interrupted - user action, terminal quit - resuming the session picks up where it left off.

02. The 3 failure modes workflows solve.

To know when a workflow is the right tool, you have to know what it fixes. The longer Claude works on a complex task in a single context window, the more it becomes susceptible to three specific failure modes - named directly in the Anthropic launch writing:

• Agentic laziness - Claude stops before finishing a complex, multi-part task and declares done after partial progress. Addresses 20 of the 50 items in a security review and calls the rest “handled.”

• Self-preferential bias - Claude prefers its own results when asked to verify or judge them against a rubric. A verifier with skin in the game can’t be a fair verifier.

• Goal drift - the gradual loss of fidelity to the original objective across many turns, especially after compaction. Each summarization step is lossy. “Don’t do X” constraints quietly disappear at turn 47.

A workflow solves all three structurally: separate Claudes with their own contexts, focused goals, and isolated state. If your task suffers from any of these patterns - that’s the signal to reach for a workflow.

03. Static vs Dynamic workflows.

You may have already built static workflows using the Claude Agent SDK or claude -p - coordinating multiple Claude Code instances together.

• Static workflows are generic: written once to handle every edge case. They work, but they have to be conservative.

• Dynamic Workflows are different: Claude writes this workflow for this task. The harness is tailor-made. Below is the same question handled both ways:

The reason the dynamic version wins isn’t the search step - both can search.

It’s that the workflow gets to shape itself around your context: read your billing code, check each feature against the actual new provider docs, price at your transaction volume, and run an adversarial “why not to migrate” pass against its own emerging answer.

A static harness can’t do this because it doesn’t know your code exists.

04. The core API. agent(), parallel(), pipeline().

Three functions do most of the work in a workflow. Knowing them is enough to read any workflow Claude writes for you and to nudge Claude when you want a specific shape.

parallel() is a barrier: it fans out, then waits for everything before returning. pipeline() is streaming: each item flows through every stage independently.

Pick by the question: do I need all results before I can do anything next? Yes → parallel. No → pipeline (cheaper, faster overall).

05. Classify-and-act. Route the work before doing it.

A classifier agent decides on the type of task, then the workflow routes to different agents or behaviors based on the answer. Or a classifier runs at the end, sorting raw outputs into buckets for whatever comes next.

When this pattern earns its keep:

• The task is heterogeneous - different sub-types need different treatment.

• You want to spend the expensive model only where complexity demands it (classifier on cheap, then route to Opus only when needed).

• The decomposition of work is itself non-trivial and benefits from a model deciding the shape.

Example: “Explain how the auth module works.” A classifier subagent reads the codebase first, estimates complexity, then routes the actual explanation task to Sonnet for a 10-file module or Opus for a 100-file one. The right model for the job, decided after the work is understood.

06. Fan-out-and-synthesize. Many small steps, one merged result.

Split a task into many smaller steps. Run an agent on each step in parallel. Synthesize the results into one answer.

The synthesize step is a barrier - it waits for every fan-out agent, then merges their structured outputs.

Why this pattern dominates in practice: it solves the “too many things at once” failure of single-context work. Each subagent sees only its piece. The orchestrator never gets distracted by 50 unrelated details.

Each step benefits from its own clean window so they don’t cross-contaminate.

Use this when:

• You have a clearly enumerable list of work items (50 files, 200 endpoints, 100 reviews).

• Each item is independent - no item needs another’s output to begin.

• You want a single consolidated answer at the end, not a pile of partial reports.

// Fan out: one agent per file. Barrier: wait for all.
const reviews = await parallel(
  files.map(file => () => agent(
    `Review ${file} for security issues`,
    { model: "haiku", schema: IssueList }
  ))
)

// Synthesize: one Opus agent merges everything.
const report = await agent(
  `Merge these reviews into one prioritized report:\n${JSON.stringify(reviews)}`,
  { model: "opus" }
)

07. Adversarial verification

This is the structural fix for self-preferential bias. For each spawned agent, run a separate spawned agent that adversarially verifies its output against a rubric. The verifier has never seen the original work; it can’t favor it.

The pattern matters most for:

• Claim-checking - every factual statement in a report gets its own verifier subagent, checking against the original source.

• Code review - the author agent writes the fix, the reviewer agent (separate context) reviews it. Never the same Claude judging itself.

• Quality gates - before any artifact ships, an adversary tries to find the weakest case against it. If the adversary can’t, you ship.

The pairing rule: the verifier should know only the rubric and the artifact, not who produced it. Otherwise self-preference creeps back in through hints in the prompt.

08. Generate-and-filter.

Generate a number of ideas on a topic, then filter them by a rubric or by verification. Dedupe duplicates. Return only the highest quality, tested ideas.

Where this pattern shines:

• Brainstorming - 30 product names, then a verifier kills clichés, trademark conflicts, and weak phonetics. You see 3.

• Hypothesis gene - 5 different approaches to a problem, then each gets scored against your constraints. The winner has earned it.

• Solution design - 5 different approaches to a problem, then each gets scored against your constraints. The winner has earned it.

The opposite of asking Claude for “the best answer.” Asking for the best answer makes Claude commit early. Generate-and-filter makes Claude commit late, after every option has been challenged.

09. Tournament. Pairwise comparison beats absolute scoring.

Instead of dividing the work, have agents compete on it. Spawn N agents that each attempt the same task using different approaches, then judge the results in pairwise fashion until one wins.

Comparative judgment is more reliable than absolute scoring - especially for taste-based work.

Why this beats sort-by-score: trying to sort 1,000 items in one prompt fails on two fronts - quality degrades, and it won’t fit in context. A tournament splits the bracket across fresh agents, each comparing just two items.

The bracket itself lives in deterministic loop code, not in context. Each comparison is fast, fair, and isolated. Same idea works for taste-based ranking: design choices, candidate selection, content prioritization.

10. Loop until done.

For tasks with an unknown amount of work, loop spawning agents until a stop condition is met - no new findings, no more errors in the logs, theory verified - instead of running a fixed number of passes.

This pattern is the answer to “keep going until it’s actually done”:

• Flaky test debugging - reproduce, form theories, test them, until one theory holds.

• Bug hunting - keep finding bugs until a full pass returns zero.

• Mining for patterns - cluster, identify rules, until no new clusters appear.

Pair this pattern with /goal to set a hard completion requirement (“don’t stop until one theory works”) and with /loop if you want the entire workflow itself to run on a recurring schedule.

The bracket and the stop condition live in code; only the active iteration stays in context.

11. Compose patterns for real use cases. One workflow, several patterns.

The 6 patterns rarely appear alone. A real workflow composes 2-4 of them. The matrix below pairs each use case from the Anthropic launch writing with the patterns it tends to use:

• Migrations and refactors. Fan-out (one agent per callsite/failing test in a worktree) → adversarial verification (a separate agent reviews each fix) → loop until done. This is the pattern Anthropic used to rewrite Bun from Zig to Rust.

• Deep research (the /deep-research skill). Fan-out (parallel web searches) → adversarial verification (each claim verified independently) → synthesize (one cited report).

• Deep verification of a draft. Identify all factual claims (one agent) → fan-out (one verifier per claim, each agent checks against source) → meta-verifier (checks the verifier’s sources are high quality).

• Sorting 1,000+ items. Tournament (steps 5-9) - pairwise comparison, bucket-rank, or bracket. Comparative judgment, never absolute scoring.

• Memory and rule adherence. Verifier per rule (fan-out) → skeptic persona reviews the rules themselves to avoid false positives.

• Root-cause investigation. Generate theories from disjoint evidence (different agents read logs, files, data) → panel of verifiers and refuters for each theory → loop until one survives.

• Triage at scale. Classify-and-act → dedupe against existing tickets → either attempt the fix or escalate. Pair with /loop for continuous triage.

• Exploration and taste (design, naming, UI choices). Generate-and-filter (5-20 options) → tournament with a rubric → rank or pick.

• Lightweight evals. Run the candidate in a worktree → comparison agents grade against rubric → refine and re-grade. Same shape as a tournament but for grading, not ranking.

The right way to internalize these: identify which failure mode your current task is failing under, then pick the pattern that structurally prevents it.

Drift → fan-out. Self-preference → adversarial verification. Open-ended → loop until done. Hard-to-score → tournament.

12. Pair with /goal, /loop, and token budgets.

Workflows can be expensive. Three controls turn them from “cool but costly” into “a tool I run unattended.”

• /goal sets a hard completion requirement. Pair it with the loop pattern: “don’t stop until one theory works.” Without /goal, a workflow stops at a soft completion point. With /goal, it iterates until the actual end condition is met.

• /loop runs the entire workflow on a recurring schedule. Use it for workflows you want running continuously - triage, weekly research updates, recurring verification.

• Explicit token budgets. Tell Claude in the prompt: “use 10k tokens.” This sets a cap on the workflow run. Without a cap, an ambitious workflow can balloon to 5–10× the tokens you expected.

> ultracode quick adversarial review of this assumption:
  "moving to Postgres eliminates our shard rebalancing."
  Use 5k tokens. /goal don’t stop until you have either
  a counterexample or three independent confirmations.

Quoting the Claude Code team directly: “Best practices are still developing. Dynamic workflows often use more tokens, so think carefully about when and how to use them.” Most traditional coding tasks do not need a panel of 5 reviewers.

Ask yourself: does this task really need more compute? If a regular Claude Code session would finish it in five minutes, you don’t need a workflow.

13. Use the quarantine pattern for untrusted input.

Any workflow that reads untrusted public content - support tickets, bug reports, user feedback, scraped data - needs to assume that content might contain prompt injection.

The fix: quarantine. Bar the agents that read the untrusted content from taking any high-privilege actions. Separate agents, with no exposure to the raw content, do the acting.

Any workflow that processes user-submitted content (support tickets, bug reports, customer feedback, social media), scrapes public web pages, or runs against output from a third-party API.

If the input wasn’t written by you or a trusted teammate, quarantine it. A 30-line read-only reader agent costs almost nothing and removes an entire class of prompt injection risk.

14. Save workflows. Ship them as Skills.

Once a workflow works, save it: press s in the workflow menu. Saved workflows go to ~/.claude/workflows. From there you have two paths:

• Keep it local - reuse it across your own projects.

• Ship it as a Skill - bundle the JavaScript file inside a Skill folder, reference it in SKILL.md, and anyone who installs the Skill runs the same workflow.

One practical nuance worth knowing: when you package a workflow into a Skill, prompt Claude to treat the workflow as a template, not a script to run verbatim.

That leaves room for Claude to adapt the workflow shape to the specific task at hand while keeping the overall structure intact. Especially useful for workflows like “deep verification” or “triage” that need to flex per use case.

The mistakes that waste tokens on workflows

• Reaching for a workflow when a regular Claude Code session would do. Most traditional coding tasks don’t need a panel of 5 reviewers.

• No token budget. Ambitious workflows balloon to 5–10× what you expected without an explicit cap.

• One agent doing both the work and the verification. Self-preferential bias makes the verifier favor the worker. They must be separate.

• Treating parallel() and pipeline() as interchangeable. The barrier matters - parallel waits for all, pipeline streams.

• Skipping /goal on loop patterns. The workflow stops early at the first soft completion point. /goal forces hard completion.

• Letting untrusted content reach the actor. Quarantine isn’t optional once you process anything user-submitted.

• Sorting with absolute scores. Comparative judgment is more reliable. Use a tournament.

• Never saving working workflows. Re-prompting the same shape every week. Save with s, ship as a Skill.

They don’t build Skills, don’t deploy to live URLs, don’t run automations while they sleep. This is the 14-step roadmap that takes you from blank folder to a working AI workflow in 30 minutes.

Codex is OpenAI’s agentic coding platform - not the deprecated 2021 code-completion API, the new one. It launched as a CLI in April 2025, grew into a desktop app, an IDE extension for VS Code/Cursor/Windsurf, and a cloud agent.

Sam Altman confirmed in April 2026 it had ~4 million weekly active users. It is now the closest direct competitor to Claude Code.

If you’ve used Claude Code, the mental model transfers in one sentence: a folder on your computer, a markdown configuration file, an agent that reads everything in the folder, plus an extension layer of Skills, MCP servers, automations, and a built-in browser.

Different harness. Different model. Same pattern.

14 steps. 3 tiers. One folder that runs your workflows.

PART 1 · The Setup

01. Project folder on your computer.

Codex doesn’t have its own database, its own file system, or its own “workspace.” A Codex project is a regular folder anywhere on your machine. When you start a new project, Codex opens a file picker.

You pick the folder. From that moment on, every file inside is fair game: read, write, edit, organize, move.

This single design choice changes everything downstream:

• Your project is portable. The same folder opens in Codex CLI, the Codex app, the IDE extension for VS Code/Cursor/Windsurf - or Claude Code, or Cursor. The harness changes; the work doesn’t.

• You version-control it like any code. Git, GitHub, Vercel - standard tools, no special integrations needed.

• You back it up, share it, and move it the same way you handle any other folder on disk.

By default Codex runs in Agent mode - it can read, edit, and run commands inside the working directory automatically. Anything outside the folder, and any network access, still requires your approval. The folder is the trust boundary.

02. Write an AGENTS.md. The onboarding doc Codex reads first.

This is the single most under-used file in Codex. AGENTS.md sits in the project root. Codex reads it every time you open a new chat in that folder.

It tells the agent who you are, what the project is, what the goal looks like, and what constraints matter.

The trick: don’t write it from scratch. Tell Codex the project goal in plain English. Ask it to draft an AGENTS.md. You get a structured file you then edit. Faster, more complete, less likely to miss something.

# Project: YouTube Comment Intelligence

## Context
I run a YouTube channel about AI tools. I want to understand
what viewers are asking, what they want to see, and what tools
they’re comparing — without reading every comment manually.

## Goal
Build a workflow that pulls recent comments, classifies them,
surfaces patterns, and visualizes the result on a live dashboard.

## Constraints
- Use the YouTube Data API v3 with an API key (not OAuth).
- Keep credentials in .env.local, never commit them.
- Output target: Excel workbook for analysis + web dashboard.
- Deploy dashboard to Vercel.
- Refresh data weekly via automation.

## Conventions
- Save failed approaches to project memory so we never retry them.
- Always confirm a plan before writing code.

What makes a good AGENTS.md:

• Context - one paragraph. Who you are and why this project exists. Saves you re-explaining yourself every session.

• Goal - one paragraph. The end state, not the steps. Steps belong in plan mode (step 3).

• Constraints - bullet list. Hard rules. API choices, languages to avoid, security boundaries, output formats. The shorter and more specific, the better.

• Conventions - bullet list. “Save lessons to memory.” “Always confirm a plan first.” “Never run X.” These compound into reliable behavior.

OpenAI’s own best-practices guide makes this explicit: “Codex works best when you treat it less like a one-off assistant and more like a teammate you configure and improve over time. Start with the right task context, use AGENTS.md for durable guidance, configure Codex to match your workflow.”

03. Start every build in Plan mode

Plan mode means Codex doesn’t execute anything. It brainstorms, asks clarifying questions, surfaces tradeoffs, and produces a numbered plan you approve before it writes code. Skipping plan mode is the single biggest reason builds go sideways.

The pattern that works:

• Describe the goal, not the steps. “Pull recent comments from my YouTube channel and turn them into an Excel report” - not “use Python to call the YouTube API and write to xlsx.”

• Let it ask questions. Codex in plan mode usually returns 3-5 clarifying questions. Answer them honestly. Each one is a future bug avoided.

• Approve the plan before it executes. Read the steps. If anything looks wrong — missing edge case, weird tool choice, unnecessary complexity — push back. Cheaper to fix in plan mode than after the code is written.

Plan mode pairs especially well with AGENTS.md: the constraints in your config file shape what plans Codex even proposes. The two together cut wrong approaches by an order of magnitude.

04. Set up .env.local for API keys.

Every API key, every secret, every credential goes into .env.local in your project root. The dot at the front of the filename is not decoration - it’s how Codex (and git) know to exclude the file from public commits.

Two rules that prevent painful mistakes:

• Never paste keys into a random secrets.txt or worse, directly into a chat message. Both end up in version control. Both become public the moment you push.

• Always test the key after adding it. Ask Codex to make a minimal API call to confirm the key works. Surface auth errors before they cost you a build.

If a key ever does end up in a commit. Rotate the key immediately at the provider (Google Cloud, OpenAI, etc.). Don’t just delete it from the file and push the deletion - the old commit still has the key, and bots scrape GitHub commits for leaked secrets within minutes. The only safe fix is rotating the credential.

PART 2 · Connect & Build

05. Connect MCP servers and plugins.

Codex speaks the Model Context Protocol (MCP) - the same open standard Claude Code uses. That means most existing MCP servers work in Codex too: GitHub, Slack, Notion, Linear, Drive, Figma, plus dozens of community-built ones.

What this unlocks: instead of describing your data to Codex, you let it read your data. Instead of describing actions for Codex to suggest, you let it perform them. The conversation shifts from “here’s what’s in my repo” to “create a PR with this fix and tag the owner.”

Three patterns that pay back fastest:

• GitHub MCP - read repos, create branches, open PRs, comment on issues. The single biggest day-one win for any dev.

• Vercel MCP - deploy, check status, roll back. Pair with GitHub for a complete “build → commit → deploy” loop.

• Notion or Drive MCP - pull internal docs as context, write decisions back to a central log. Codex stops being a black box, becomes part of the team’s memory.

06. When no plugin exists, ask Codex to set up the API

Not every service has an MCP server. YouTube Data API doesn’t. Internal company APIs don’t. Niche SaaS tools usually don’t.

When that happens, you don’t hunt for a third-party wrapper. You ask Codex. In plan mode, tell it the integration goal - “pull recent comments from my YouTube channel.”

It will return options (API key vs OAuth), recommend one, and produce a step-by-step plan to set up credentials, enable the relevant API, and test the connection.

The pattern that compounds over time:

• Try the first approach. Codex picks one based on tradeoffs. Let it.

• When something fails, save the lesson. “PowerShell hit a TLS error, Python worked. Save that to project memory so we never retry the broken path.” The next session inherits the knowledge.

• Lock the working pattern. Once an integration is solid, turn it into a Skill (step 9). You never repeat the setup.

This is the single most important habit in agentic work. Try, fail, save the failure, never fail the same way twice. Codex agents have short memory by default - what they learn this session is gone tomorrow unless you write it down.

Tell Codex to update AGENTS.md or project memory whenever something teaches it a real lesson. The system gets sharper every time you use it.

07. Build a real deliverable with specific prompts.

The point of any tool is the deliverable. For most users, the first one is something concrete - an Excel report, a script that automates something tedious, a dashboard, a generated document. The thing that proves the tool earns its keep.

The single rule that determines whether your first build is great or generic: specificity in the prompt. “Analyze my YouTube comments” produces an Excel sheet with categories like “positive,” “negative,” “neutral.” Useless. “Analyze my YouTube comments and classify them by: tool comparison, content request, technical question, general feedback - then rank by reply priority for me as a creator” produces a workbook you actually use.

Two patterns that lift output quality fast:

• State the role of the output - “for me as a creator,” “for a board update,” “for my engineering team.” The audience shapes the structure.

• Enumerate the categories or buckets you care about. Don’t leave classification to default judgment. Tell Codex your taxonomy.

If the first version is OK but not great, don’t throw it out. Add more specificity and re-run. Three rounds of iteration with sharper prompts beats starting over five times.

08. Use gpt-image-2 for concept art before building UI.

Codex has built-in image generation through gpt-image-2 - the OpenAI image model. Invoke it explicitly with $imagegen in your prompt, or just describe what you need and Codex will pick it up.

Generated images become project assets the rest of the build can reference.

The pattern that unlocks this: generate concept art before the UI code. Ask Codex to mock up the dashboard look in one or two images first. Save them to the project.

Then ask it to build the dashboard, referencing the concept art. The visual output comes out sharper than letting the model freestyle the design from a text spec.

09. Turn workflows into Skills

A Skill is a reusable recipe Codex loads on demand. Once you’ve built a workflow that works - pulling comments, generating a report, deploying a dashboard - you turn it into a Skill so the next run is one command.

Skills in Codex are markdown files in a folder. The directory has a SKILL.md file with frontmatter (name + description) and a body of instructions. Optionally include scripts and reference files alongside.

---
name: youtube-comment-insights
description: Pull recent YouTube comments via the Data API,
  classify them by content category and tool mentions,
  rank by reply priority, and output an Excel workbook
  with summary tabs and charts. Trigger whenever I ask
  for "comment insights" or "weekly youtube report."
---

# YouTube comment insights

## Setup
- Read YOUTUBE_API_KEY from .env.local.
- Fetch ~200 most recent comments across the last 10 videos.

## Classification
- Categories: tool comparison, content request, technical question,
  general feedback, off-topic.
- Tool mention tracking: Codex, Claude Code, Cursor, API, GPT, etc.
- Priority signal: questions > high-engagement comments > other.

## Output
- Workbook tabs: Summary, Categories, Tool Mentions,
  Priority Replies, Content Ideas, Raw.
- Charts on Summary tab: category mix, tool ranking.

Two storage levels worth knowing:

• Global Skills - stored at ~/.agents/skills/. Available in every Codex project on your machine.

• Project-level Skills - stored inside the project folder itself. Only available there. Useful for client-specific or project-specific recipes.

Three things that determine whether a Skill actually triggers when you need it:

• The description is everything. Codex matches your task against the description text alone for implicit invocation. Front-load the key use case and trigger words; vague descriptions never fire.

• Two ways to invoke. Explicit (/skills in CLI/IDE, or

  $skillname

  mention), or implicit (Codex picks the skill when your prompt matches the description).

• Open standard. Skills launched for Codex in December 2025 and are now part of the cross-platform Agent Skills standard - same format works in Codex, Claude Code, Gemini CLI, Cursor. Write once, run anywhere.

10. Deploy localhost to a live URL. GitHub → Vercel → production.

The Excel sheet was the backend. A dashboard is the frontend. Localhost is the development URL. None of these are shippable.

To go from localhost to live, you wire up two services: GitHub for the repo, Vercel for the host. Codex orchestrates the whole flow.

python

> Connect this project to GitHub. Create a private repo
  named "yt-comments-dashboard" and push the codebase.
▲ Codex  authenticating with gh CLI…
  - created github.com/you/yt-comments-dashboard (private)
  - initial commit pushed
✓ repo ready

> Connect Vercel to the same GitHub account.
  Import this repo. Deploy.
▲ Codex  connecting Vercel…
  - vercel project created
  - build succeeded in 38s
✓ live at https://yt-comments-dashboard.vercel.app

The killer detail: GitHub and Vercel keep talking to each other after the initial connect. Every push to main triggers an automatic Vercel deploy. You never log back into Vercel. You work in Codex, Codex pushes to GitHub, Vercel deploys. Three tools, one workflow.

11. Set up Automations - and explicitly set the model.

The Codex app has an Automations tab. Scheduled prompts that run on a cron. Combined with Skills, this is what turns a dashboard into “a thing that updates itself while you sleep.”

A real Sunday-evening automation: pull fresh comments, run the insights Skill, update the Excel file, push the new data, let Vercel auto-deploy. End-to-end refresh, untouched. By Monday morning the dashboard is current.

The model picker inside the Automations panel does NOT inherit from your active chat. A new automation defaults to whatever the panel default is, which may be slower and cheaper than what you actually want for production runs.

Set the model explicitly per automation, or you’ll wonder why a 7-minute job suddenly takes 40 minutes. Same problem if you have a file open locally that Codex needs to overwrite - close it first.

12. Pick the right thread mode - Local, Worktree, or Cloud.

Each thread in the Codex app runs in one of three modes. Picking the right one is the difference between safe iteration and rage-quitting after a bad merge.

• Local - works directly in your current project directory. Fastest, easiest, but every change touches the live working tree. Good for small, contained edits when you trust the agent.

• Worktree - isolates changes in a Git worktree (a sibling working directory tied to the same repo). The agent works in a separate branch with no risk to your main checkout. This is the default for any meaningful build. If the run goes wrong, throw the worktree away. Zero damage.

• Cloud - runs remotely in a configured cloud environment. Your laptop can be off. Pair this with Automations (step 11) for true async workflows that don’t depend on your machine being awake.

The rule of thumb: Worktree for ambitious work, Local for small surgical edits, Cloud for long-running automated runs. Three trust levels, picked per task.

13. Use built-in Browser Use as the QA loop.

After building a dashboard, ask Codex to open it in the built-in browser, click through, try to break it, and report back. It does.

It catches things you would have missed staring at the code - broken external links, empty states that look bare, search behavior that’s too literal, accessibility gaps, minor UI inconsistencies.

The pattern that turns this from a one-off into a habit: bake the QA pass into your project memory or Skill.

Every time you ship a new feature, the agent runs a browser pass before returning to you. You stop being the QA tester. The agent does it. You review the report.

Browser Use isn’t just for QA, though. It’s a general-purpose tool the moment an API doesn’t exist:

• Logging into tools without APIs - legacy admin panels, vendor portals, internal dashboards.

• Pulling reports from dashboards that don’t expose data programmatically- analytics views, billing tools, status pages.

• Automating multi-step UI workflows you’d otherwise click through by hand. Describe the steps in natural language; Codex performs them.

14. Use the UX features most people ignore.

The Codex app has a handful of UI features that turn it from “tool I use” into “workspace I live in.” They look minor in isolation. Together they compound.

• Side chat. Open a side thread off your main conversation. Same project context, different conversation. Ask a quick question without polluting the main session. Close it when done.

• Slash commands. Type / to browse: /skills to invoke a Skill explicitly, /clear, /help, and more. Slash menus surface everything Codex can do.
  
  

• @-mentions. Tag a specific file in your prompt: “Use @example .tsx as a reference to add a new page that lists items from @resources.ts.” Way cleaner than pasting paths.

• Model switcher + reasoning effort. The switcher under the chat input swaps models per conversation. Reasoning effort controls how long Codex thinks before responding. Higher effort = better on complex tasks, more tokens, faster rate-limit drain. Match effort to task.

• $imagegen + Skills mentions. Type $ to mention a skill inline. Same syntax as @ for files. Lets you compose multiple skills in one prompt.

• Auto-context sync with IDE Extension. If Codex IDE Extension is installed in your editor, the app and editor automatically sync when both are in the same project. You see threads running in the app inside the editor, and vice versa. Toggle “Auto context” to have Codex track files you’re viewing.

• Full access mode. Settings → toggle to skip approval prompts. Faster, riskier. Start on default. Switch to full access only once you trust the project boundaries.

The habits that keep Codex at 3% of its potential

• No AGENTS.md. Re-explaining the project every session, getting different answers every session.

• Skipping plan mode. Forty-file diffs to fix a one-sentence misunderstanding.

• Keys in chat or in secrets.txt. Public the moment you push.

• Never saving lessons to memory. Failing the same way over and over because nothing got written down.

• Vague prompts. Generic deliverables and surprise that the output is generic.

• One-off builds. Rebuilding the same workflow from scratch every week instead of turning it into a Skill.

• Local mode for everything. A bad agent run wipes your working tree because you didn’t use a worktree.

• Letting Automations default the model. 40-minute runs that should take 7.

• No QA pass. Shipping dashboards with broken external links and empty states that look bare.

• Tool tribalism. Picking Codex vs Claude Code based on identity, not the job in front of you. Both win, depending.

Conclusion:

Codex looks like a chat window. It is not a chat window. It is a folder with an agent that knows what’s in it - plus a layer of Skills, MCP, automations, and a browser, all configured through markdown files that live in the folder itself.

That folder is portable. Open it in Codex, Claude Code, Cursor, or any tool that speaks the Agent Skills standard. The harness changes. The work doesn’t.

Most users will keep typing questions into the chat and stop there. They’ll get answers, copy code, and move on. The 4 million weekly active users shipping with Codex are the ones who configured the folder.

Pick one step you weren’t doing - probably AGENTS.md, or your first real Skill - and add it tomorrow. Then the next. The output of Codex follows the configuration of Codex.

Empty folder. Workflow engine. 14 steps between them.

They don’t set up Projects, don’t build Skills, don’t connect MCPs, don’t run agents. This is the 14-step roadmap that turns that 3-feature habit into a workflow engine that replaces 10 apps and a browser.

Claude is not a chatbot. It is a chatbot, plus a project workspace, plus a memory system, plus a custom-skill engine, plus a browser of connectors to your other tools, plus a coding agent, plus a cloud scheduler, plus a voice interface, plus add-ins for Excel and PowerPoint and Chrome.

The chat window is the surface. Everything good lives one layer down.

The 14 steps below are the layer-down. Each one is a real Claude feature that exists in May 2026 - built from Anthropic’s own support docs, official launches, and what teams shipping real work with Claude actually use.

Three tiers: get your basic setup right, unlock the hidden layer, run Claude as a workflow engine.

14 steps. 3 tiers. One workflow engine.

PART 1 · The Setup

01. Use Projects, not one endless chat.

The single biggest mistake: cramming every conversation into one growing chat history. Claude has Projects - self-contained workspaces with their own chat history, instructions, and knowledge base. Free users get five. Paid users get unlimited.

• Create one at

  claude.ai

  → Projects → New Project.

The rule for what deserves its own Project: if the work has its own files, its own tone, or its own deadline, it gets its own workspace. Client X, product launch Y, personal finance, code refactor, side project - each one separated.

Mixing your startup pitch and your finance tracker into the same Project pollutes the context for both.

The rule of thumb: if the work has its own files, its own tone, or its own deadline, it deserves its own Project. Don’t mix your startup pitch and your finance tracker into the same workspace. The whole point is to keep Claude focused on one topic at a time.

Three Project patterns that work in practice:

• By client - one Project per active client. Brand voice, deliverables history, ongoing chats all stay together. Switching clients = switching Projects.

• By repeated task - one for weekly reports, one for blog drafts, one for sales emails. Each holds the format rules and reference examples for that one task.

• By codebase — one per repo. Upload your README, architecture doc, and conventions. Every code question loads with that context.

The two mistakes to avoid: creating a Project then never using its instructions (you got the workspace, not the value), and creating one mega-Project called “Work” (defeats the purpose).

Aim for 3-7 active Projects, archive the rest. Claude does not read the Project name - only the instructions and knowledge.

02. Set Project instructions.

Every Project lets you set instructions that load automatically at the start of every chat inside it. Your role, your tone preferences, your output format, your banned phrases. Write them once. Every conversation in that Project starts pre-tuned.

“Be helpful and professional” is not an instruction. It is a wish. Use this structure instead:

# Role
I'm the marketing lead at a B2B SaaS for engineering teams.

# Preferences
- Write in a direct, professional tone. No corporate speak.
- Default to ~1,200 words. H2 and H3 only.
- Use Oxford commas. Avoid em-dashes.
- Banned: leverage, synergy, best-in-class, robust, seamless.

# Standards
- Customer-facing copy: confident but not arrogant.
- Technical content: cite primary sources, never blog rehashes.
- Always close with one specific action the reader should take.

If Claude makes the same mistake twice across a Project, the fix is to update the instructions, not correct it again in the next chat. Treat the instructions file like your coworker’s onboarding doc - the more specific, the less you repeat yourself later.

03. Upload Project knowledge.

Below the instructions sits the knowledge base. Click +, drop in PDFs, Word docs, spreadsheets, code, plain text. Whatever you upload is available to every chat inside that Project - without re-attaching. Brand style guide, product spec, codebase, last quarter’s sales numbers. Once.

What works well in the knowledge base:

• Reference docs that rarely change - brand guides, API specs, SOPs, glossaries. Claude can cite them across every chat without you reminding it.

• Examples of good output - 3-5 pieces of work you’d be happy to ship again. Claude pattern-matches against examples far better than it interprets adjectives.

• Decisions log - a single “decisions.md” that records what you’ve agreed in past chats and why. Memory only stores a profile (step 7); this is your durable decision history.

What ruins a knowledge base:

• Bloated dumps. Uploading dozens of loosely related files dilutes retrieval. A focused 5-10 file base outperforms a 50-file pile every time.

• Stale content. Outdated docs produce misleading context. Set a calendar reminder to review monthly - remove what’s no longer accurate.

• Confidential data. Real PII, financial account numbers, legally privileged content. Review Anthropic’s data terms before uploading anything sensitive.

The token limit: Projects share a 200K-token context window with the conversation. A bloated knowledge base eats into the space Claude needs for your actual chat. Free users hit it first.

For very large reference docs where only one section matters per query, don’t upload the whole thing.

04. Use Artifacts for everything reusable

Whenever Claude produces something you’ll use outside the chat - a doc, code, chart, landing page, SVG diagram, slide outline - ask it to put the output in an Artifact.

Artifacts open in a side panel next to the chat. You edit them in place, version them, share them as standalone pages, run them if they’re code or React.

The mental shift: chat answers are conversational, Artifacts are deliverables. If you’d copy-paste it into another tool, it should be an Artifact.

What Artifacts handle well, today:

• Documents - long-form writing in markdown, rendered with headings and formatting. Edit in the side panel, ask Claude to revise specific paragraphs.

• Code - full files in any language, with syntax highlighting. Modify with iterative prompts (“change the auth to use JWT”) instead of re-pasting.

• HTML pages - complete pages with embedded CSS and JS, rendered live. Great for landing-page prototypes and one-pagers.

• React components - functional components rendered inline. You can build interactive calculators, dashboards, mini-apps without leaving the chat.

• SVG and Mermaid diagrams - charts, flowcharts, architecture diagrams. Edit by asking, not by hand-drawing.

Artifacts have a Publish button. Hit it and you get a public URL you can share with anyone - no login required to view. Used for: sharing a draft with a client, publishing an interactive demo, sending a one-page report to a non-Claude user.

The Artifact becomes a real link you can drop in Slack or email. This is the cheapest way to turn Claude output into shareable work, no separate hosting needed.

PART 2 · The Hidden Layer

05. Build custom Skills. Reusable workflows in one file.

A Skill is a reusable instruction file Claude loads on demand - only when the task matches its description.

Project instructions apply to every chat in one Project. A Skill applies wherever Claude detects the relevant task, across all contexts. Write the workflow once. Claude executes it consistently after that.

Skills are filesystem-based: a folder with a SKILL.md file inside. The frontmatter tells Claude when to use it. The body is your workflow.

---
name: weekly-report
description: Turn raw notes from the week into a structured
  weekly report. Use whenever I share notes and ask
  for a "weekly update" or "weekly report."
---

# Weekly report format

## 1. Wins (3 bullets max)
- One concrete shipped thing per bullet
- Include the metric that moved if any

## 2. Lessons (2 bullets max)
- Honest, not sanitized
- What I'd do differently next time

## 3. Next week priorities (3 max)
- One sentence each, with the outcome that defines "done"

## Tone
Direct, no hedging. Cut everything that does not earn its place.

Three things that matter for Skills to actually trigger:

• The description is everything. Claude decides whether to load a Skill based on the description alone. Vague descriptions never fire. Specific descriptions with concrete trigger phrases (“use whenever I ask for X”) fire reliably.

• One Skill, one job. A Skill that tries to do five tasks fails at all of them because the description has to be too broad. Split big workflows into focused Skills that compose.

• Just-in-time loading. A Skill costs ~100 tokens when dormant (just the description) and ~5K tokens when loaded. You can install dozens without paying context until they fire.

Anthropic ships pre-built Skills for common formats - PowerPoint, Excel, Word, PDF. You can build your own through the Skill Creator (interactive Q&A inside Claude Code) or just write the markdown file directly.

The marketplace at /plugin marketplace in Claude Code has thousands more, community and official.

06. Connect Gmail, Calendar, Drive, Notion

Claude has connectors - pre-built bridges to the apps where your real work lives. Google Workspace (Gmail, Calendar, Drive) is available to all users on

Claude.ai

and Desktop. Notion, Slack, Linear, GitHub, HubSpot, and dozens more available too. Settings → Connectors → Add. One-time OAuth, then live data and live actions.

The shift this enables: from chat about your tools to chat through your tools.

• Before: “Here’s an email I got, what should I reply?”

• After: “Find the three follow-ups I owe today, draft replies in my voice, queue them in Gmail for review.” Claude reads, drafts, queues. You review and click send.

The connectors that pay back fastest, in order:

• Gmail. Inbox triage, drafts queued for your approval, search across years of email. Biggest single time-saver for most people.

• Calendar. “What’s on my calendar tomorrow, prepare briefing notes for each meeting.” Especially useful with Gmail also connected so it pulls context from related threads.

• Drive / Notion. Search your whole workspace by content. “What did we agree with Acme Corp last week” pulls the meeting note even if you forgot the file name.

• Slack. Catch up on channels, summarize threads, draft replies. Read-only mode is enough to recover hours per week.

07. Turn on Memory and chat search.

Two separate features, both free since March 2026.

• Memory = automatic profile. Claude builds a summary of stable facts about you - role, recurring topics, durable preferences - and applies them across future chats without you re-explaining.

• Search and reference chats = on-demand recall. You say “what did we decide about X last week?” and Claude pulls specific snippets from past conversations with citations linking back to the original chat.

Enable both at Settings → Capabilities. Toggle “Generate memory from chat history” and “Search and reference chats.” Once on, you stop telling Claude every session what you do for a living, what stack you use, what client you’re working with.

Three controls worth knowing:

• Pin facts manually. Say “remember that I prefer Python over Ruby for backend work” and Claude adds it explicitly. Survives across sessions.

• Incognito chats - ghost icon in the chat list. Conversations there are not stored, not searchable, not used to build memory. Useful for one-off sensitive questions.

• Delete on demand. Memory → review → remove anything that’s wrong or stale. The deleted facts won’t resurface.

08. Use Styles for consistent tone.

Three pre-built tones come standard: Formal, Concise, Explanatory. Useful, but the real power is custom Styles. Create a custom Style by either describing your voice in plain language, or - the better path - uploading 3-5 samples of your own writing.

Claude analyzes rhythm, sentence length, openings, closings, signature phrases, and produces a Style that mimics you.

Then in any chat, pick the Style from the dropdown and Claude writes in that voice.

One profile per use case: client emails, blog posts, internal Slack notes, technical docs. The output stops sounding like AI - it sounds like you on a good day.

The right way to set up a Style that actually works:

• Mix the sample types. A long-form post, a short note, an email. One genre alone produces a one-genre Style that fails on others.

• Use your best work. Quality > quantity. One piece you’d be proud to publish today beats five mediocre ones from 2022.

• Add explicit rules to the description. “Average 12 words per sentence. Never use ‘collaboration,’ ‘robust,’ ‘innovative.’ Use contractions. Open with the point, not the setup.” Examples train pattern; rules enforce boundaries.

• Iterate after first use. Generate three pieces in the new Style, mark what feels off, add “don’t do X” rules. By round three it’s usually right.

Where Styles still miss: contextual instinct (you know when to be more formal mid-email; Styles apply rules uniformly), signature phrases tied to specific people, and humor with specific references. Voice matching is iterative - don’t expect perfection on the first attempt.

09. Use voice mode and Quick Entry.

Two voice features that serve different purposes.

Voice mode (beta, available to all plans) is a full spoken conversation: speak naturally, hear Claude respond, switch back to text mid-chat without losing context. Five voices to choose from (Buttery, Airy, Mellow, Glassy, Rounded). Free users get ~20-30 voice conversations per day. Best for thinking out loud, walking while problem-solving, hands-busy moments.

Quick Entry on Claude Desktop for Mac is the everyday workhorse. Double-tap Option to open Claude from anywhere on your machine. Press

Caps Lock to dictate into the input with real-time transcription. You speak about 3× faster than you type - longer prompts at the same time cost, and longer prompts consistently produce better output. Free speed.

When to reach for which:

• Quick Entry / dictation - you know what you want to say, you just type slowly. Best for drafting prompts, dictating long context. Output stays as text.

• Voice mode - you don’t know what you want yet, you’re thinking. Best for brainstorming, exploring an idea, talking through a decision. You’ll get a transcript automatically saved.

Voice doesn’t just save typing time. It makes you willing to write longer prompts, which is where output quality jumps. A 300-word prompt that takes 6 minutes to type takes 90 seconds to dictate - so you actually include all the context Claude needs.

Most prompt failure is missing context, not bad model. Dictate the full thing, get the better answer. Compounding effect for anyone who works with Claude daily.

10. Use Claude in Chrome, Excel, PowerPoint, Word, Outlook

You don’t have to go to Claude. Claude comes to you. Three surfaces matter:

Claude for Chrome (beta, all paid plans). Browser extension that can navigate, click buttons, fill forms on any site. Tell it: “summarize the 15 emails I haven’t read,” “book a hotel within these dates,” “extract the data table from this page into a spreadsheet.” It does the work in the active tab.

Anthropic continues expanding site-specific support - Gmail, Calendar, Docs, GitHub all have richer awareness than generic sites.

Microsoft 365 add-ins. Install from AppSource: Excel, PowerPoint, Word, Outlook. Available to Pro and above. Since March 2026 they share a single AI context, so a conversation that started in Excel keeps going when you switch to PowerPoint.

Claude reads cells with citations, edits decks respecting your template (master slides preserved), drafts in Word as tracked changes you accept or reject, drafts Outlook replies inline.

What each one is actually good for:

• Excel - financial modeling, formula explanation, data cleaning, pivot building. Reads dependencies between cells, modifies without breaking your model.

• PowerPoint - turn a URL or PDF into a deck that matches your template, generate speaker notes, translate full decks, restyle to brand.

• Word - tracked changes for review, structural edits, citation insertion. The redline workflow without leaving the doc.

• Outlook - reply drafts, thread summaries, inbox triage. Same patterns as Gmail connector, but in-place.

• Chrome - navigation tasks, form filling, web research, scraping structured data. Pair with Cowork (step 14) to turn research into finished deliverables.

11. Use Claude Code for real work in your terminal.

Beyond the chat window lives Claude Code - a terminal-native agent that reads your files, writes code, runs tests, installs packages, deploys, and orchestrates sub-agents in parallel.

It is the version of Claude that finishes work, not the version that explains how to finish it.

The starter command is one line:

$ claude
▲ Claude  starting session in /your/project…
  no CLAUDE.md detected

> /init
✓ wrote CLAUDE.md (architecture map, conventions)

> Add JWT auth to all unprotected /api endpoints. Plan first.
▲ entering plan mode…

Five habits that turn Claude Code from “cool demo” into “daily driver”:

• Always /init in a new project. Generates a CLAUDE.md that maps your architecture and conventions. Every future session loads it automatically - no re-explaining your codebase.

• Plan mode before code. Press Shift+Tab twice to enter plan mode. Claude outlines what it’ll do before touching anything. Catches wrong assumptions in one sentence instead of forty-file diffs.

• Match the model to the task. /model opus for architecture and hard debugging. /model sonnet for daily building. /model haiku for cheap exploration. One model for everything wastes capability or money.

• Set permissions. Use /permissions to explicitly allow safe commands and deny destructive ones. Skip --dangerously-skip-permissions — that’s how rm -rf ends up running in the wrong directory.

• Use Skills for repeated workflows. Drop a SKILL.md in .claude/skills/ and Claude loads it when the description matches. Build once, use forever.

Claude Code is what turns Claude from “assistant who explains” into “coworker who builds.” Pair it with MCP connectors (step 6) and Routines (step 13), and you have an agent with know-how, access, and cloud automation - what most people are imagining when they say “AI agent.”

12. Generate visuals with Artifacts. SVG, HTML, React, inline.

Most people don’t realize Claude can build visuals directly - not describe them, build them. Ask for a diagram, it generates an SVG that renders in the Artifact side panel. Ask for an interactive calculator, it writes a React component that runs inline. Ask for a landing page, it produces working HTML with Tailwind styles.

What used to take three tools - Figma for the mockup, Canva for the chart, a code playground for the prototype - happens in one chat. The Artifact is editable: ask Claude to change colors, swap data, restructure, and the canvas updates. Export when done.

Specific visual jobs Claude handles well:

• Diagrams. Flowcharts, architecture diagrams, mind maps, sequence diagrams. SVG output that scales cleanly and exports to any vector tool.

• Charts. Bar, line, scatter, area, donut. Pass real data, get a Recharts component you can drop into a React app or screenshot for a slide.

• Landing pages. Full HTML with embedded CSS and JS. Hero, features, pricing, CTA — rendered live in the panel. Publish button gives you a real shareable URL.

• Interactive widgets. Calculators, simulators, configurators, dashboards. React components with state, inputs, real-time updates.

• Slide outlines as visuals. SVG mockups of each slide before generating the actual PPTX through the Skill (or the PowerPoint add-in from step 10).

The trick that unlocks this for most people: specify the format explicitly. “Build me an SVG diagram of X” produces a diagram. “Build me an interactive React calculator for Y” produces a working app. Generic “visualize Z” often produces text.

Tell Claude what kind of visual deliverable you want; it knows what to do from there.

13. Schedule Routines.

Released April 14, 2026. Routines are saved Claude Code configurations - a prompt, repositories, connectors - that run on Anthropic’s cloud infrastructure on a trigger: a fixed schedule, an API call, or a GitHub event. Your laptop can be off. The run still happens.

Available on all paid plans (Pro, Max, Team, Enterprise) in research preview. Configure at

claude.ai/code/routines

or with /schedule inside Claude Code. 15 runs per day on Pro, more on higher tiers.

Three real use cases that pay for themselves fast:

• Morning briefing - every weekday at 7am, pull yesterday’s metrics, summarize new GitHub issues, post a digest to Slack. By the time you open your laptop, the daily situation is already written down.

• Inbox triage - every hour during business hours, scan Gmail for emails marked as needing reply, draft responses in your Style, queue them in Gmail for your review. Inbox zero becomes a queue you approve, not a list you process.

• PR review - on every GitHub PR open event, run a code review pass, flag security and style issues, leave comments. PRs arrive at human review pre-cleaned.

Three triggers each route to different patterns:

• Schedule - cron-style cadence. Daily summaries, weekly reports, hourly polling. The most common type.

• API - HTTP endpoint with a bearer token. POST to it from your tools, alerting systems, deploy pipelines. Pass one-shot context that appends to the routine’s configured prompt.

• GitHub event - fires on PR open, issue create, push. Per-account hourly caps during preview, filter events for noisy repos.

Security boundary worth knowing: by default, Routines can only push to branches prefixed claude/. A poorly written routine cannot directly touch main. Disable this only if you have downstream review process you actually trust.

14. Use the API and Cowork for custom workflows.

Everything above lives in Anthropic’s interfaces. The last step is bringing Claude into your own.

The Claude API is a few HTTP calls away - same models, your own UI, your own data flow. Sign up at

console.anthropic.com

, get a key, hit /v1/messages. For most use cases it’s 20 lines of code. Use it when:

• You’re building a product that needs Claude inside it (chatbot, agent, content generator)

• You need batch processing of thousands of items (50% cheaper via the Batch API)

• You want to embed Claude in an internal tool, Slack bot, or workflow that doesn’t fit any Anthropic surface

• You need fine-grained control over system prompts, tools, or streaming output

If you’re a non-developer who wants async, multi-tool work without writing code, Cowork is the desktop product to install. It uses the same MCP connectors as the chat, runs scheduled tasks locally, and turns plain-language briefs into multi-step work. Examples Cowork handles well:

• “Every Monday morning, pull our top 10 priorities from Notion, our open invoices from Gmail, and our schedule for the week. Compose a one-page status doc.”

• “Take this client brief, build a discovery deck in PowerPoint matching our template, draft the kick-off email in Outlook for review.”

• “Monitor

  #support

  in Slack, draft replies for anything tagged ‘urgent,’ queue them for me before 9am.”

The combo is the ceiling: connectors as input, Claude as engine, Routines or Cowork as orchestration, API or extensions as the surface. That’s the workflow engine the article’s subtitle promised - not theory, not a future product, available today.

§ The habits that keep Claude at 5% of its potential

• One endless chat for everything. No Projects, no separation, no context that persists where you need it.

• Vague instructions like “be helpful.” Wishes are not configuration. Be specific or stay generic.

• Pasting files into the chat instead of uploading. Re-pasting the same brand guide every session is the AI equivalent of yelling.

• Asking for chat answers instead of Artifacts. Copy-pasting deliverables out of chat is busywork Claude already eliminated.

• Never building a Skill. Re-explaining the same workflow every Tuesday for a year.

• No connectors. Reading you the contents of an email instead of letting Claude read the actual email.

• Memory off. Starting from zero every session.

• Default tone. Output that sounds like generic AI because you never told Claude how you sound.

• Typing everything. Wasting the 3× speed of voice on bad prompts you never had time to write properly.

• Never installing Chrome or Excel add-ins. Switching between apps when Claude could be in the app with you.

• No Routines. Babysitting tasks Claude could run on its own while you sleep.

Conclusion:

Everything in this roadmap is one menu, one toggle, one file, or one extension away. None of it requires writing code, paying extra, or learning a new product.

The chat window is the surface of Claude. Projects are the workspace. Skills are the muscle memory. Connectors are the senses. Voice is the input. Artifacts are the output. Code, Chrome, Excel, PowerPoint are the surfaces. Routines and the API are the cloud underneath the whole thing.

Most users will keep using the chat window and stop there. That is fine for chat questions and bad at everything else. The gap between “Claude is a smart Google” and “Claude is the workflow engine that replaces your stack” is exactly these 14 steps.

Pick one step you weren’t doing - probably Projects or connectors - and add it tomorrow. Then the next. The output of Claude follows the configuration of Claude.

The agents don’t share context, don’t divide work, don’t know what the others are doing. This is the 9-stage roadmap that turns that mess into a crew that actually coordinates.

An AI agent team sounds simple: a few agents, each with a job, working together on something one agent could not finish alone. In practice, the moment you try it, you discover the problems no demo ever shows.

What works is structure. The 9 stages below are the structure - built from Anthropic’s own engineering writing on the Claude Agent SDK, the patterns in their multi-agent research blueprint, and what teams shipping real agent systems in 2026 do differently from the ones still stuck in demo mode.

Three tiers: get one agent right, get them coordinating, get the whole crew production-ready.

9 stages. 3 tiers. One crew that finishes work while you sleep.

Part 1 · The Single Agent

01. Define the agent loop

The most common mistake before stage one even begins: confusing a smart chatbot with an agent. A chat is a turn.

An agent is a loop - the model receives a goal, picks an action, runs it, observes the result, and decides what to do next. It keeps going until the goal is done or the loop hits a stop condition.

Everything else in this article assumes you have a real loop in code. Pseudo-code makes the shape obvious:

Notice what is in there: an approval gate, a logging hook, and a clear stop condition. If your “agent” is one big prompt that asks the model to do everything in one shot, you do not have an agent - you have a long completion. Everything later in this article needs a real loop to build on.

Pro tip: The stop condition matters more than people think. A loop with no clear end will burn money. Common stop conditions: goal achieved, max iterations reached (typically 30–50), explicit user halt, error threshold exceeded. Always set max_iterations. A runaway agent is worse than a slow one.

02. Engineer the context. Write, Select, Compress, Isolate.

Context is the most expensive and most fragile part of an agent. Most agent failures - the ones that look like “the model is dumb” - are actually context failures: the model never had what it needed, or it had too much and got distracted, or what it had was stale.

The four operations that matter, from Anthropic’s own engineering writing:

• Write - what gets added to context at each step. Be deliberate. Every line costs tokens and attention.

• Select - what to pull from memory or files. Retrieval, not dumping.

• Compress - when context fills up, summarize older parts while keeping decisions intact.

• Isolate -subagents work in their own context window so the main thread stays clean.

03. Write tools the model picks correctly

Without typed tool schemas the model improvises message formats, argument structures, and permissions for every call.

That improvisation is where most production failures come from. Not because the model cannot call the tool, but because it guesses the wrong format, sends the wrong arguments, or does something it should not have permission to do.

A typed schema converts the task from “guess how to call this” into “fill in these fields.” And it lets the harness enforce rules the model cannot bypass:

The fields beyond basic types are what make it production-grade: preconditions are what must be true before the call runs. side_effects tell downstream readers what will happen. requires_approval routes the call to a human checkpoint. blocked_targets are hard constraints the harness enforces no matter what the model decides.

Part 2 · The Coordination Layer

04. Spawn subagents with isolated context.

A subagent is not a copy of the main agent. It is a specialist with its own context, its own toolset, and often its own model. When the orchestrator decides “this part is research,” it spawns a research subagent - gives it only the relevant goal, lets it use only the relevant tools, runs it on a cheaper model like Haiku, and waits for a summary back. The main thread never sees the raw research.

In the Claude Agent SDK this is the Task tool. In code, the call looks like this:

> spawn_subagent(
    role="research",
    model="claude-haiku-4-5",
    goal="find every API endpoint in src/ that lacks auth",
    tools=["grep", "read_file"],
    return_format="summary + file list"
  )

▲ subagent_a  starting in isolated context…
  - scanning 142 files
  - 11 endpoints flagged
✓ done · returned 1.2K-token summary, full transcript not loaded into parent

The subagent’s return_format field matters more than any prompt. If you let subagents return free-form text, the orchestrator drowns.

Force structured returns - a summary string plus a list of facts, a list of files, a list of findings. The orchestrator then composes those structured returns into the next decision without reading the noise.

05. Design the orchestrator. Plans, delegates, never executes.

The orchestrator is the agent at the top of the tree. Its only job is to plan, delegate, and gather. It does not write code, run queries, or talk to APIs directly — if it does, it pollutes its own context with details that belong inside subagents. The orchestrator stays light so it can keep the whole task in view.

A working orchestrator has three loops nested inside the main agent loop:

def orchestrator_loop(goal):
    plan = make_plan(goal)                  # step 1: PLAN
    results = []

    for step in plan:
        subagent = pick_specialist(step)    # step 2: DELEGATE
        result   = run_subagent(subagent, step)
        results.append(result)

        if plan_needs_revision(result):
            plan = revise_plan(plan, result) # adapt mid-run

    return synthesize(results)             # step 3: GATHER

The orchestrator is usually the most capable model (Opus, in 2026). The subagents under it are often Sonnet or Haiku.

This is where the cost math works: the expensive model runs the plan, the cheap models run the work. A crew on this pattern can run 5–10x the tasks of a single-Opus setup at lower total cost.

06. Build a shared task list.

Without shared state, your “team” is parallel solo work. Two subagents start on the same step. One finishes a step nobody knows about. The orchestrator forgets what was assigned to whom. The fix is a single shared task list that every agent reads from and writes to - not as a creative document, but as a structured file.

{
  "goal": "Add auth to all unprotected endpoints",
  "tasks": [
    {
      "id": "t1",
      "description": "Find unprotected endpoints",
      "status": "done",
      "assignee": "subagent_a",
      "result": "11 endpoints in src/routes/*.ts"
    },
    {
      "id": "t2",
      "description": "Add JWT middleware to each",
      "status": "in_progress",
      "assignee": "subagent_b",
      "depends_on": ["t1"]
    },
    {
      "id": "t3",
      "description": "Write integration tests",
      "status": "pending",
      "assignee": null,
      "depends_on": ["t2"]
    }
  ]
}

Three things make this work that pure memory does not: explicit assignees mean two agents never pick the same task.

Explicit dependencies stop subagents from running steps whose inputs are not ready. Explicit status lets the orchestrator check progress without reasoning over transcripts.

Part 3 · The Production Crew

07. Add memory, durability, and sandboxing.

A demo agent forgets the moment the session ends. A production crew remembers what it should and forgets what it should. The three things to wire in, in order:

• Memory - a structured store the agent writes to deliberately. Not the conversation log; that is too noisy. A separate file or DB row per fact, decision, or convention worth keeping. memory/decisions.md, memory/conventions.md, memory/known_failures.md. The next session loads these explicitly.

• Durability - every step writes its action and result to disk before moving on. If the process crashes mid-loop, the next start reads the trajectory and resumes. Without this, a 50-step task that fails at step 47 starts from zero. This is the single most ignored detail in agent engineering.

• Sandboxing - agents run in a container or restricted subprocess with no access to anything not explicitly granted. No reading your home directory because someone’s prompt drifted. No writing outside the project folder. The sandbox is the wall between “agent that helps you” and “agent that costs you something.”

  # Decisions log
  
  ## 2026-05-22
  - chose JWT over session cookies (mobile clients drive this)
  - auth lives in src/auth/, never duplicated per route
  - all endpoints under /api/admin require role check, not just login
  
  ## 2026-05-29
  - adopted shared task list pattern (state/tasks.json)
  - orchestrator on Opus, subagents on Sonnet/Haiku
  - max_iterations = 30 per loop, hard cap enforced by harness

  ---

08. Wire evals and trajectory checks.

Most teams change their agent system and have no idea whether the change helped or hurt. They run it twice on a familiar task, it “feels better,” and they ship. Six weeks later they have a system that performs worse than the original on cases they forgot to check. Evals fix this.

Three layers of measurement that a production crew needs:

• Eval set - 20–100 frozen tasks with known good outputs. Run them after every meaningful change. Track pass rate over time.

• Trajectory checks - not just “did it finish,” but “did it call the right tools in roughly the right order.” A correct answer through a wrong path is a future regression.

• CI regression gates - the eval set runs automatically on PRs. If pass rate drops below a threshold, the PR is blocked. Same discipline as code tests.

{
  "id": "auth_refactor_001",
  "input": "Add JWT auth to all unprotected /api/* endpoints",
  "expected": {
    "endpoints_protected": 11,
    "files_touched": ["src/auth/jwt.ts", "src/routes/*.ts"],
    "tests_added": "at least one per endpoint",
    "no_changes_to": ["src/db/", "src/email/"]
  },
  "trajectory_must_include": [
    "grep_for_unprotected_endpoints",
    "read_existing_auth_module",
    "apply_middleware_to_each_endpoint",
    "run_tests"
  ],
  "max_iterations": 30
}

The trajectory_must_include list is the secret weapon. Two agents can produce the same answer through wildly different paths - one safe, one one bad approval away from disaster.

Trajectory checks catch the unsafe path before it ships. Pair this with anonymous logging of real production runs and you build the eval set automatically from cases that already happened.

09. Ship with permissions and human checkpoints.

The last stage is the one that lets you sleep at night. A permissions file declares what the crew can do without asking, what needs human approval, and what is never allowed at all. The harness reads this file before every tool call.

The model cannot bypass it because the rule lives outside the model.

## Always allowed (no approval needed)
- read any file in the project directory
- run tests
- create branches
- write to memory/ and skills/ directories
- create draft pull requests

## Requires approval
- merge pull requests
- deploy to any environment
- delete files outside of memory/working/
- install new dependencies
- modify CI/CD configuration

## Never allowed
- force push to main, production, or staging
- access secrets or credentials directly
- send HTTP requests not in the approved domains list
- modify permissions.md (only humans edit this file)
- disable or bypass pre_tool_call hooks

## Approved external domains
- api.github.com
- registry.npmjs.org
- pypi.org

This file is the single most important artifact in the whole production stack. It is the difference between an agent crew you can leave running overnight and one you have to babysit. Write it before you spawn your first subagent, not after the first incident.

§ The mistakes that keep crews stuck in demo mode

• No real loop. A long prompt with “think step by step” is not an agent. No iteration, no observation, no recovery.

• Free-form context. Stuffing the window with everything you have. The model gets distracted and misses what mattered.

• Untyped tools. Free-text arguments and no preconditions. The model guesses, sometimes wrong, sometimes destructively.

• Subagents without isolation. When subagents share context with the orchestrator, you get five chatty agents instead of one focused team.

• Orchestrator that executes. The lead agent writing code itself, drowning in details its specialists should be handling.

• No shared task list. “Team” collapses into parallel solo work with duplicated effort.

• No durability. A 50-step task crashes at step 47 and starts over from scratch. Money burned, time wasted.

• No evals. “Better” is a vibe. Six weeks later you cannot explain why anything works or fails.

• No permissions file. Speed without a safety net. One bad approval away from a real incident.

  ---

Conclusion:

A team of AI agents is not more model. It is more structure.

Everything in this roadmap is plumbing. None of it is exotic. None of it requires a frontier model the rest of the world does not have. The teams shipping real multi-agent systems in 2026 are using the same models everyone else can use. What they have that demo-stuck teams do not is nine stages of structure between the agents.

If you have read this far and tried multi-agent setups before, the answer to “why did it not work” is probably in here. Pick the one stage you skipped - usually shared state or permissions - and add it tomorrow. Then the next. A crew that ships is built in stages, not in one weekend of vibes.

Here’s the full map, every hack verified, including the two that shipped this week.

This is built from Anthropic’s own docs, the official Claude Code release notes, and the power-user tips section in their help center. Every hack here is something that actually exists as of May 2026 - not folklore, not deprecated, not “coming soon.”

We organize them in three tiers, from your first session to running parallel agent teams that finish work while your laptop is closed.

32 hacks. 3 tiers. One terminal that runs your whole stack.

Part 1 · Foundation

01. Run /init on every project.

The first thing to do in any project - new or existing. /init scans your codebase and writes a CLAUDE.md file that maps your architecture, conventions, and key files.

From now on, every session starts with that context loaded automatically. You stop re-explaining your project.

02. Set up a /statusline. Mini-dashboard in your terminal.

The single best anti-anxiety upgrade. /statusline generates a script that pins a live bar to the bottom of your session - model, context %, cost, branch, whatever you want. You stop guessing how close you are to context rot.

03. Use voice mode. You talk 3× faster than you type.

Voice mode is now available in Claude Code, Desktop, and Cowork — to everyone. The Anthropic team itself codes mostly by voice. The reason isn’t gimmick: you speak roughly 3× faster than you type, so your prompts get more detailed without taking more time.

Detailed prompts = better output. Free speed.

04. Keep your context small. Don’t dump the whole codebase.

Only give Claude what the current task needs. Break big problems into small focused steps. Less noise = better output - and it’s the single most-ignored basic. The next hack tells you exactly where the bloat is hiding.

05. Run /context to find token bloat. Diagnose, don’t guess.

/context shows exactly what’s eating your tokens - system prompt, files, MCP servers, conversation history - broken down by percentage. If a session feels heavy, this is the first command you run.

Usually one MCP server you don’t need is hogging 30% of your window.

06. Compact at 60%. Clear between tasks.

When context hits ~60%, run /compact - Claude summarizes older messages and gives you back your window. You can even steer what it keeps: “/compact but preserve the auth decisions and DB schema.”

When you’re switching to an entirely different task, /clear wipes the slate (CLAUDE.md stays loaded - you’re not starting from zero).

07. Always start in “plan mode”

Cycle modes with Shift+Tab until you land on Plan Mode. Claude can read, search, research - but won’t modify anything until you approve. It outlines the approach, asks clarifying questions, lists files it’ll touch.

You catch wrong assumptions in one sentence instead of forty files. This single habit cuts revisions dramatically.

08. Treat Claude like a junior developer.

Instead of “write a function that does X,” ask “how should we handle X? What are the tradeoffs?” Reasoning through a problem first produces better code than pattern-matching from a command. You also learn its assumptions, which is where the real bugs hide.

09. Make Claude ask questions. “Until you’re 95% confident.”

Append this to any non-trivial request: “Continuously ask me questions until you’re 95% confident you understand what I need and what you’ll do.” Three rounds of clarification beat three rounds of revision every time. This works especially well in plan mode (hack 7).

10 . Bake self-checks into the todo list.

When Claude makes a todo list, ask it to add verification steps as actual items: “Take a screenshot. Open DevTools and check for errors. Run the tests.”

Plus the magic line: “Don’t move to the next todo until you’re 95% confident the current one is good.” You stop getting features that look done and aren’t.

PART 2 · Control

11. Deploy subagents for parallel work.

Tell Claude to “use subagents” for complex tasks. Each subagent gets its own context window, can use a different model, and works in parallel - research, tests, exploration. They report back to the main session.

Pair with model tiers (hack 15) and run subagents on cheap Haiku while your main thread stays on Opus.

12. Build custom Skills. Reusable workflows in markdown.

Drop a SKILL.md file in .claude/skills/<name>/ and Claude auto-loads it when the task matches the description. A skill is just frontmatter + markdown instructions - but because it loads just-in-time (~100 tokens dormant, ~5K when needed), you can have dozens installed without context cost.

13. Use hooks for what must always happen.

Hooks are shell scripts that fire automatically at specific events: PreToolUse, PostToolUse, session start/stop, subagent completion. They run outside the model’s reasoning so they cannot be skipped. Use for: format-on-edit, block dangerous bash, run lint before commits.

14. Edit permissions for safe autonomy.

Don’t YOLO with --dangerously-skip-permissions. Use the /permissions command (or ~/.claude/settings.json) to explicitly allow safe commands and deny destructive ones.

Deny rules beat allow rules, so dangerous patterns are blocked even if a generic allow would match. Same speed, none of the danger.

15. Match the model to the task. Opus, Sonnet, Haiku - on purpose.

Switch right inside the session: /model opus for architecture and gnarly debugging, /model sonnet for day-to-day building, /model haiku for cheap exploration like “find every file that imports X.” One model for everything is leaving capability or money on the table.

16. Use /memory to edit CLAUDE.md inline.

When you realize mid-session that a convention should live permanently, run /memory to open CLAUDE.md in-place. Faster than alt-tabbing to your editor, and the change is loaded immediately for the rest of the session.

17. Run /review for built-in code review.

/review is a bundled skill that walks your recent changes with a structured review pass - security, style, edge cases. Faster than asking a teammate, and catches things the original session missed because it was in build mode, not review mode.

18. Track spend with /cost. Know what each session costs.

/cost shows token usage and dollar cost for the current session. Useful for finding which sessions are silently expensive (usually: too-big MCP servers, too-long context). Pair with the statusline (hack 2) to make it always-visible.

19. Press Esc Esc to rewind. The undo button for sessions.

Double-tap Escape and Claude rewinds to a previous point in the conversation. Crucial when a session drifts - instead of fighting it or starting over, just rewind to before the drift and rephrase. Most users never even know this exists.

20. Type # for quick memory pins. Add to CLAUDE.md without leaving.

Start any line with # and Claude treats it as a memory instruction - it adds the text to CLAUDE.md without breaking your flow. Perfect for capturing a convention the moment you realize it: # always use named exports, never default.

PART 3 · Scale

Hacks 21-32 - Claude Code as a platform. Includes May-28 features.

21. Run parallel sessions with git worktrees. --worktree feature-name.

Native since Claude Code v2.1.50. Run two Claude sessions on the same repo without them stomping on each other:

Each worktree is an isolated branch with its own working directory. Three Claude sessions, three branches, zero conflicts. Merge back when done, like any git branch.

22. Use API endpoints instead of MCP

MCP loads all a server’s tool definitions into context - a typical 5-server setup can eat 55K tokens before you say a word. If you only need one thing (e.g. reading one Notion database), just hardcode the API endpoint. Less flexible, far cheaper. Use MCP for exploration, hardcode for production.

23. Use /loop for recurring tasks.

Requires Claude Code v2.1.72+. /loop 5m check the deployment status reruns the prompt every five minutes within the same session. Great for babysitting a deploy, watching a PR, polling a build. Loops are session-scoped and auto-expire after 3 days for safety.

24. Schedule Desktop tasks.

For automation longer than a session, use the Claude Desktop scheduled tasks feature. Each fire opens a fresh session (no shared context with previous runs), but it survives terminal exits and laptop restarts. Use for: morning issue triage, weekly metric pulls, nightly log scans.

25. Use Routines for laptop-off automation.

Routines run on Anthropic’s infrastructure - your laptop can be off. Schedule a routine via API call, GitHub event, or fixed cron.

Pair with sub-agents for cohesive overnight work: “review yesterday’s PRs, summarize, post to Slack at 8am.” This is the missing orchestration layer for async teams.

26. Control sessions from your phone.

Start a session locally, scan a QR code with your phone, keep steering it from anywhere. Your code never leaves your machine - only the control channel goes mobile. Useful for: kicking off heavy tasks at desk, monitoring from a walk, approving permissions from the gym.

27. Use UltraThink for hard problems.

Type “ultrathink” in your prompt and Claude allocates the maximum extended-thinking budget before responding. Don’t use it for trivial fixes - but for architecture decisions, complex debugging, or refactors that touch the whole system, the quality jump is real and visible. Tokens cost more; mistakes cost more not using it.

28. Build agent teams. Subagents that talk to each other.

Sub-agents (hack 11) work in isolation. Agent teams let them share a task list, communicate, and assign work to each other. You can talk to any team member directly instead of routing through the main agent. More expensive, longer runs - but for big multi-domain projects, the cohesion is worth it.

29. Install Context7 MCP. Up-to-date docs for any library.

Claude’s training has a cutoff, so it can suggest deprecated APIs. Context7 MCP injects up-to-date, version-specific docs from thousands of libraries - React, Next.js, Postgres, you name it - before Claude writes any code. One install, quality jump across every library.

30. Browse /plugin marketplace. Pre-built skills and agents.

The plugin marketplace is full of pre-packaged Skills, agents, and commands you can install instead of writing your own. Context7 (hack 29) is one example. Browse before you build - there’s a good chance someone already shipped what you need.

31. Trigger Dynamic Workflows. Up to 1,000 subagents in parallel.

Shipped two days ago alongside Claude Opus 4.8. Dynamic Workflows let Claude take a task too big for one session, plan it, fan out across up to 1,000 parallel subagents, run a second wave of agents to refute each finding, iterate until results agree, and hand you the consolidated answer.

The orchestration plan lives in a JavaScript script Claude writes on the fly - not in the context window - which is what makes 500-agent runs feasible at all. Activation is a single keyword:

Requires Claude Code v2.1.154+. On by default for Max and Team; Enterprise admins enable it; Pro users turn it on manually in /config. Trigger by saying “create a workflow” or by setting effort to ultracode (next hack).

Cap: 1,000 subagents per workflow. Cost: significantly more tokens than a single-agent run 0 use it where the task scale justifies it.

32. Set /effort ultracode. Claude decides when to fan out.

The companion to Dynamic Workflows. /effort ultracode sets reasoning effort to xhigh and lets Claude automatically decide when a task is big enough to warrant a workflow. A single request can become multiple workflows in sequence - one to understand the code, one to apply the change, one to verify.

Session-scoped: it stays on until you change it or start a new session. Drop back to /effort high for routine work, because ultracode burns substantially more tokens than a standard session. Anthropic’s own recommendation: pair it with Auto Mode so parallel subagents aren’t blocked on permission prompts.

§ The habits that keep beginners beginners

• No CLAUDE.md. Re-explaining your project every session and getting the answer wrong every session.

• Never checking /context. You can’t fix bloat you don’t see.

• Skipping plan mode. Forty-file diffs to fix a one-sentence misunderstanding.

• YOLO permissions. Speed is great until rm -rf runs in the wrong directory.

• One model for everything. Burning Opus tokens on Haiku tasks.

• Ignoring the marketplace. Building skills that already exist as plugins.

• Not knowing what shipped this week. The biggest features (Dynamic Workflows, ultracode) often launch quietly.

Conclusion:

Claude Code didn’t get good because of one feature. It got good because thirty-two of them stack - CLAUDE.md gives you context, plan mode catches assumptions, Skills package workflows, hooks enforce rules, worktrees parallelize, MCP connects, Dynamic Workflows orchestrate a thousand agents. Each one helps. Together they change what’s possible.

Most people will use six of them, blame Claude when it misses, and move on. The 4% writing commits today are the ones who keep stacking.

Pick one hack you weren’t using - probably /init or plan mode - and add it tomorrow. Then the next. The gap between beginner and PRO is exactly this list, applied.

Where these numbers come from.

$1,000/month is the realistic ceiling for an actively-managed household: 2–3 accounts, 15–25 subscriptions, some debt, regular bills you’ve never renegotiated. It breaks down roughly as: ~$200 in forgotten subscriptions, ~$250 from renegotiating bills (internet, mobile, insurance), ~$150 in silent fees (overdraft, FX, late, inactive investing), ~$200 in tax deductions you weren’t tracking, ~$200 in “decisions you make when you actually see your cashflow.”

If your life is simpler, your number is smaller - and that’s fine. The system is what matters.

PART 1 · See your money

01. Claude is the dashboard. Aggregate every account into one view.

The reason 5-app chaos persists is that no single tool sees everything you have. Your bank sees one account. Your brokerage sees investments. Your credit card app sees one card.

None of them sees the whole picture, and you end up making decisions on partial data - which is how you can simultaneously have $8,000 sitting idle in checking and be paying 22% interest on a credit card.

The fix is one weekly export and one prompt. Most banks let you download a CSV of transactions. Brokerages export positions. Save them to a folder.

Then give Claude this prompt, attaching the files:

I'm attaching CSV exports from all my accounts for last month:
- chase-checking.csv  (main checking)
- chase-savings.csv   (emergency fund)
- amex-platinum.csv   (credit card)
- fidelity.csv        (brokerage + 401k)

Build me a one-page snapshot:
1. Net worth (assets minus debts), with month-over-month change
2. Cashflow: total income, total spending, savings rate %
3. Top 5 spending categories this month, with $ and %
4. Anything unusual vs last month — flag it
5. One question I should be asking myself based on what you see

Be direct. No fluff. Numbers in $.

Claude returns a one-page snapshot in under a minute. The “one question” line is the key - Claude reads the data without ego and surfaces what your brain skipped: “Why is your dining spend 47% higher than last month?” or “You have $8K in checking earning nothing while paying 22% on $4K of credit card debt - moving $4K of that closes the gap.”

This is the foundation. Everything else in this article depends on having one honest picture. Do this once a month - fifteen minutes, replaces three apps.

02. Categorize transactions automatically. Stop tagging by hand.

The single most boring task in personal finance is categorizing transactions. “Was ‘AMZN MKTP US*RZ4F8’ groceries, or household, or that one weird book?” Done by hand it eats hours a month.

Done by Claude - with a Skill that learns your categories - it takes a minute, and it stays consistent across months so trend analysis actually works.

A Skill is the right home for this: it loads only when you ask about transactions, and it carries the one thing you can’t outsource - your own category logic. Here’s the file:

---
name: categorize-transactions
description: Categorize bank and credit card transactions
  using my personal category rules. Use whenever I share
  a CSV of transactions or ask about my spending.
---

# My Transaction Categories

Use exactly these categories — no inventing new ones:

## Essentials
- Housing — rent, mortgage, property tax, HOA, repairs
- Utilities — power, water, internet, mobile
- Groceries — supermarkets only (NOT restaurants/takeout)
- Transport — gas, transit, rideshare, car insurance, parking
- Insurance — health, life, renters (NOT car — that's Transport)

## Lifestyle
- Dining — restaurants, takeout, coffee shops, bars
- Shopping — clothes, electronics, general retail
- Entertainment — streaming, concerts, hobbies, travel

## Money
- Subscriptions — flag SEPARATELY even if also Entertainment
- Fees — bank fees, FX, overdraft, late, interest
- Investments — transfers to brokerage, 401k contributions
- Income — paychecks, refunds, dividends

## Rules
- "AMZN MKTP" → ask me which category, don't assume
- Anything Stripe/Square unclear → ask
- Always flag transactions over $200 separately for review
- Output as a markdown table: Date | Merchant | Amount | Category

Categorization rules belong in a Skill because they only matter when you’re actually categorizing - which is a few times a month. Put them in a system prompt and they’d consume context on every unrelated question.

As a Skill, they take ~100 tokens until you mention transactions, then load fully. This is the kind of just-in-time loading that keeps Claude fast for everything else.

03. Find the leaks. The first $400 hides in plain sight.

Once your transactions are categorized, the next prompt is brutal: “Find every recurring charge in this data - anything that hits monthly, quarterly, or annually.

For each one, tell me how long I’ve been paying it, total to date, and whether I’ve used it in the last 30 days.”

What comes back is the most-read artifact of any finance review: a complete subscription audit. Here’s a realistic one - fifteen lines, the kind of mess that’s normal:

Almost $200 a month, recovered in fifteen minutes. This is not a hypothetical - the average household carries 12+ subscriptions and forgets about 4 of them.

Run this once a quarter and it’s the single highest hourly-rate task in your year.Then the second prompt - the one most people don’t think to run:

From these last 12 months of transactions, find every:

1. Bank fee — overdraft, ATM, wire, monthly maintenance
2. FX conversion fee — anything in a foreign currency
3. Late fee or interest charge — credit cards, loans
4. "Inactive" or "low balance" fees — anywhere
5. Investing fees — expense ratios over 0.20%, advisory %
6. Duplicate charges — same merchant twice in a week
7. Trial conversions — anything that started "$0" then jumped
8. Refunds owed — returns where I never got the credit

Total it up. Show me where to call.

This second pass usually finds another $100–$200/month - fees you didn’t know you were paying, refunds that never arrived, expense ratios eating returns. Combined with the subscription audit, this is the “$400 hour” - fifteen minutes that pays for itself many times over for years.

PART 2 · Take control

04. Negotiate your bills. Claude writes the script. You make the call.

Internet, mobile, insurance, gym, credit card rates 0 almost every recurring bill in your life is more negotiable than you think. The reason most people don’t negotiate is that they don’t know what to say.

Claude writes you a script in thirty seconds. One call typically saves $20–$50/month on each bill. Run it across four bills and you’re at $200/month.

Here’s the prompt that delivers the script - copy, fill in your numbers, run:

Write me a phone script to negotiate down my internet bill.

My situation:
- Provider: Comcast Xfinity, 800 Mbps plan
- Currently paying: $94/month
- Customer since: 2019 (5+ years)
- Competitors near me: Verizon Fios offering 500 Mbps for $55/mo
- I've had 2 outages in the last 6 months

Write me:
1. The opening line — calm, factual, not aggressive
2. What to say if they offer a small discount ($5-10)
3. What to say if they say "no, that's the best we can do"
4. When to ask for the retention department
5. The walk-away line — and what to actually do

Keep it real. Tell me what NOT to say too.

What Claude returns is a five-paragraph script with branching paths - opening, escalation, retention escalation, and an exit. It includes the specific phrases that work (“I’ve been comparing options and I’d hate to switch after 5 years”) and the ones to avoid (“this is too expensive” - too soft and never works). It tells you when to ask for the retention department by name, and what to do if they call your bluff.

This is where the $250/month line item comes from. Internet ($30/mo saved), mobile ($25), car insurance ($40), credit card APR reduction ($15 in interest), maybe one streaming bundle renegotiation ($10) - easily $120/month, often double. Run it once a year per bill.

05. Crush debt with the right strategy. Avalanche beats snowball by $7,000.

Two strategies for paying off multiple debts, both promoted as “the right one” by different camps.

Snowball pays smallest balance first (motivational - quick wins).

Avalanche pays highest interest rate first (mathematical - least money lost). Both work better than no plan; one works much better than the other.

Here’s a realistic example: $45,000 across three debts, paying $1,200/month total. Claude models both strategies side-by-side:

The numbers are real and they’re brutal. $7,001 saved and five months earlier for choosing the right order. The only argument for snowball is psychological - if you’re at risk of giving up, the quick wins of paying off the small debt first keep you in the game. If you’ll stick to the plan either way, avalanche is the answer every time.

Ask Claude this single prompt to get your own version:

Compare debt avalanche vs snowball for me. My debts:

- $X balance @ Y% APR  (name)
- $X balance @ Y% APR  (name)
- $X balance @ Y% APR  (name)

I can pay $Z/month total toward debt.

Show me:
1. Total months to debt-free under each strategy
2. Total interest paid under each
3. Which debt gets attacked in what order, each method
4. The difference in $ and months
5. A recommendation given I'll stick to the plan

Be specific. Use my actual numbers.

06. Make hard decisions with a real framework.

Buy the house? New car? Quit the job?

Most big financial decisions are made on gut and regret. “The mortgage payment is the same as rent, so I should buy.” Except the mortgage payment isn’t the cost - property tax, insurance, maintenance, opportunity cost on the down payment, transaction friction on selling all are.

A real decision needs a real framework, applied the same way every time.

This is exactly what a Skill is for. Install it once, and every “should I buy / quit / take this offer” question goes through the same disciplined process:

name: financial-decision
description: Apply a rigorous framework to any large
  financial decision — buying a home, car, leaving a job,
  taking debt, big purchases. Use whenever I ask "should I
  buy/quit/take" something costing more than $5,000 or
  committing me for more than 12 months.
---

# Decision Framework

For any big financial decision, work through these 5 lenses
before giving an opinion. Show your work for each.

## 1. True 5-year cost
Not the sticker price — the total. Include:
- Direct cost (price, payments, interest)
- Hidden cost (tax, insurance, fees, maintenance)
- Opportunity cost (what would this money earn invested at 7%?)
- Friction cost (commissions, transaction fees if I exit)

## 2. Reversibility
- Can I undo this in 30 days? 1 year? 5 years?
- What does undoing cost — money, time, reputation?
- One-way doors deserve 10x more scrutiny than two-way.

## 3. Cashflow stress test
- Could I still make this work if my income dropped 30%?
- Does it require any of: bonus, future raise, side income?
- What happens if interest rates rise 2 points?

## 4. Alignment with stated goals
- Ask me what my top 3 financial goals are (don't assume)
- Does this decision push me toward or away from them?
- If away — what would I be willing to delay or skip in
  exchange?

## 5. The "regret test"
- In 5 years, would I regret NOT doing this? More or less
  than the regret of doing it and it going wrong?
- This is intuition — use it last, not first.

## Output
End with a clear: "Here's what the numbers say. Here's
what I'd want you to think about. The decision is yours."
Never give a final yes/no — give clarity.

Notice the final instruction: Claude never gives a binary yes/no on big personal decisions. This is intentional. Claude doesn’t know your risk tolerance, your relationship dynamics, your career trajectory, or what you’ll regret.

The Skill’s job is to make the math and tradeoffs visible - to remove the fog. Decisions stay with you, where they belong. Anyone selling you an AI that tells you whether to buy a house is selling you confidence, not analysis.

PART 3 · Grow it

07. Compound your savings. $1,000/month is $173,000 in 10 years.

Here’s the math that turns this whole article from “useful” into “life-changing.” If the system in stages 1–6 saves you the $1,000/month we’ve been talking about, and you invest it consistently at a market-typical 7% real return (the rough historical average of the S&P 500 after inflation), here’s what that becomes:

Look at the gap. You contribute $360,000 of your own money over 30 years. You end with $1.22 million. The market did $860,000 of the work for you — for free, while you slept, because you let compound interest run.

The numbers across the milestone years, all verified math:

• 10 years: $173,085 - a year of household income most places

• 20 years: $520,927 - a paid-off house in much of the country

• 30 years: $1,219,971 - retirement comfortably possible

Run your own version with one prompt:

I want to model long-term wealth from monthly savings.

Inputs:
- Monthly contribution: $X
- Expected annual return: 7% (S&P 500 long-term avg)
- Time horizon: 30 years
- Starting balance: $0 (or current investments)

Show me:
1. Balance at end of years 5, 10, 15, 20, 25, 30
2. Total I contributed vs total market growth (the gap)
3. Same table at 5%, 7%, and 10% so I see the range
4. What monthly contribution would I need to hit $1M in 20 years?

No advice, just the math.

7% is a rough long-term historical average for the US stock market after inflation. Real returns swing wildly year to year - some years up 25%, others down 30%. The math above assumes constant 7%, which no real year delivers.

The compound effect works over decades, not months. If you can’t tolerate watching your balance drop 30% in a bad year, this is information you need before you start, not after. Claude can model these scenarios; it cannot tell you what to buy.

07.2 Define what “enough” actually means. The 4% rule, with your number on it.

The number people throw around - “I need to retire” - is usually a feeling, not a figure. The 4% rule gives you the figure. It says: you can safely withdraw 4% of your invested nest egg per year, more or less indefinitely, because long-run returns cover the withdrawals.

The math is simple: take the income you want, multiply by 25. That’s your nest egg target.

Now overlay this on the compound chart from Stage 7. If you invest $1,000/month at 7% and want $1.5M for a $60K/year retirement, you get there in about 26 years.

Push it to $2,000/month and you cut that nearly in half. The system isn’t magic - it’s just arithmetic that most people never sit down to do.

This is the second Skill worth installing - the investment modeler. It turns Claude into a scenario calculator without ever crossing into advice:

---
name: investment-modeler
description: Model long-term investment scenarios —
  compound growth, retirement targets, "what if" comparisons,
  4% rule calculations. Use whenever I ask about investing
  outcomes, retirement timing, or compare scenarios. Do NOT
  recommend specific investments.
---

# Investment Scenario Modeler

## What I do
Run the math on hypothetical scenarios. Show inputs,
outputs, and ranges. Compare options side-by-side.

## What I never do
- Recommend specific stocks, funds, ETFs, or sectors
- Predict market direction
- Advise on tax-advantaged account choices (Roth vs trad)
  — these are tax-situation specific; refer to a CPA
- Tell anyone what to buy or sell

## Always include
- A range (5%, 7%, 10%) so they see best/typical/great cases
- Total contributed vs total growth, made explicit
- A reminder that real returns are non-linear
- A line about consulting a licensed advisor for personal
  advice on specific instruments

## Output format
Tables for comparisons. Show your math. Be honest about
what's assumption vs. what's calculation.

The most powerful line in that Skill is the “What I never do” section. Telling Claude what to refuse is as important as telling it what to do - especially for finance, where overstepping into advice could cost someone real money or put them on the wrong side of regulation.

This pattern works for any sensitive domain: write the boundary into the Skill once, and Claude holds the line consistently across every session.

The habits that keep people stuck

• Not aggregating the picture. You can’t make decisions on partial data - and every app shows you partial data by design.

• Never categorizing consistently. Spending “trends” mean nothing if last month’s “shopping” was this month’s “household.”

• Skipping the silent-fees pass. The fees you don’t notice are the ones that compound against you for years.

• Never renegotiating bills. Companies absolutely price-discriminate between customers who call and customers who don’t. Be the one who calls.

• Snowball when avalanche fits. Quick wins feel good, but $7K is . Pick avalanche unless you’ll genuinely quit otherwise.

• Buying without the framework. Five lenses on a big purchase takes 20 minutes. The wrong purchase costs you for years.

• Treating savings as the goal. Savings is potential energy. Invested savings is the actual thing. The gap between them is where the millionaires live.

• Asking AI for stock picks. No legitimate tool does this. If something is willing to tell you what to buy, that’s the red flag.

Conclusion:

The five apps and the spreadsheet aren’t your problem. They’re a symptom.

The problem is that none of them sees the whole picture, none of them does the math on your behalf, and none of them tells you the boring truth - that the difference between staying broke and getting free is mostly arithmetic, applied consistently, for longer than feels reasonable.

Claude isn’t your advisor. It’s the workflow that turns a chaos of statements, subscriptions, and half-finished spreadsheets into one honest picture, one negotiation script, one decision framework, one compound chart.

Do the system once, run it monthly, and the numbers do their thing.

Pick one stage and start there. Most people should start with Stage 3 - the subscription audit.

Fifteen minutes, $2,000 a year, and you’ve earned the right to take the rest seriously.

They type a request, watch it spray code across forty files, accept whatever comes out, and call it “vibe-coding.”

Vibe-coding is a real and useful mode - describe what you want, let the agent build it. The problem is stopping there. When the diff is unreviewable, the tests never ran, and a change three days ago broke something you can’t trace, you don’t have a productivity tool. You have a slot machine.

The fix is not a better model. It is a better setup. Claude Code is a programmable platform with five extension layers most people never touch.

Below are ten techniques, built from Anthropic’s own best-practices docs - each shown with the real file or command you’d actually use, and a screenshot slot where you drop your own.

Same tool. Same model. A third of the output - or all of it.

PART 1 · Foundation

01. Write a CLAUDE.md

A CLAUDE.md file at your project root is read into context at the start of every single session, automatically - before you type anything.

It’s the closest thing Claude Code has to long-term project memory. Everything you’d otherwise re-explain on every task (your stack, your conventions, your non-negotiables) lives here once and is present every time.

The mental model that keeps it useful: CLAUDE.md is for things that must be true on every turn, in every task. Stack and global conventions, yes.

Here’s a complete, realistic one:

# Project: Reports Dashboard

## Stack
- Next.js 14, TypeScript, Tailwind
- Postgres via Supabase
- Tests: Vitest, in /tests

## Conventions
- 2-space indent, no tabs
- Named exports only, no default exports
- No new dependencies without asking first

## Always
- Run `npm test` before saying a task is done
- Keep changes scoped to exactly what I asked
- If you're unsure about an approach, ask before coding

The mental model that keeps it useful: CLAUDE.md is for things that must be true on every turn, in every task. Stack and global conventions, yes.

Task-specific procedures, no - those belong in Skills (technique 8), which load only when relevant and keep this file lean. A bloated CLAUDE.md is a real cost: every line is in context for every request, so treat it like a tight constitution, not a wiki.

Pro nuance - the file hierarchy:

CLAUDE.md cascades. A file at the project root is shared with your team via git; a ~/.claude/CLAUDE.md in your home directory holds personal rules across all projects; nested CLAUDE.md files in subfolders add local rules for that part of the tree.

Team conventions go in the repo, personal quirks in your home file - and keep each one short, since every line costs context on every request.

02. Plan before you code

The vibe-coder fires a request and watches code appear. The engineer asks for a plan first - the approach, the exact files it’ll touch, the tradeoffs, the assumptions - and approves or corrects it before a single line is written.

The reason this works is mechanical: a plan is cheap to read and cheap to fix. Catching “you’re about to add a charting library I don’t want” in a one-line plan costs you one sentence.

Catching it after the code is written costs you a revert across a dozen files plus the context Claude already burned building the wrong thing.

The phrasing matters. Add “don’t write code yet” explicitly - otherwise Claude’s helpful instinct is to plan and immediately build. In practice the session looks like this:

Why this matters most:

The three failure patterns that make AI coding infamous - silent wrong assumptions, over-engineering 50 lines into 500, and touching code it was never meant to - are all caught at the planning step. Plan-first is the single biggest reliability upgrade in this list.

03. Scope tightly.

Broad requests produce broad, unreviewable diffs - and broad diffs are where bugs hide. The engineer scopes each task to one bounded change. “

Add a CSV-export button to the reports page that exports the currently filtered rows - nothing else” is a task with a clear edge.

“Improve the reports page” is an open invitation for Claude to rewrite half your app, refactor things you didn’t ask about, and bury the one change you wanted in three hundred you didn’t.

Tight scope pays off three ways at once: the diff stays small enough to actually review (technique 4), the context stays clean so quality stays high, and a wrong result is one cheap revert instead of a tangled untangling.

The slow loading, the cleanup, the refactor - each is a separate task, done separately, reviewed on its own. If you catch yourself writing “and” in a request, that’s usually two tasks.

The foundation is one file and two habits. Most people skip all three.

PART 2 · Control

04. Keep diffs small and reviewable.

The most dangerous output Claude Code produces is a giant diff you accept because reading it is too much work.

Code you didn’t review is code you don’t understand - and when it breaks at 2am, you’ll be debugging a stranger’s work that happens to live in your repo. The whole bargain of agentic coding only holds if you stay the reviewer: Claude writes fast, you verify deliberately.

This is the direct payoff of tight scope (#3). A bounded task produces a diff small enough to read line by line in under a minute - and reading it is where you catch the real bugs, the ones tests might miss:

+ export function exportToCsv(rows: Row[]) {
+   const header = Object.keys(rows[0]).join(",");
+   const body = rows.map(r =>
+     Object.values(r).map(escapeCsv).join(",")
+   ).join("\n");
+   return `${header}\n${body}`;
+ }
  1 file changed, 8 insertions(+)

Eight lines. You can read every one - and you might catch that escapeCsv needs to handle commas inside fields before it shis, not after.

05. Make Claude run the tests.

“The feature is complete!” is a claim, not a fact - and accepting claims is how unverified bugs reach production.

The fix is to make Claude actually run the tests and show you the output before anything is accepted. Not “did you test it?” but “run the suite and paste the result.”

The stronger version is test-first: have Claude write the test, run it, watch it fail, then write code until it passes.

This matters more with an AI than with a human - a failing-then-passing test proves the test actually exercises the new behavior, instead of being a green rubber-stamp Claude wrote to match whatever it already built.

Claude runs your suite itself, so the whole loop happens in one session:

bash

> Write a test for the export including the empty-rows
  case, run it, then implement until it passes.

⏺ Claude  wrote /tests/export.test.ts
⏺ running npm test …
  ✓ exports filtered rows to CSV
  ✓ includes a header row
  ✓ escapes commas inside fields
  ✓ returns empty string on empty input
  4 passed (0.41s)

Now “done” means green tests you watched run - and the empty-set bug that would’ve hit production died before merge.

06. Use hooks for what must always happen.

Here’s the distinction that makes this technique matter: CLAUDE.md instructions are advisory. Claude reads them and usually complies - but “usually” isn’t “always,” and on turn 40 of a long session, under a full context, a rule can quietly slip.

Hooks are deterministic. They’re shell scripts that fire automatically at fixed points in Claude’s workflow, run outside the model’s reasoning, and cannot be skipped, forgotten, or hallucinated away.

That makes them the right home for anything that must happen with zero exceptions. The events you can hook into include:

• PreToolUse (before Claude runs a tool - use it to block dangerous commands like writes outside src/),

• PostToolUse (after - run the formatter or linter on every edit), and UserPromptSubmit (inject context on every prompt).

Here’s a real PostToolUse hook that formats code after every single edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "npm run format"
      }
    ]
  }
}

A CLAUDE.md line (”always format after edits”) works usually. A hook works every time, no exceptions - the formatter runs whether Claude remembers or not. For anything that must be guaranteed, use a hook. Claude can even write the hook for you.

PART 3 · Scale

07. Connect MCP servers

By default Claude Code can see your filesystem and run shell commands - that’s it. MCP (Model Context Protocol) servers are how you give it everything else: your database, issue tracker, design files, monitoring, any SaaS tool. MCP is an open standard - think of it as USB-C for AI: one protocol, many devices.

Connect a server once and Claude gains real tools, so it can read a ticket straight from your tracker, query your actual schema instead of guessing column names, or pull a Figma design directly.

The key mental split: MCP is for access (connecting Claude to external systems), while Skills are for know-how (how to do something). They compose - an MCP server gives Claude your GitHub, and a Skill tells it how to review PRs against your team’s standards.

You add and inspect servers right from the terminal:

$ claude mcp add postgres
  ✓ connected: postgres (reports DB)

$ claude mcp add github
  ✓ connected: github (issue tracker)

> /mcp
  Connected servers:
  ● postgres   — query schema, run reads
  ● github     — read issues, open PRs

Now you can say “implement issue PROJ-241; check the reports table schema directly for the columns to export” - and Claude reads the ticket and queries the real schema itself.

No copy-paste, no stale schema, no human relay.

Every connected MCP server loads its tool definitions into context before you say a word - a typical five-server setup can cost roughly 55,000 tokens up front, versus about 100 tokens for a dormant Skill.

So connect servers you actually use and disconnect the ones you don’t. The instinct to wire up every available integration quietly shrinks your usable context window. Treat MCP servers as a deliberate, curated toolkit - not a junk drawer.

08. Write /Skills for repeated workflows.

A Skill is a folder containing a SKILL.md file - YAML frontmatter (a name and a description) plus markdown instructions, and optionally helper scripts. It packages a repeatable workflow: your deployment checklist, your migration procedure, your export conventions, your accessibility review.

The rule of thumb: if you’ve written the same instructions to Claude twice, that should have been a Skill the first time.

What makes Skills cheap is progressive disclosure.

At session start, Claude only sees each Skill’s name and description - about 100 tokens apiece - not the full body. It loads the full instructions (up to ~5K tokens) only when your task matches the description, and any referenced scripts only if it actually needs them.

That’s why you can have dozens of Skills installed without slowing anything down, and why Skills - not CLAUDE.md - are the right home for task-specific rules: they keep your always-on context lean and load in just-in-time.

Here’s the full file:

---
name: csv-export
description: How we generate CSV exports —
  use whenever the task involves exporting
  data to CSV or spreadsheet formats.
---

# CSV Export Standard

Every CSV export in this project must:
- Include a header row from the column names
- Use UTF-8 with a BOM (so Excel opens it cleanly)
- Escape commas and quotes inside field values
- Name the file: `report_{type}_{YYYY-MM-DD}.csv`
- Export only the currently filtered rows, not all data

Written once. From now on, every export Claude builds follows this standard automatically - the Skill loads itself the moment a task mentions CSV, and stays out of context the rest of the time.

Better still, Skills are portable and composable: one developer’s Skill becomes the team’s, the format is now an open standard, and you can stack several (a code-reviewer Skill alongside a git-automation Skill) and they cooperate.

Because Claude decides whether to load a Skill purely from its description, that one line is doing all the heavy lifting. Vague descriptions (”helps with documents”) bloat your always-on token cost and risk Claude loading the wrong Skill - or missing the right one.

Write descriptions that name the exact trigger: “use whenever the task involves exporting data to CSV or spreadsheet formats.” Also worth knowing: Claude Code ships with bundled skills like /debug, /simplify, and /batch -try them before writing your own.

09. Delegate to subagents

Here’s the failure mode this solves: the classic mistake is doing 20 file reads and 12 greps in your main session to investigate something, then trying to plan the actual work with all that noise still loaded. By the time Claude codes, half its context window is junk and quality drops.

Subagents fix this by running in their own fresh, isolated context with their own tools and even their own model if you want (a cheap Haiku subagent for grep-heavy exploration, say). They do the noisy work and report back a clean summary:the noise never touches your main session.

The rule: spawn a subagent the moment a task would pollute your main context - research, code review, exploring an unfamiliar part of the codebase. Asking for one is plain English:

bash

> Use a subagent to map how exports currently
  work across the codebase, then report back a
  short summary. Keep my main context clean.

⏺ Claude  spawning subagent (own context)
  subagent read 214 files…
⏺ summary returned:
  - 3 existing export paths (PDF, XLSX, print)
  - shared formatter in /utils/format.ts
  - no CSV path yet — safe to add alongside

The 214 files of noise stayed in the subagent’s context. Your main session got one clean paragraph - and plans the build with a clear window.

This is also how parallel work happens: a coordinator with specialist subagents for review, tests, and QA.

10. Match the model to the task.

Running every task on one model leaves either capability or money on the table. The three tiers exist for genuinely different jobs:

• Opus for complex reasoning, architecture decisions, and gnarly debugging where being right matters most;

• Sonnet for the bulk of day-to-day building, where it’s the best balance of speed and quality;

• Haiku for fast, cheap, high-volume work like “find every file that imports X” or simple mechanical edits.

Matching the tier to the task is the difference between waiting (and paying) for deep reasoning on a trivial grep, and under-powering a hard architectural call.

You switch right inside the session:

bash

> /model opus     # architecture decision
  ✓ now using Claude Opus 4.7

> /model sonnet   # build the export feature
  ✓ now using Claude Sonnet 4.6

> /model haiku    # "find every file importing X"
  ✓ now using Claude Haiku 4.5

Reasoning power where it counts, speed and savings where it doesn’t. If quality is your only variable and budget isn’t, standardizing on the most capable model is defensible too - but make it a choice, not a default you never examined.

The whole system on one page

These 10 techniques map onto Claude Code’s five extension layers. Here’s how they fit together - each has a different context cost and a different job.

The habits that keep vibe-coders stuck

• No CLAUDE.md. Re-explaining your conventions every session, and getting them wrong every session.

• Skipping the plan. Finding out what Claude built only after it built it - across forty files.

• Accepting diffs you didn’t read. Code you waved through is code you’ll debug at 2am.

• Trusting “done.” If you didn’t see the tests run, the feature isn’t verified - it’s claimed.

• Putting must-haves in CLAUDE.md instead of hooks. Advisory means “usually.” Some things need “always.”

• Never leaving the chat box. Ignoring MCP, Skills, and subagents is using a third of the tool.

  ---

Conclusion:

The model writes the code. You do the engineering.

None of this slows you down. A CLAUDE.md takes ten minutes. A plan step takes one sentence. A hook takes five lines.

They’re the cheapest investments in software, and they convert a slot machine back into a tool you control.

Pick the one technique your setup is missing most - probably CLAUDE.md or the plan step - and add it to your next session. Then the next. The 4% writing commits today are just the people who started.

This guide is built from Anthropic’s own official prompt engineering documentation - the same patterns their engineers use internally.

Each technique has been benchmarked: in Anthropic’s internal testing, structured prompts produce 20–40% more consistent outputs than the unstructured equivalents most people write.

To make the progression concrete, we will use one task throughout all ten techniques: writing a blog post about productivity tips for remote workers.

You will see the same prompt evolve from amateur trash to professional-grade. The transformation is the lesson.

01. Be ridiculously specific. Vagueness is the #1 killer.

The single most common prompt is some version of “write me a blog post about X.” This is a prompt for any blog post - and Claude will give you exactly that: a generic one.

The fix is not magic words. It is treating Claude like a brilliant new hire with zero context on your project. Spell out audience, length, tone, format, and what success looks like.

✗ Amateur:

Write me a blog post about productivity
tips for remote workers.

What you get: 800 generic words. “Set a routine.” “Take breaks.” Content you’ve seen a thousand times.

✓ Pro:

Write a 1,200-word blog post on productivity
for remote workers who have been WFH for
2+ years and have hit a wall. Audience knows
the basics (don't repeat "take breaks"). Tone:
direct, slightly contrarian, no fluff. Open with
a counterintuitive claim. End with one specific
action they can do today.

What you get: A post with a real angle, written for a real reader, that lands a real action.

02. Give Claude a role. Identity shapes output.

Identical questions to “a helpful assistant” versus “a senior editor at a top business publication” produce radically different answers.

Roles set vocabulary, default standards, and what Claude considers worth saying. Put roles in the system prompt - that is where Claude weights them most heavily.

✗ Amateur

[no system prompt]

Write a blog post about remote
productivity.

What you get: Default Claude - competent, neutral, slightly bland. Sounds like everyone else.

✓ Pro

// System prompt
You are a senior editor at a respected
business publication. You despise generic
listicles. You only publish pieces that
have a real argument and one
counterintuitive insight.

// User
Write a blog post about remote productivity.

What you get: A post with a thesis, not a vibe. Standards are now baked into every paragraph.

03. Structure with XML tags. The single biggest pro tell.

Claude was specifically trained to parse XML-style tags. When you wrap sections of your prompt in <context>, <task>, <constraints>, <output_format>, you remove all ambiguity about which part of your prompt is which.

Anthropic’s own testing puts the consistency gain at 20–40%. The amateur wall-of-text becomes a parseable spec.

✗ Amateur

Write a blog post about remote productivity
for senior managers, around 1200 words, in
a direct contrarian tone, include three case
studies, end with an action item, oh and
also avoid the cliché tips like "take breaks."

✓ Pro

<context>
Audience: senior managers, WFH 2+ years.
</context>

<task>
Write a 1,200-word blog post on remote
productivity.
</task>

<constraints>
- Tone: direct, contrarian
- Avoid clichés ("take breaks", "set routine")
- Include 3 brief case studies
- End with one concrete action
</constraints>

Result: Nothing dropped. Claude can also reference your sections back (”per the constraints…”) for self-checking.

The foundation alone closes most of the gap. Most people stop here. The pros are just starting.

04. Show, don’t tell. Few-shot examples beat any description.

Telling Claude “use a direct, punchy style” is fine. Showing it three paragraphs in that exact style is 10x more effective. Examples are how you transfer style without writing a style guide.

Two to five is the sweet spot - more than that and you are wasting tokens for diminishing returns.

✗ Amateur

Write in a punchy, direct style with
short paragraphs.

What you get: Claude’s interpretation of “punchy.” Could be anywhere from “snappy” to “trying too hard.”

✓ Pro

<examples>
<example>
Most productivity advice is for beginners.
This isn't. If you're reading at 9am with
coffee, you already know the basics. The
question is why you've plateaued anyway.
</example>

<example>
Calendar blocking doesn't work. Not for
you. The reason isn't discipline. It's that
you blocked the wrong things.
</example>
</examples>

Write in this style.

Result: Claude pattern-matches the rhythm, the contrarian setup, the short sentences. Style transferred.

05. Let Claude think. Chain-of-thought is the cheat code.

For anything that requires planning or judgment, asking Claude to think before answering produces dramatically better results.

The mechanism is real: reasoning tokens give the model space to work through the problem before committing to a final output. You ask it to plan in one tag, then write in another.

✗ Amateur

Write a 1,200-word blog post on
remote productivity.

What you get: Claude starts writing on the first token. No outline, no thesis check - the structure emerges by accident.

✓ Pro

Before writing, work through this in
<thinking> tags:
1. What's the one counterintuitive claim?
2. What 3 case studies support it?
3. What's the single action at the end?

Then write the post in <post> tags.

Result: Claude plans the argument, picks the strongest case studies, lands the action - then writes. Quality jumps visibly.

Pro tip - extended thinking:

On Claude’s newest models, you can enable extended thinking at the API level - the model gets a dedicated reasoning budget before responding. For complex creative work, this can be the single biggest quality lever you have.

06. Prefill the response. Skip the preamble entirely.

Claude has a polite reflex to open with “Sure! Here’s your blog post:” - wasted tokens and tone-killers.

The fix is to prefill the start of the assistant’s response yourself. Claude will continue from where you left off, skipping any preamble entirely.

✗ Amateur

Just give me the post. No preamble.

What you get: Sometimes works. Sometimes you still get “I’d be happy to write that for you. Here it is:”

✓ Pro

// User message
Write the blog post.

// Assistant message (prefilled by you)
# Most productivity advice is for
beginners. This isn't.

Result: Claude continues from your line. Zero preamble. Tone locked from word one.

07. Give permission to say “I don’t know.” Hallucination, killed.

Claude makes things up most often when it feels pressured to answer. Explicitly granting permission to admit uncertainty - or to flag weak claims - eliminates a huge category of confident-but-wrong output.

This single line is one of the most underrated fixes in the entire toolkit.

✗ Amateur

Include three real case studies of
companies that improved remote
productivity.

Risk: Claude may invent plausible-sounding companies and statistics rather than admit it doesn’t have specifics.

✓ Pro

Include three case studies of companies
that improved remote productivity.

If you don't have a verifiable real example,
say "[case study placeholder — needs
verification]" instead of inventing one.
Accuracy matters more than completeness.

Result: Claude flags what it doesn’t know instead of inventing it. You catch gaps before publishing.

08. Chain prompts. One job per prompt, not five.

For complex tasks, the amateur instinct is to cram everything into one mega-prompt. The pro move is the opposite: break it into a chain of small prompts, each doing one thing well.

The output of one becomes the input of the next. Latency goes up; accuracy goes up far more.

✗ Amateur (1 mega-prompt)

Research three companies, write an
outline, write a 1,200-word post in our
style with case studies and an action,
then suggest three SEO titles and a
meta description.

Problem: Claude rushes each step. Outline is weak, post drifts, titles are afterthoughts.

✓ Pro (chain of 4)

// Prompt 1
Research and summarize 3 real companies
with strong remote productivity practices.

// Prompt 2 (uses output of 1)
Build a detailed outline for a 1,200-word
post using these case studies.

// Prompt 3 (uses output of 2)
Write the post from this outline in our
style.

// Prompt 4 (uses output of 3)
Generate 3 SEO titles + meta description.

Result: Each step has Claude’s full attention. Quality compounds. This is how production AI workflows actually run.

09. Force structure with tool use. Clean JSON every time.

When you need machine-readable output - say, the post broken into title, hook, sections, action, and meta - prose instructions like “respond in JSON” fail unpredictably.

The pro move is tool use: you define a tool with a schema, force Claude to call it, and get guaranteed-shape data back. No parsing prose, ever.

✗ Amateur

Respond in JSON with fields: title, hook,
sections, action, meta_description.

Problem: Sometimes you get clean JSON. Sometimes you get markdown around it. Sometimes a polite preamble. Production code breaks.

✓ Pro

// Define a tool
{
  name: "publish_post",
  input_schema: {
    type: "object",
    properties: {
      title: { type: "string" },
      hook: { type: "string" },
      sections: { type: "array" },
      action: { type: "string" },
      meta: { type: "string" }
    },
    required: ["title","hook","sections"]
  }
}

// Force the call
tool_choice: { type: "tool",
  name: "publish_post" }

Result: Guaranteed-shape JSON, every single time. Production-grade.

10. Iterate ruthlessly. The pros don’t get it right the first time.

The biggest lie in prompt content is “here’s the perfect prompt.” There is no perfect prompt - there is the one you write, the output it produces, the ways it fails, and the next version. The pros iterate. They write a draft, run it on five inputs, look at where it broke, and fix exactly that - not the whole prompt.

The loop that works:

• Define success. What does a perfect output look like? Write it down before you write the prompt.

• Run on 3–5 varied inputs. Not one. Edge cases reveal what one shot hides.

• Diff against your ideal. Where exactly did it fall short? Tone? Length? Missing constraint?

• Fix one thing. Add one constraint, one example, one tag - not a rewrite. See if that closed the gap.

• Repeat. Most production prompts go through 8–15 iterations before they ship.

Use the Prompt Improver

Anthropic’s Console has a built-in Prompt Improver that automatically restructures your prompt with XML tags, refines chain-of-thought, and enhances examples.

Paste your draft, add feedback about what’s wrong, and review the improved version. It is the single best learning tool in the entire ecosystem.

The amateur prompt vs the pro prompt - side by side

Here is the full transformation. The same task, the same goal - but ten techniques stacked.

✗ Amateur - what 87% write

Write me a blog post about productivity
tips for remote workers.

✓ Pro - what the 13% write

// System prompt — role (#2)
You are a senior editor at a respected
business publication. You despise generic
listicles and only publish pieces with a
real argument and a counterintuitive insight.

// User prompt — XML structured (#3)
<context>
Audience: senior managers, WFH 2+ years,
hit a plateau. They know the basics.
</context>

<task>
Write a 1,200-word blog post on remote
productivity. (specificity #1)
</task>

<constraints>
- Tone: direct, contrarian, no fluff
- Avoid clichés ("take breaks", "routine")
- 3 case studies; if no real one fits, write
  [verify] instead of inventing. (#7)
- End with one concrete action
</constraints>

<examples> (few-shot #4)
<example>Most productivity advice is for
beginners. This isn't.</example>
<example>Calendar blocking doesn't work.
Not for you.</example>
</examples>

Before writing, plan in <thinking> tags: (#5)
- the counterintuitive claim
- the 3 case studies
- the closing action

Then write the post in <post>.

// Assistant prefill (#6)
<thinking>

One prompt, seven techniques stacked. The result reads like a senior editor wrote it - because you told Claude to be one.

The mistakes that keep amateurs amateurs

• Writing one mega-prompt and hoping. The right move is iteration, not one perfect shot.

• Telling instead of showing. “Be punchy” loses to two punchy examples every time.

• Skipping the role. Default Claude is competent. Senior-editor Claude is sharp. Free upgrade.

• Asking Claude to answer instantly. No thinking tag = no planning = mid-tier output.

• Trusting prose for JSON. If your code parses Claude’s output, use tool use. End of debate.

• Never reading the docs. Anthropic publishes the official techniques. Most people don’t read them. You just did.

  ---

Conclusion:

Two people send Claude the same task and get wildly different output. They blame the model. They blame their use case. They don’t blame the prompt - which is exactly the difference.

You now know the ten techniques the 13% use. Pick the one your prompts are missing most and add it to whatever you write today. Then the next. Stack them and the gap closes faster than you’d believe.

Bookmark this. Come back when an output disappoints you. Nine times out of ten, the answer is in one of the ten boxes above.

You will see the exact Claude Code prompts, the real API calls, the screens -and the honest math of reaching $5K a month.

That is not a lottery ticket. Building is the easy 40%. Getting paid is the other 60% - and we cover both.

What we are building: CalSnap

The whole app is one magic loop: the user snaps a photo of their meal → Claude’s Vision API identifies the food and estimates calories and macros → the app logs it to their daily total.

No barcode scanning, no manual database search, no 14-field forms. Point, shoot, logged.

Why this is a good first AI app: the AI is the product (vision + estimation is exactly what Claude does), the pain is real and recurring (people hate manual calorie logging), and it is narrow enough to build in a weekend.

01. Validate the idea before any code.

Calorie tracking is a proven, paid market - MyFitnessPal, Cal AI, and others already make millions, which means the budget exists. Your angle is not “beat MyFitnessPal.” It is one sharper wedge: faster photo logging, a specific diet (keto, bodybuilding prep), or a friendlier UX for a niche.