Last week, I sat down to write a follow-up post on Loops and deep-diving into multi-agent systems. But then I realised something – I personally have had half a dozen multi-agent experiments and use cases sitting in my to-do list which I’m yet to try out. I do use multi-agents for a few things but not to the extent I’ve wanted. That realisation took me down a different rabbit-hole altogether: What are the real use cases which benefit from a multi-agent system? What are the friction points and shortcomings of it? And most importantly, if they’re so powerful, why aren’t more people using them, excluding all the AI-influencer demos?

If you’ve been doom-scrolling AI Twitter, you’ve definitely seen the hype: “I built a 12-agent swarm that codes, writes, and launches SaaS products while I sleep.” Meanwhile, in your actual workflow, you’re still copy-pasting between three different chats and praying nothing explodes. So I set out to find: do people actually use multiple agents simultaneously in a meaningful way today? And more importantly: outside of coding and tech demos, is this “agent team” thing real, or just a fancy word for “I opened three tabs”?

So this article is a bit opinionated and based on my interaction with developers, engineering leaders and non-tech [AI-pilled] folks in my circle. It also includes some online research, for which I actually did use “multi-agents”. I encourage you to share in comments any inaccuracies or contradictions you may have seen compared to my own experience.

This is what I’ve found. The short answer is: yes, people are using multi-agent workflows. But not to the extent that AI-influencers would have you think. Almost no one is running a “swarm of tiny robots”. They’re running it more for role-delegation and evaluating multiple solutions. Let’s break down what’s actually happening in the wild and how Claude, Cursor, and Codex each approach this. I look at specifically those three because I believe they cover the majority of users and use cases.

I reviewed this post after I finished writing it. While I really wanted to explore how this powerful construct of multi-agents can be leveraged by non-tech folks too, unfortunately, the way today’s tools are built, these features are largely targeted towards engineers. So heads-up, this gets a bit technical. But I encourage non-tech folks also to go through it and think about how they can apply these to their own workflows.

The three flavors of multi-agent

1. Claude: The closest thing to a real “team”

Claude Code’s Agent Teams feature is the most explicit “team of agents” product you’ll find right now. Released with Opus 4.6, it’s designed so that one session acts as a team lead, spawns teammates, and coordinates them through a shared task list and a mailbox system. Note that the feature is still experimental and you have to explicitly enable it in settings.json before you can use it. There are a few tutorials on YouTube that go in more depth about how to set it up and use it, but below are some key features of this:

• Team lead + teammates: One main Claude session becomes the manager. It spawns other sessions, each with its own context window and role-specific instructions.

• Shared task list: All agents see the same Kanban-style task board. Tasks have states, dependencies, and can be claimed by teammates as they become available.

• Peer-to-peer messaging: Teammates can send structured messages to each other directly, not just back to the lead. This is interesting because it means, say for example, a security reviewer agent can flag an issue to the performance reviewer agent mid-run without stalling the whole team.

• File locking: When one agent writes to a file, it acquires a lock, so that two agents don’t try to edit it at the same time.

• Automatic orchestration: You describe a complex task, and Claude figures out what specialist agents to spawn, in what order, and how they should check each other’s work. But if you’re really particular about those things, you can also specify all of those things explicitly.

In practice, apparently people are using Agent Teams for:

• Research tasks with competing hypotheses.

• Full-stack features where one agent handles frontend, another backend, and another tests.

• Content pipelines: e.g., “take this one webinar and turn it into a week’s worth of LinkedIn posts, X threads, and Instagram captions.”

The most mature examples are still in technical and content-production workflows. Within content and non-tech use cases, only maybe 5% of power users are using this kind of approach.

2. Cursor: The orchestration workspace

Cursor doesn’t call itself an “agent team” platform in the same way. Instead, it’s an agent-first IDE. So it doesn’t have, like, one manager agent directing a team of agents. But instead it has a workspace where you can launch and coordinate many specialised agents.

Cursor seems to have a few different flavours of Agent Teams in that sense.

Human Lead: Cursor introduced a dedicated “Agents Window” outside of the main IDE some time back. They also added support for multiple agent tabs at the same time. But those are totally isolated and independent sessions you’re having with individual agents. So essentially, you are acting as the “human lead” who assigns tasks and coordinates the work between the different agents.

That’s the default mode of working for most people. But if the task is not that big, people don’t usually bother kicking more agents and switching tabs for the same or related task. If the wait time per task is not really long, people will tend to wait and serialise the tasks rather than parallelise for maximum productivity.

Best-of-N: Cursor provides a /best-of-n command that runs a given task simultaneously across multiple models. You can provide a list of all the models against which you want to run that task. It then gives you the summary of the result that the models gave consensus for. It also shows which models agreed to a certain approach and which ones differed. This is classic “best-of-N parallelism.”

Build-in-Parallel: This is a relatively new feature, available since May 2026 in Cursor 3.3 and above. This allows you to give a list of independent tasks which Cursor can then run in parallel.

This is how you use it -

• Send a multi-step request. E.g. Refactor code generator, Add token tabs to leaderboard, Implement navigation menu.

• Cursor produces a plan and shows a “Build in parallel” button pill below it.

• Click the “Build in parallel” on the plan card. The agent then spawns one async subagent per independent step.

• Each subagent appears as its own row with its own progress indicator and final summary.

• The main agent thread is free to interact with you.

A few things to remember regarding /multitask

• One thing to note is that this feature is quite different from Claude Code’s Agent Teams. These are really just independent tasks happening in parallel. There is no “Lead” agent and no coordination happening between the subagents.

• The subagents also do not work on separate worktrees; they work on the same repo by default. So if your parallel tasks need to modify overlapping files, you’ll need to configure worktrees in .cursor/worktrees.json.

While the feature sounds great, I’m yet to see how useful this feature actually is (I’m on an older version of Cursor). At least the people I spoke to haven’t really used it as much.

Multi-models mode: This feature has been there for a while. Cursor gives you an option to run any given tasks in parallel with multiple models. You can compare the results, review each model’s code separately and pick the best one. You do this by selecting multiple models in the model picker dropdown. Each model gets its own worktree for making code changes to avoid overlapping code changes.

In many organizations, this feature is disabled since this can easily lead to 3x or 5x the cost of the feature development.

Plan-Build-Review: This is not a feature per se but rather a workflow. You can set up workflows where one model implements, another reviews, and a third checks for style or performance issues. People describe this as “Claude plans, Codex reviews, Composer builds” inside Cursor. Cursor community workflows show patterns like “plan → build → review” with separate agents for each stage.

To summarize, in the wild, Cursor users are doing things like:

• Running a planning agent to break down a large feature, then handing slices to separate implementation agents.

• Using one agent for UI work, another for backend logic, and another for copywriting or docs.

• Launching multiple agents to try different approaches to the same problem, then comparing results.

You could very well call it a multi-agent workflow, but it’s more orchestrated parallelism than a single “team lead” directing everything. Cursor gives the tools for you to design the team structure.

3. Codex: The specialist in a pipeline

OpenAI’s Codex is best thought of as a powerful coding agent that can be slotted into a larger workflow. It’s explicitly asynchronous: you submit a task, and Codex works independently in the background, often returning a pull request with diffs, test results, and explanations.

In advanced setups, people are using Codex as one role in a multi-agent system:

• An external orchestrator (like the OpenAI Agents SDK or a Pydantic AI process) drives Codex as an MCP server in a star topology.

• Codex handles implementation or review, while other agents handle planning, documentation, or security checks.

• Some workflows report significant token savings and higher task success rates when Codex is part of a well-structured multi-agent harness.

Codex itself doesn’t have a public “agent teams” feature in the same sense as Claude. Instead, it’s the specialist builder/reviewer that other tools orchestrate around.

So, are people actually using multiple agents?

Yes, but in very specific patterns, not general “AI swarms.”

The most common real-world multi-agent patterns are:

1. Plan / build / review. One agent defines scope, one implements, one checks quality. This shows up in Cursor, Claude, and Codex-based workflows.

2. Parallel research or hypothesis testing. Multiple agents explore different angles, then synthesize. This is classic in Claude Agent Teams for debugging or strategy work.

3. Role specialization. Separate agents handle UI, backend, tests, copy, docs, or security. Cursor examples show UI/coding/copywriting agents running in parallel.

4. Best-of-N model comparison. Run the same prompt through multiple models, then pick the best output. Cursor’s /best-of-n is built exactly for this.kimi+1

5. Long-task splitting. Break a big project into smaller ownership slices so agents don’t clash in the same context or file set. This is where Cursor’s worktrees and Claude’s task lists shine.

Non-coding use cases are emerging too: content repurposing, marketing campaign planning, RFP/proposal drafting, and sales-call-to-asset pipelines. But they’re still a smaller slice of the overall activity compared to coding and technical workflows.

Why not just use one super-agent?

If models are getting smarter, why bother with multiple agents? I believe there are three reasons why it’s better than a single agent:

• Context loss. Single agents tend to forget earlier decisions or introduce inconsistencies as tasks grow. Splitting work across agents with focused context windows helps.

• Parallelism. Instead of waiting for one agent to do everything sequentially, you can run several in parallel and synthesize the results.

• Specialization and review. Different agents can be tuned for different roles (planner, coder, reviewer, writer), and having separate agents check each other’s work reduces errors.

Should you have FOMO for not using multi-agents?

The biggest tell that the multi-agent pattern is not in vogue yet is that, as of now, across the tools, there is only one true “Agent teams” feature, which is available in Claude Code, and even that is still experimental. So you’re not far behind for not using it.

Very few developers I’ve spoken to have actually used multi-agents and multi-agent loops. The ones who have used it, did so only a couple of times for doing large refactoring or large feature development. Even for large tasks thrown at multi-agents and loops, people reported completing the tasks within 1- 3 hours. So my guess is, there are not very many tasks that require such horsepower. And even for those tasks, people tend to resort to human planning and parallel task delegations to “human teams” rather than “agent teams”.

The bottom line

People are using multiple agents simultaneously, but not as a sci-fi swarm as of today. They’re using them as structured workflows: plan/build/review, parallel research, role specialisation, best-of-N comparison, and long-task splitting.

Claude’s Agent Teams give you the closest thing to a real coordinated team, with shared task lists, peer-to-peer messaging, and file locking. Cursor gives you a powerful orchestration workspace with /best-of-n, multi-model review, and git worktrees. Codex slots in as a specialist coding agent inside larger pipelines.

If you’re not using Agent Teams, you probably aren’t missing out on a lot. But I still think it’s a good skill to acquire for the future as we move from more human teams to agent teams, bigger/complex tasks per engineer and better and cheaper models.

Memory is the building block that decides whether a loop actually gets better over time or just repeats the same mistake on a schedule. A loop without memory runs fine every single time, and every single time it starts from zero, re-reading the codebase, re-deriving conclusions it already reached, and sometimes retrying the exact fix that failed yesterday because nothing told it that fix already failed.

That’s the failure mode this post is about, not a crash or an error, but a loop that works, technically, while quietly wasting a share of every run relearning what it already knew.

What memory actually is in a loop

People conflate memory with two other things, so it’s worth being precise about what it isn’t before getting into what it is.

Memory is not the context window. A Claude Code session holds a conversation in its context window while it’s running, and that context disappears the moment the session ends. If a loop kicks off a fresh session every morning, that session has no idea what happened yesterday unless something outside the session told it. The context window is short-term and session-scoped, and memory has to survive past that.

Memory is not a skill either. A SKILL.md file holds project conventions: how to run tests, how PR titles should be formatted, which files are off-limits. That information is static. It doesn’t change from one loop run to the next, which is exactly why it belongs in a skill and gets loaded fresh every time. Memory is the opposite. It’s the part that does change every run, because it’s a record of what actually happened: which issues got triaged, which fix attempt failed and why, what the loop is currently waiting on. A skill tells the loop how to work. Memory tells it what’s already been done.

In practice, four things need to persist across runs: the decisions the loop made and the reasoning behind them, so a later run or a human reviewing the log understands why the code looks the way it does; what failed and why, so the loop doesn’t burn a turn retrying an approach that’s already been ruled out; the current status against whatever goal the loop is working toward, so an interrupted run can resume instead of restarting; and handoff notes for whoever picks this up next, whether that’s another agent or a person reading the standup summary the next morning.

Three memory patterns, with a real example

The simplest pattern, and the one worth starting with by default, is a flat markdown file. In the GitHub triage loop from my first post, the triage agent wrote its classifications to a triage.md file, and issues that failed review got logged to flagged.md. That’s memory in its most basic form, a plain text file that any agent can read and write, that a human can open and understand without any tooling, and that lives in git so changes to it are tracked the same way code changes are. For a solo project or a small team, this is usually enough, and it’s the pattern I’d default to.

One practical question comes up immediately with this pattern: does the memory file belong in the main branch alongside the code, or somewhere separate? Committing it to main means every commit that touches code can also show what the loop was thinking at the time, useful for a human reviewing history later. The tradeoff is that a fast-growing memory file adds noise to the commit log for a directory nobody but the loop reads day to day. A middle ground that works well in practice is keeping the memory file in its own directory, committed but excluded from normal code review, so it’s tracked and diffable without cluttering pull requests built around actual code changes.

The second pattern is a task tracker, meaning Linear, GitHub Issues, or something similar. This is worth reaching for when the state needs to be visible to humans and other agents at the same time, and when the workflow already has native states worth plugging into, like open, in review, or blocked. If the fix agent from the triage loop opened a PR and linked it to a GitHub issue, the issue itself becomes part of the memory. It carries status, comments, and history that both people and agents can read without any of that structure being built by hand.

The third pattern is a structured store, either a database or a vector store for semantic recall. This is the heaviest option, and it’s only worth the added complexity once a loop has enough history that a flat file becomes hard to search, or once the loop needs semantic lookup rather than exact text matching, like finding issues related to auth timeouts rather than issues containing the literal string “timeout.” If a loop hasn’t run into that problem yet, this pattern is premature. Start with the flat file.

Let’s take another example where the choice of memory becomes important. Think of a content pipeline loop that runs weekly, drafts LinkedIn and X posts repurposing a new Substack article, and checks whether a similar angle has already been published so it doesn’t repeat itself. Whether a draft has already shipped is a flat-file lookup, easy to check against a running log. Whether a similar angle has already been covered is a different kind of question, because two posts can cover the same underlying idea in completely different wording. That’s a semantic question, not an exact-match one, which is exactly the kind of case a vector store earns its complexity for, embedding summaries of past posts and querying by meaning instead of by keyword.

Here’s how the flat file pattern gets wired in so updates happen automatically instead of depending on the agent remembering to do it. Two hooks handle this: SessionStart, which fires when a new session begins, and Stop, which fires when the agent finishes.

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "cat memory/loop-state.md"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo \"## Run $(date -u +%Y-%m-%dT%H:%M:%SZ)\" >> memory/loop-state.md"
          }
        ]
      }
    ]
  }
}

The SessionStart hook reads the memory file into context before the loop does anything else, so every run begins with what the previous run learned instead of starting cold. The Stop hook appends a timestamped entry when the run finishes. In practice the agent itself would write the substantive content, meaning what it decided, what failed, and what’s still open, rather than a bare timestamp, but the hook guarantees the update happens every run regardless of whether the agent remembers to do it as part of its own instructions.

Where memory breaks

The first failure mode is staleness. Nobody prunes the file, so it grows every run, and eventually the loop spends a real share of its token budget reading history that’s no longer relevant to the current task. A huge memory file needs either a pruning step, dropping entries older than a set number of runs, or a summarization step that compresses old entries into a shorter record, built into the loop itself. Treat this the same way you’d treat log rotation. It stops being optional past a certain scale.

The second failure mode is drift, and it shows up specifically when more than one agent writes to the same memory file. If two fix agents are running in separate worktrees and both try to append to the same flagged.md, the writes can interleave or overwrite each other depending on how the hook is set up. This is the same coordination problem I’ll get into in more depth in the post on parallel agents, but the short version is that a shared memory file needs a single owner. Either one agent, usually a main orchestrating agent, is the only one allowed to write to it, or each parallel agent writes to its own file and something merges them afterward.

The third failure mode is treating memory as a dumping ground instead of a curated record. If a loop logs everything it does, including routine steps that didn’t fail and didn’t require a decision, the memory file stops being useful because a reader, agent or human, has to wade through noise to find what mattered. The rule I use is that memory should record decisions, failures, and open questions, not a transcript of every action taken. If a step went exactly as expected and required no judgment call, it doesn’t need an entry.

A dumping-ground entry looks like this: “Ran tests, all passed. Checked lint, no errors. Reviewed auth.ts, looks fine. Moved to next file.” None of that required a decision, so none of it earns a place in memory. A curated entry for the same run looks like this instead: “Auth module refactor: skipped the token-refresh function because it touches session storage directly. Flagged for human review per the SKILL.md rule on auth changes. Tests pass on everything else.” The second version is shorter, and it’s also the only one a later run, or a human, actually needs to read.

There’s a fourth failure mode worth naming separately, because it’s specific to the hook pattern shown earlier rather than a general memory design mistake. The Stop hook fires once per turn, meaning once every time Claude finishes responding, not once at the true end of a multi-turn loop. A /goal loop with --max-turns 30 can run through many of those turns before the evaluator confirms the goal is met, and the plain append-on-Stop pattern from earlier would write one timestamped entry for every one of those turns instead of a single entry summarizing the finished run. This distinction doesn’t matter for a loop that only ever runs one turn per invocation, like the cron-triggered triage loop from my first post, since one turn and one run are the same thing there. It matters for anything using /goal with a real turn budget, where dozens of turns can happen inside a single run.

The fix is to be more deliberate about what the Stop hook actually does. Stop hooks can block Claude from actually stopping, which means a Stop hook can check whether the agent has written a real memory update this run and push Claude to do it before the session is allowed to end, instead of blindly appending a timestamp on every single trigger.

When memory becomes a skill

There’s a natural next step once a memory file has been running for a while: some entries stop being one-off history and start being a pattern. If a memory file shows the same kind of failure across several runs, the same edge case tripping up the loop three separate times, that stops being a fact about one run and becomes a convention the loop should have known from the start.

That’s the moment to move it out of memory and into the SKILL.md. Memory holds “this specific run hit this specific problem.” A skill holds “this class of problem always gets handled this way.” The migration is straightforward: read back through memory for entries that keep recurring, generalise the specific case into a rule, and add it to the skill so every future run starts already knowing it instead of rediscovering it. I’ve written about what makes a skill worth keeping in my two-part series on Claude Code skills; the short version is that this graduation path, from a repeated memory entry to a permanent skill rule, is one of the more reliable ways a skill earns its place instead of rotting.

To summarise, there are three things to carry out of this. Memory is distinct from both the context window and a skill: the context window is session-scoped and disappears, a skill is static and doesn’t change run to run, and memory is the dynamic record of what actually happened. You can start with a flat markdown file before reaching for a task tracker or a database, because most loops never actually outgrow it. And you should wire memory updates into hooks, SessionStart to read and Stop to write, so the update happens automatically instead of depending on the agent remembering to do it as one more instruction among many.

The loop that seems to be running fine but never gets any better is usually missing this piece, not because it’s broken, but because it has no way to remember what already happened.

Next in this series, I’m covering parallel agents: worktrees, sub-agents, and Claude Code’s newer Agent Teams feature, and how to actually run several agents on the same problem without their state colliding, which is the drift problem from this post at a larger scale.

The examples and commands in this post are Claude Code-specific, but the core concepts apply to other agentic coding tools too: Codex, Cursor, and similar. The primitives have different names but the shape is the same. This post is also somewhat engineering heavy, but there is enough takeaways for non-tech folks as well.

Loop engineering is having a moment. It has been the hot topic in the AI community for many weeks now. Boris Cherny, the head of Claude Code at Anthropic, said “I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” Peter Steinberger, the author of OpenClaw said it similarly: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Addy Osmani wrote a strong conceptual piece on this. If you want to understand the framework, read that first.

What I wanted after reading it was the implementation guide: actual hook configs, real sub-agent setups, a complete working example, and an honest answer to questions like “how many turns should I let this run?” and “when does a human still need to be involved?” For many people promoting loop engineering including Peter, token costs are not a real constraint. But the failure modes of loops are underreported.

That’s what this post covers.

The shift from prompting to designing

For the past two years, working with a coding agent meant you typed something, read what came back, and typed the next thing. The agent was a tool and you were holding it turn by turn.

Loop engineering flips this. Instead of you doing the prompting, you design a system that does it for you. Addy Osmani’s framing is right: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

Loops can be quite elaborate, like the one we’ll talk about below - one that automates small bug fixes and features in the code base - but they can also be fairly simple. An example of a simple loop could be a cron job which summarizes all my emails for me every morning and gives me the action items for the day. Claude Code has a built-in feature that allows you to implement some of these simpler loops called “Routines”.

Building a loop

Claude Code gives you two core commands to build your own custom loops:

/goal lets you define a finish line. You give it a verifiable condition, and Claude keeps working turn after turn until a separate, smaller model confirms that condition is true. The important detail is that the model checking whether you’re done is different from the one doing the work. The maker doesn’t grade its own homework.

/goal "all tests in /auth pass, eslint reports zero errors, and no file over 200 lines"

/loop re-runs a prompt on a time interval. You define what to check and how often, and it keeps running until you stop it.

/loop 10m tail the last 100 lines of deploy.log and alert me to any ERROR patterns

The difference is that /goal stops when a condition is met, while /loop stops when you say so. Either way, you’re out of the turn-by-turn cycle.

You can also cap how many turns a /goal runs with the --max-turns flag. Without it, a loop on a vague goal will run until it hits API limits or your monthly credit pool. More on that later.

The 5 building blocks: what they actually look like in code

Addy’s post identifies five things a loop needs and explains the concept well. I’m not going to re-explain the theory. But I’m going to show you the configs.

1. Automations: the heartbeat

Automations are what make a loop run without you triggering it manually. In Claude Code this means scheduled tasks (cron), /loop, and hooks.

A cron-style scheduled task is exactly what it sounds like: the loop runs at a set time every day. You can also use GitHub Actions to trigger a Claude Code session on a push or PR event, so the loop runs in CI without a human kicking it off.

Hooks are the more granular version. They fire at specific points in Claude’s lifecycle during a session: before a tool runs (PreToolUse), after a tool runs (PostToolUse), at session start, at session end, and when the agent stops.

You configure them in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\" && npm run lint --silent"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo $CLAUDE_TOOL_INPUT_COMMAND | grep -qE 'rm -rf|DROP TABLE|truncate' && exit 2 || exit 0"
          }
        ]
      }
    ]
  }
}

The PostToolUse hook here auto-formats and lints every file Claude writes. You never manually run Prettier again inside a loop. The PreToolUse hook reads every Bash command before Claude runs it and blocks anything matching rm -rf, DROP TABLE, or truncate by exiting with code 2. Claude sees the block and has to find another way.

This is the right place to put safety rails. Not in the goal description, where Claude might work around them, but in the hook, which runs unconditionally.

I’m working on a dedicated post that goes deeper into hook configs and safety-rail patterns. Stay tuned.

2. Worktrees: isolation for parallel work

If you run two agents against the same codebase at the same time without isolation, they write to the same files, causing their changes to collide. A git worktree fixes this. It’s a separate working directory on its own branch that shares the repo’s history, so each agent’s writes are completely isolated from the others.

In Claude Code, you get this with isolation: "worktree" when spawning a sub-agent:

Task("refactor the payments module to use the new SDK", isolation: "worktree")

The sub-agent gets a fresh checkout, makes its changes, and the worktree is cleaned up after. Use this by default on any sub-agent that writes code. The cost is nothing; but the upside is that parallel agents stop colliding with each other’s work.

I’ll cover worktree patterns for parallel agents in more depth in an upcoming post.

3. Skills: project knowledge that persists

We’ve already covered skills in great detail in the previous two posts. To recap - A SKILL.md file is project knowledge written down outside the context window. Conventions, build steps, naming patterns, things to avoid and why. Without a skill, the loop starts cold every run and re-derives everything from scratch. With a skill, it starts with context.

Here’s a minimal example:

---
name: repo-conventions
description: Project conventions for the payments service
---

Testing: always run `npm test -- --testPathPattern=<changed-file>` not the full suite.
PR format: title must be [type]: description. Types: feat, fix, chore, refactor.
Never modify migrations directly. Create a new one with `npm run migration:create`.
Auth changes require a second human review before merging. Always flag these.

The skill is why the loop doesn’t have to be told the same things every run. I covered the deeper relationship between specs and skills in my earlier post on spec-driven development, and I’ve published a two-part deep dive specifically on skills: what they are, how triggering actually works, and how to write skills that compound instead of rot. The short version is that a tight SKILL.md is a prerequisite for a reliable loop.

4. Plugins and connectors: the loop touches real tools

A loop that can only see the filesystem is limited. MCP connectors plug the agent into your actual environment: GitHub to read issues and open PRs, Linear to update tickets, Slack to post summaries, a database to query state.

Once a connector is installed, the agent can act inside your workflow instead of just producing output that you then have to act on yourself. The difference between a loop that says “here’s the fix” and one that opens the PR, links the ticket, and posts to your team’s Slack channel is entirely down to connectors.

5. Sub-agents: separating the maker from the checker

Sub-agents are specialized Claude instances with their own context window, system prompt, tool list, and permissions. You define them as markdown files in .claude/agents/:

---
name: code-reviewer
description: Reviews code changes for quality, correctness, and adherence to repo conventions
tools: Read, Glob, Grep
model: claude-sonnet-4-6
---

Review the code changes given to you. Check for:
- Security issues, especially in auth and input validation
- Adherence to conventions in the repo SKILL.md
- Test coverage for any new logic
- Functions over 50 lines that should be split

Return a structured review: blockers (must fix), suggestions (optional improvements), and a pass/fail verdict.

The main reason to use sub-agents isn’t parallelism. It’s separation. The agent that wrote the code will be generous when reviewing its own output. A separate agent with different instructions catches what the first one missed. Keep it to 3-5 concurrent sub-agents maximum. If you add more than that, the rate limits kick in, and the parent agent spends most of its tokens just orchestrating.

Plus the sixth thing, which Addy correctly calls the spine: memory. A Markdown file, a Linear board, anything external that holds state between runs. Agents forget everything when a session ends. The memory file helps the agents retain the memory.

I’m planning a dedicated post on designing sub-agent systems in more depth as well as memory and state patterns. Stay tuned.

A complete loop: all 5 in action

Here is what a real loop looks like with all five components working together. The scenario is that a team wants to automatically triage GitHub issues every morning, draft fixes for the simple ones, and leave the rest categorised for the engineering standup.

The setup:

.claude/
  agents/
    triage-agent.md      # reads issues, classifies them
    fix-agent.md         # attempts fixes in isolated worktrees
    review-agent.md      # checks fixes against conventions
  settings.json          # hooks for linting and safety gates
skills/
  repo-conventions.md    # conventions SKILL.md

How the loop runs (9am cron trigger):

The main agent kicks off the triage agent, which reads open GitHub issues via the GitHub MCP connector and classifies each one: quick fix, needs investigation, or feature request. This classification is written to a triage.md file (the memory).

For each issue marked as a quick fix, the main agent spawns a fix agent with isolation: "worktree". Each fix agent gets its own branch, reads the relevant code, and writes a fix. The PostToolUse hook runs lint automatically after each file write. The fix agent runs the targeted test suite, not the full suite (that distinction is specified in the skill).

Each fix is then handed to the review agent, which reads the diff and checks it against the conventions skill. If the review passes, the GitHub connector opens a draft PR, links the issue, and posts a summary to the team’s Slack channel. If it fails, the issue goes into flagged.md with the review notes attached.

The main agent finishes by writing a standup summary: what was fixed, what was flagged, and what needs a human.

You arrive in the morning with context, draft PRs, and a clear list of what still needs your attention.

Loops need tight goals, or they’ll go sideways confidently

A loop is only as good as the goal you give it. A vague goal like “clean up the codebase” will produce confident, well-structured work in a direction you didn’t intend. Claude won’t stop and ask. It will run, and it will run far.

A tight goal gives the loop something to verify against. An example of this could be something like “refactor the auth module so every function has a JSDoc comment, all existing tests still pass, and no new files are created”. The evaluator model has a real bar to check.

This is also why skills matter so much inside loops. They encode the standards the loop should meet, so you don’t have to restate your conventions in every goal you write. A tight goal plus a good skill is a reliable loop. A vague goal without a skill results in a very expensive experiment.

Where this gets hard

How many turns before you intervene?

While it sounds great to have loops, they’re also a risky if not used properly and for the right usecases. As they can very well go on a tangent if left unsupervised and if an agent sets its mind on a wrong solution, it is very important to set some guard-rails around loops. One good habit is to always set --max-turns on any /goal that isn’t trivial. I’d actually say that you should always set this, irrespective of the task. This limits the number of iterations an agent would go through while pursuing a goal. Below are some good default:

• Simple tasks (fix a specific test, update a config): 10-15 turns

• Medium tasks (refactor a module, add a feature with tests): 25-40 turns

• Complex tasks (cross-cutting changes, multi-file refactors): 50 turns max, with a checkpoint

Below are three signs the loop needs human intervention regardless of where it is on the counter: the same error appears three or more times in a row (the agent is stuck, not making progress), the agent starts rewriting things outside the scope of the goal (it’s gone off track), or the cost has crossed a threshold you set upfront and progress isn’t visible.

You can estimate the cost before running a loop. A 30-turn loop with Claude Sonnet at roughly 5,000 input tokens and 1,000 output tokens per turn costs approximately $0.50-$0.60 at Sonnet 5’s introductory pricing (through August 31, 2026); expect that to run closer to $0.90 once standard per-token rates take effect. Either way, that’s cheap. A 100-turn loop that went sideways at turn 20 and kept going is $2-3 of output you’ll throw away regardless of pricing tier. So always set a max-turns limit before you walk away.

When humans must be in the loop

Loop engineering doesn’t eliminate human judgment. It changes where you apply it. Some decisions should never be delegated to an unattended agent:

Database migrations. Creating a new migration is fine to automate. But modifying an existing one or running a migration against production data requires a human to verify the before and after states. You should probably put this in your SKILL.md and block it in a PreToolUse hook.

Security and auth changes. Any change to authentication logic, permissions, or environment configuration should require explicit human sign-off. These are the changes that are hardest to reverse and easiest to get subtly wrong. Again, put this in the skill and flag it in the review agent.

When the agent fails the same subtask more than twice. Repeated failure on the same step is usually a signal that the goal is ambiguous or the agent is missing context it can’t derive from the codebase. At this point you intervene, add context, and restart. Don’t let it keep going.

Code review before merging to main. The review sub-agent is useful for catching obvious issues and convention violations. It is not a replacement for a human reviewing what’s going into the main branch. Keep that step human, always.

Any time the goal is ambiguous enough that you’re unsure what a correct output looks like. If you can’t write a clear verification condition, you can’t run an unattended loop. Write the condition first. If you can’t, the task isn’t ready for a loop yet.

Should you go crazy with loops?

Boris Cherny, Peter Steinberger, Addy Osmani. These are people for whom token costs are not a meaningful constraint. When they say “I don’t prompt anymore, I write loops”, they are not thinking about whether they can afford the bill.

Most developers are not in that position. And agents go off-track more than the demos suggest. They make assumptions, fix the wrong thing, and in an unattended loop, they keep going confidently in the wrong direction for a long time before you notice.

Loops are worth learning and worth building. But it’s better to start small: one automation, a tight goal, a clear verification condition, a human checkpoint before any PR merges. Run the first few turns, watching before you step away.

This is the first post in what’s going to be a longer series. I’m planning dedicated deep dives on hooks, worktrees, sub-agents, memory and state, and more, each one going further than I could here. If a section above left you wanting more, that’s the plan. Subscribe if you want those in your inbox as they go up.

This is the second part of the two-part series on Skills. In part one, I covered what skills are, why triggering fails, and the difference between soft and hard enforcement. If you haven’t read that, start there.

This post is about everything that comes after. Say you’ve written a skill and it works. What comes next? Most skills I’ve seen start out useful and quietly get worse. Not because the feature is flawed, but because skills encode assumptions, and assumptions go stale. This post is about how to write skills that don’t rot, how to manage them at scale, and how to build the kind of maintenance habit that keeps a skill library useful rather than just large.

Why most skills rot

A skill is only as good as how accurately it reflects current reality. When you write it, that accuracy is high. Six months later, it might not be.

The reason is that skills encode specifics: file paths, command sequences, team structure, tool names, workflow steps. All of those things change. A deploy skill written when your team used one CI setup silently misleads Claude after you switch to another. A skill referencing a directory that got renamed does nothing. Or worse, it does the wrong thing quietly. A skill that assumed a particular branching strategy becomes confusing when the team adopts trunk-based development.

The problem is not just that the skill stops working. It’s that it continues to look authoritative while being wrong and Claude follows it. The output looks plausible so you don’t notice the drift until something breaks or someone new on the team asks why Claude keeps doing a thing that stopped being correct three months ago.

You don’t have to avoid specifics entirely but be careful adding them and keep revisiting them.

Writing for longevity

The most durable skills share a few properties. They avoid hardcoded paths. They explain the reasoning behind instructions, not just the instructions themselves. And they’re written as if a new engineer who has never seen the codebase would read them on their first day.

No hardcoded paths. Absolute paths are the fastest way to make a skill brittle. If your skill says “run this command from /home/user/projects/myapp“, it breaks the moment anyone else uses it, or the moment the project moves. Use relative references, or write the instruction in a way that lets Claude discover the right location.

Write the why, not just the what. This is the most underused principle in skill writing, and it’s also the most powerful. When Claude understands the intent behind an instruction, it can adapt when the specifics change. When it only has the instruction, it follows it literally or fails.

Brittle instruction:

“Always use the feature/ prefix for branch names.”

Durable instruction:

“Use the feature/ prefix for branch names to keep feature work distinguishable from hotfixes and releases in the branch list. If the team’s convention has changed, follow whatever current convention achieves that same clarity.”

Write it for a new engineer on day one. This framing is useful because a new engineer has no implicit context. If a skill only makes sense to someone who already knows the system, it’s not doing the work it should be. Skills written for a new engineer tend to be more explicit about reasoning, more likely to include the why, and less likely to rely on assumptions that aren’t stated.

The CLAUDE.md versus skill question also becomes important as the codebase grows. A useful rule of thumb is that if something has grown from a fact into a procedure, it belongs in a skill, not CLAUDE.md. But the reverse matters too. If a skill has grown to contain a lot of standing facts that apply everywhere, some of it probably belongs back in CLAUDE.md. Keep CLAUDE.md as the source of truth for things that are always true. Keep skills as the source of truth for specific workflows.

Token efficiency in practice

Skills have a cost that most people don’t account for until they notice something going wrong.

Here is how the math works. Claude Code’s context has a compaction threshold. When a session gets long enough that Claude needs to summarize earlier conversation to free up space, it re-attaches loaded skills with a combined budget of 25,000 tokens, keeping the first 5,000 tokens of each. If you’ve loaded three skills in a session, each gets up to 5,000 tokens. If you’ve loaded ten, they share the 25,000 token pool and the ones loaded earliest tend to lose content first.

A 600-line SKILL.md file is not just a large file. It’s up to 5,000 tokens burning in your context for the rest of that session, whether or not you need all of it. And after compaction, it might only partially survive anyway.

The practical response to this is to keep the SKILL.md lean and move detail to linked reference files.

Reference files are separate markdown files in the skill directory that Claude can load on demand when the skill instructs it to. They don’t load automatically. Claude reads them only when the skill body tells it to, meaning they don’t burn the description budget or compaction budget until they’re actually needed.

A well-structured skill looks like this: the SKILL.md contains the core workflow and decision logic, and it references a separate file for detailed API documentation, a separate file for edge cases, and a separate file for examples. Under five hundred lines in the main file. The rest lives alongside it but out of the hot path.

The signal to split a skill rather than reorganize it is whether you can describe what it does in one sentence. If you can’t, it’s doing too much. A skill that handles both code review and deployment is two skills pretending to be one. Split it. Focused skills trigger more reliably, cost less per use, and are easier to keep current.

How many is too many

You need to budget your skill descriptions against your overall context window.

All skill descriptions are loaded together into Claude’s context so it can decide which skill to use for a given request. That combined listing has a default size limit of one percent of the model’s context window. For a 200,000-token context window, that’s 2,000 tokens for all descriptions. A well-written description averages 50 to 100 tokens. That puts the practical ceiling somewhere between 20 and 40 skills before descriptions start getting trimmed.

When descriptions get trimmed, skills stop triggering, and they do it silently. You won’t see an error. The skill just won’t run when you’d expect it to.

You’ve crossed the line when a skill that used to trigger automatically no longer does. When that happens, the answer is not to just remove a few skills. The answer is to audit what you have and consolidate or delete anything that isn’t important.

Team patterns

Skills in a shared repository behave differently from personal skills, and both have a role.

Skills checked into the repo under .claude/skills/ are available to everyone who checks out the code. They travel with the codebase. This is where team workflow knowledge lives: how to run tests, how to structure a PR, what the deployment process looks like, how to handle migrations. When a new engineer checks out the repo, they inherit the team’s accumulated operational knowledge without anyone having to explain it.

Personal skills under ~/.claude/skills/ are local to your machine. They don’t go into the repo. This is the right place for things that are specific to your setup or your personal workflow quirks. A skill for your preferred way of structuring a commit message. A skill for the local tools you use that your teammates don’t.

It is worth treating SKILL.md changes in pull requests with the same review attention as any other documentation. If a code change makes a skill inaccurate, the PR should update the skill. If a process changes and the skill still describes the old process, that’s a documentation bug in the same category as outdated comments or stale README sections. The review question to ask is the same as for any doc: does this still reflect how things actually work?

Onboarding is where a healthy skill library becomes visible. A new engineer who checks out the repo and finds that Claude already knows how to deploy, how to run the test suite, how to file a bug, and what the branching conventions are. That’s the outcome of a well-maintained skill library.

Maintenance and the audit habit

A good skill library requires regular maintenance. Since skills can quietly go stale.

The two tools for diagnosing whether skills are actually working are /doctor and --debug. Running /doctor shows you which skills are loading, which descriptions are being trimmed, and which might not be reaching Claude at all. Running Claude Code with the --debug flag surfaces YAML parse errors and other silent failures that keep skills from triggering. If a skill you expect to see active isn’t showing up, one of those two commands will usually tell you why.

Beyond diagnosis, a periodic audit can help greatly. Quarterly is a reasonable cadence for most projects, though a team that changes fast might want monthly. The audit has a few simple questions:

Which skills triggered in the last month? The /doctor output and session logs give you a rough picture. A skill that hasn’t triggered in a month might have a description problem, might have drifted from current reality, or might simply no longer be needed.

For skills that did trigger, check whether the output is still what you want. If Claude is doing technically what the skill says but the result is no longer right, the skill has drifted. Update it or retire it.

For skills that didn’t trigger, check whether the description is still accurate and whether the skill still describes something useful. If the answer to either is no, delete it.

Before you build the next skill

Skills are effective when they encode clear, repeatable knowledge about how to do something specific. If you genuinely have a repeatable workflow that Claude should know about, write the skill. Write the why. Keep it lean. Review it when the workflow changes. That’ll keep Claude away from unexpected edge cases.

If you’ve set up a skill in Claude Code and watched Claude ignore it, you’re not alone. Or maybe you’ve written what felt like a thorough skill and found Claude only follows it sometimes. Both of these are more common than the documentation lets on, and both have specific reasons.

This post is about those reasons: what skills actually are, why triggering fails in ways that aren’t obvious, and the honest answer to whether “always do X” in a skill actually means always. Although this article refers to Claude, it applies equally to any other tool/agent of your choice.

This is part one of a two-part series. Part two covers writing skills that compound over time, token efficiency, and team patterns.

What a skill actually is

A skill is a directory with a SKILL.md file inside. The file has two parts: YAML frontmatter at the top (which tells Claude when to use the skill) and markdown content below (which Claude follows when the skill runs).

my-skill/
├── SKILL.md        # Required
├── reference.md    # Optional — detailed docs loaded on demand
└── scripts/
    └── helper.py   # Optional — scripts Claude can execute

The first thing most people miss is that skills are not always loaded into Claude’s context. Only the skill name and description are. The full body (the instructions, the step-by-step procedures, all of it) stays dormant until the skill is actually invoked. Claude Code calls this lazy loading, and it matters a lot for how you think about skills.

The upside is that you can install dozens of skills without bloating your context on every turn. The cost only hits when the skill runs. The downside is that Claude’s decision to use a skill depends entirely on whether the description matches what you asked, and that is a much narrower window than most people expect.

Once a skill loads, its content remains in context for the rest of that session. But there’s a catch here too: after compaction (when Claude summarises older conversations to free up space), skills are re-attached with a combined budget of 25,000 tokens, keeping the first 5,000 tokens of each. If you’ve invoked many skills in one session, older ones can be dropped entirely. If a skill suddenly stops influencing behavior mid-session, this is usually why. Re-invoking it with /skill-name brings it back.

Skills, CLAUDE.md, and MCP: what goes where

It tooks some time for me to get clarity on which one to use when. The confusion here is understandable because they all feel like “instructions for Claude.” But they’re not the same thing.

CLAUDE.md is always in context. Every session, every turn, Claude reads it before anything else. Put facts that always apply here: your tech stack, naming conventions, things to never do. The test is: does this need to influence everything Claude does, even when it’s just answering a question? If yes, CLAUDE.md.

Skills are loaded on demand. The right signal for extracting something from CLAUDE.md into a skill: when a section has grown into a procedure rather than a fact. “Use REST naming conventions” is a fact. “When deploying, first run tests, then build, then push, then verify” is a procedure. The procedure belongs in a skill.

MCP gives Claude capabilities: things it can do. Connect to GitHub, query a database, post to Slack. Skills give Claude knowledge and instructions: how to behave. They’re complementary. A skill can specify which MCP tools it’s allowed to call while it’s active, scoping permissions to just what that workflow needs.

Sub-agents are separate Claude instances with their own context window. A skill can run inside a sub-agent by adding context: fork to its frontmatter, which makes the skill content become the sub-agent’s task. But a sub-agent is an execution environment. A skill is the instructions it runs. They’re not the same layer.

One more thing worth knowing: Claude Code skills follow the AgentSkills open standard. A SKILL.md file you write for Claude Code also works in Codex. The format is shared, so skills you build aren’t locked to one tool.

The triggering problem

This is something which took some time for me to figure out and it’s the reason skills appear to be ignored sometimes by your agent.

The description field is the only thing Claude reads when deciding whether to use a skill. Claude reads the description, not the skill name or the body (plus an optional when_to_use field you can append).

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
when_to_use: Also use when the user says "what did I do", "show me my changes", or asks for a git summary.
---

Here’s what surprised me the most: Claude matches the description against the exact phrases you type. If your description says “summarizes git diffs” and you ask “what did I change today?”, those don’t match, and the skill doesn’t load. The description isn’t just a label for what the skill does. It’s the trigger condition, and it needs to include the natural language your users actually reach for.

This means writing a good description requires thinking less like a developer naming a function and more like someone anticipating how a person would ask for the thing. What would someone type before they even know this skill exists? Those phrases should be in the description.

A few other things that silently kill triggering:

Malformed YAML frontmatter. If the frontmatter has a syntax error, Claude Code loads the skill body with empty metadata. The skill still works when you manually type /skill-name, but Claude has no description to match against, so it never triggers automatically. The failure is silent. You won’t get an error. The skill just won’t run. Use --debug to catch parse errors.

The description budget. All skill descriptions are loaded into Claude’s context so it can decide which ones to use. That listing has a size limit: 1% of the model’s context window by default. If you have many skills, descriptions get trimmed to fit. The skills you invoke least lose their descriptions first, so the ones you actually use keep their full text. But if you’ve installed a lot of skills and notice one has stopped triggering, the budget is a likely culprit. Running /doctor shows you exactly which descriptions are being shortened or dropped.

disable-model-invocation: true in the frontmatter. If this is set, Claude never auto-triggers the skill. The description isn’t even shown to Claude. The skill only runs when you type /skill-name directly. This is intentional for some skills (deploy scripts, anything with side effects), but if you didn’t set it yourself and find it in a shared skill, that’s why Claude keeps ignoring it.

How enforceable are skills?

Skills are instructions to an LLM. “Always do X” in a skill body is a strong default, but it’s still not a contract. Claude will generally follow skill instructions, but it applies judgment and that means it can prioritize other things, miss instructions buried deep in a long skill, or simply choose differently.

The official Claude Code docs acknowledge this directly: “If a skill seems to stop influencing behavior after the first response, the content is usually still present and the model is choosing other tools or approaches. Strengthen the skill’s description and instructions so the model keeps preferring it, or use hooks to enforce behavior deterministically.”

That second option of using hooks, is the real answer when you need a hard guarantee. There are two tiers of enforcement in Claude Code, and understanding the difference is important.

Skills are soft enforcement. Claude reads the instructions and is strongly guided by them, but it’s making a judgment call, not executing a deterministic function. For most workflows, “strongly guided” is good enough.

Hooks and tool restrictions are hard enforcement. These cannot be overridden by Claude’s judgment. A PreToolUse hook configured in .claude/settings.json runs before every tool call. Similarly, the disallowed-tools frontmatter field removes specific tools from Claude’s available pool while a skill is active. It means, Claude literally cannot call them, not just won’t.

The practical rule: if a constraint matters enough that Claude ignoring it would be a real problem, don’t put it only in a skill instruction. Put it in a hook or a tool restriction.

Controlling when and whether skills run

Beyond the skill body, there are a few levers for controlling skill behavior that are worth knowing about.

The frontmatter fields disable-model-invocation and user-invocable let you set who can trigger a skill. disable-model-invocation: true means only you can run it by typing /skill-name. Claude won’t auto-trigger it, and the description isn’t even shown to Claude. You can use this for deploy scripts, commit flows, anything where you want explicit control over timing. user-invocable: false is the inverse. Claude can load it automatically when relevant, but it doesn’t show up in the / menu. Use this for background context the model should apply silently.

The skillOverrides setting in your settings file (or the /skills menu) lets you change a skill’s visibility without editing its SKILL.md. This matters when a skill is checked into a shared repo and you can’t edit it directly. You can set a skill to "off" to hide it from both Claude and the menu, "name-only" so Claude knows it exists but can’t auto-trigger it (useful for freeing description budget), or "user-invocable-only" so it stays in your / menu but Claude won’t load it on its own.

For teams, permission rules give you fine-grained control:

# Allow only specific skills
Skill(commit)
Skill(review-pr *)

# Block specific skills
Skill(deploy *)

And if you want to disable all skills across a session, adding Skill to your deny rules in /permissions does it.

The format question: .md, scripts, and what else can live in a skill

The SKILL.md itself is always markdown. That’s the format for the AgentSkills standard and it’s not configurable. Although, there has been a new trend of using HTML instead of markdown, notably by few Anthropic engineers. But a skill directory can bundle anything else: reference files, example outputs, executable scripts.

my-skill/
├── SKILL.md              # Core instructions + pointers to other files
├── api-reference.md      # Detailed API docs — referenced but not auto-loaded
└── scripts/
    └── generate.py       # Script Claude can run

Keep the SKILL.md concise: the docs recommend under 500 lines. Once it loads into context, every line is a recurring token cost for the rest of that session. Move detailed reference material to separate files and reference them from SKILL.md so Claude knows they’re there and when to read them.

One thing that’s not obvious but is very useful: the !`command` syntax runs a shell command before Claude sees the skill content. The output is inlined into the prompt before Claude reads anything:

## Current changes
!`git diff HEAD`

When this skill runs, git diff HEAD executes first and the output replaces that line. Claude receives the actual diff, not a command to run. This is preprocessing. It happens before the skill reaches Claude at all.

While the standard mandates the SKILL.md format to be markdown, a Python or shell script bundled with the skill can generate any output format: HTML reports, interactive visualizations, whatever you need. The skill body instructs Claude to run the script; the script handles the output.

Before you move on

The three things that cause the most silent failures in practice: descriptions that don’t match natural language, malformed YAML frontmatter, and putting hard constraints in skill instructions when they belong in hooks.

Part two covers the other half: writing skills that stay useful as the codebase changes, structuring them for token efficiency, how many is too many, and what a well-maintained skill library looks like for a team.

You can also listen to an audio version of this article on Spotify -

A few weeks ago, I was talking to another engineering leader about AI coding tools. His team had gone all in on the technology. Every engineer had access to AI-powered IDEs, they were experimenting with coding agents, and pull request creation had become faster than ever. Features that previously took days were being scaffolded in hours.

Then he told me the real problem: nobody felt faster. Several of his senior engineers actually felt busier than they had before AI arrived.

That contradiction stuck with me. At first glance, it sounds impossible. If AI can write code 5x faster, shouldn’t teams ship 5x faster? But the more I’ve thought about it, the more I believe we’re measuring the wrong thing. AI has dramatically accelerated code generation. It has not dramatically accelerated software delivery. And those are fundamentally not the same thing.

Funny thing is just a few days ago, AWS, the company that has been most upbeat about AI productivity and done tens of thousands of layoff recently due to AI tweeted this

The Cost of Creating Code Has Collapsed

For most of my career, writing code was expensive in terms of human time. An engineer would spend hours understanding a problem, researching solutions, implementing the feature, writing tests, fixing edge cases, and finally opening a pull request. The entire workflow was a deliberate, sequential process.

Today, that’s changed. A large portion of the implementation work can now be delegated to AI. Need an API endpoint? Generate it in seconds. Need tests? Generate those too. Need a migration script or documentation? Same story. What used to take a day can sometimes be produced in thirty minutes. From a pure productivity standpoint, that’s genuinely incredible.

But here’s what happens when the cost of creating code approaches zero: you get a lot more code. Not more progress. More code. There’s a meaningful difference between those two things, and I think that difference is at the heart of why shipping hasn’t actually sped up.

The Review Bottleneck Nobody Talks About

I’ve noticed a pattern across teams that use AI heavily: AI doesn’t eliminate work; it transfers it. Specifically, it shifts the effort from the person writing the code to the person reviewing it.

Before AI, an engineer might submit a 300-line pull request for review. With AI, that same engineer might submit 3,000 lines. The code compiles. The tests pass. The feature even works. But now someone has to actually review it.

And that’s not a trivial task. A reviewer needs to understand whether the implementation is secure, verify that the architecture is sound, determine whether this introduces future maintenance headaches, and decide whether the AI took the shortest path or the right path. The uncomfortable reality is that AI can generate answers much faster than humans can validate them.

Here’s what makes this matter: software engineering is fundamentally a profession built on trust. I don’t ship code because it exists. I ship code because I trust it, and that trust still requires human judgment. In many organizations, review capacity has become the new bottleneck. Not code generation. Not feature definition. Code review.

Correct Code Can Still Be Bad Code

One of the biggest misconceptions about AI-generated code is that the primary risk is bugs. That’s not actually what I worry about. Obvious bugs are often the least interesting problem. The more dangerous issue is architectural entropy.

I’ve seen examples where multiple engineers solved similar problems using AI assistance. Every solution worked. Every test passed. Every implementation looked reasonable when examined in isolation. But collectively, the codebase became harder to understand. Different patterns emerged in different places. Different abstractions. Different libraries. Different assumptions about how to solve problems. The result was a software that worked fine but was completely incoherent for someone trying to read it.

This is where AI creates a subtle but important challenge. Human engineers naturally absorb organizational patterns over time. They understand tribal knowledge. They know why certain architectural decisions were made, even if that knowledge only exists in someone’s head. AI doesn’t have access to any of that context. It optimizes for solving the specific problem in front of it, and it’s good at that. But when hundreds of local optimizations accumulate across a codebase, the global architecture starts drifting. You end up with a collection of individually good decisions that don’t fit together particularly well.

The Rise of the Architecture Gap

I believe we’re entering a period where architecture matters more than implementation. This represents a fundamental shift in how engineering leverage works. Historically, senior engineers created leverage by writing difficult code. They were the ones who could optimize algorithms, manage memory, or navigate complex systems. The hard work was the implementation.

Today, AI can often produce that implementation. The leverage increasingly comes from deciding what should be built, how it should be structured, and what tradeoffs are acceptable. The hard part isn’t “How do we build this?” anymore. It’s becoming “Should we build it this way at all?”

That’s a fundamentally different skill, and I’ve noticed it in the strongest engineers working in AI-assisted environments. They’re not necessarily the fastest coders. They’re the people who consistently make good decisions about systems. They understand system boundaries. They understand long-term consequences. They can recognize when an elegant-looking solution creates operational complexity six months later.

AI is compressing the value of implementation skill. Judgment remains stubbornly difficult to automate.

A New Generation of AI-Native Developers

There’s a trend, I think, the industry is only beginning to discuss: we’re seeing engineers who have never known a world without AI-assisted coding. For them, generating code with AI isn’t a productivity enhancement. It’s simply the default workflow.

That’s not necessarily bad. Every generation adopts new tools. Nobody complains that developers no longer write assembly language. But I do think there’s an important distinction worth making: there’s a difference between using AI as a force multiplier and using AI as a substitute for understanding.

I’ve seen situations where a developer can successfully build a feature using AI assistance but struggles to explain how the underlying implementation works. The feature exists. The reasoning doesn’t. And I think this matters more than we’re currently acknowledging.

The concern isn’t that these engineers are less productive. Many of them are incredibly productive. The concern is what happens when the generated solution fails. What happens when production is on fire at 2 a.m. and you need to understand what’s actually running? What happens when performance degrades under load and you need to diagnose where? What happens when a subtle concurrency issue appears? What happens when an AI-generated abstraction leaks and you need to fix it?

At some point, someone still needs to understand the system deeply. The ability to generate code and the ability to reason about code are increasingly diverging skills. The industry is rewarding the first one aggressively right now. I suspect we’ll rediscover the value of the second one soon enough.

AI Optimizes Locally. Engineering Requires Global Thinking

One thing AI is exceptionally good at is solving well-defined local problems. Refactor this function. Write this endpoint. Generate tests for this component. Create a database migration. These are bounded tasks with relatively clear objectives and measurable success criteria.

But many engineering failures aren’t local failures. They’re global failures. Should this service exist? Should this team own this system? Should this be a microservice? Should we invest in this capability at all? Are we solving the right customer problem? These decisions determine far more business value than the implementation details that follow. Yet they remain difficult to automate because they require context, tradeoffs, incentives, and judgment.

AI makes it easier than ever to optimize execution. It does not guarantee you’re optimizing the right thing. And teams that confuse speed with direction can move very quickly toward the wrong destination.

The Bottlenecks Have Moved

For years, engineering organizations invested heavily in removing friction from development. Better frameworks. Better tooling. Better CI/CD pipelines. Better developer environments. AI is simply the next step in that progression.

But here’s what I’ve observed: every time you eliminate one bottleneck, another emerges.

The old bottlenecks were writing code, finding information, creating documentation, and generating boilerplate. AI has made meaningful progress on all of them. The new bottlenecks are architectural decision-making, code review, prioritization, coordination, and trust. Notice something interesting: the new bottlenecks are increasingly human. They tend to sit with senior engineers, tech leads, and engineering managers.

This helps explain something I see often: individual productivity increases while organizational productivity remains relatively unchanged. The person writing code is faster. But the people reviewing code, making architectural decisions, and coordinating work haven’t gotten faster at all.

What High-Performing Teams Are Doing Differently

The teams I’ve seen succeed with AI aren’t trying to maximize code generation. They’re trying to maximize decision quality. A few patterns stand out consistently.

First, they keep AI-generated changes small. Instead of generating an entire feature and reviewing thousands of lines at once, they break work into smaller increments. This makes review feasible and keeps the architecture coherent.

Second, they invest more heavily in architecture and design reviews. This might sound counterintuitive, but it makes sense: the cheaper implementation becomes, the more valuable design becomes. If implementation is free, what you’re really paying for is correctness and coherence.

Third, they measure outcomes rather than activity. Lines of code generated is not a useful metric. Neither is pull request volume. Customer impact, lead time, reliability, and business outcomes matter far more.

Finally, they treat AI like a highly capable junior engineer. One that can move incredibly fast. One that never gets tired. One that can generate endless implementation options. But still one that requires guidance, oversight, and judgment.

Final Thought

For decades, software engineering was constrained by the speed at which humans could write code. In 2026, that constraint is increasingly no longer true. Code generation is becoming abundant. Judgment remains scarce. Understanding remains scarce. Trust remains scarce.

AI didn’t eliminate bottlenecks. It simply moved them. And the teams that thrive over the next few years won’t necessarily be the ones generating the most code. They’ll be the ones who become exceptionally good at deciding which code is actually worth shipping.

You can also listen to an audio version of this article on my Spotify podcast -

I keep meeting young developers who are far less bullish on AI coding tools than I expected them to be. These are people who grew up building things fast, who aren’t precious about how code gets written. And yet, when I ask them about their experience with Claude or Cursor or Copilot, I get the same complaints every time.

The output is sloppy. It doesn’t get it right on the first try. It doesn’t have context about what they’re actually building. After the first draft, there are so many things to fix manually that they wonder if it was faster to just write it themselves. One developer told me: “I feel like I spend more time reviewing its mistakes than I would have spent just writing the thing.”

I’ve heard this enough times that it stopped sounding like a model problem and started sounding like a workflow problem. Because the developers who get consistent, reliable output from AI coding agents aren’t necessarily using better models. They’re working differently upstream.

Coding Was Never the Bottleneck

The problem, almost always, is the lack of a right spec. This isn’t actually a new insight. Joel Spolsky wrote about it in 2000 in his Painless Functional Specifications series: “Failing to write a spec is the single biggest unnecessary risk you take in a software project.” That was about human developers on human teams. The advice got ignored for years because writing specs felt like overhead, and good engineers could hold enough context in their heads to make it work.

AI agents can’t do that. They don’t hold context. They execute against what you give them.

Agoda’s engineering team published a finding in early 2026 that put numbers to this: AI coding tools raised individual developer output, but project-level velocity barely moved. The bottleneck shifted upstream to specification and verification, the parts that require a human to think clearly about what they actually want. Coding was never the bottleneck. AI just made that more visible.

Spolsky was right in 2000. He’s more right now.

So What Is a Spec, Actually?

This is worth slowing down on, because “spec” gets used loosely, and it’s easy to conflate it with things it’s not.

A Jira ticket’s acceptance criteria tells you what done looks like. It’s a checklist: the user can log in, the notification appears within 5 seconds, and the error state shows correctly. Useful, but it doesn’t capture the decisions you’ll have to make to get there.

A plan.md is an execution sequence. Steps in order. It answers “what will I do first, second, third.” It’s about sequence, not contract.

A spec is a contract. It answers: what should this system do, under what conditions, with what constraints, and what are the edge cases we’ve decided to handle or explicitly not handle? It’s the layer between your intent and your implementation, data model, decision log, success criteria, and failure modes, all in one place.

A concrete example makes this clearer. Say you want to add automatic retry logic for failed API calls with exponential backoff.

As a Jira acceptance criterion: “Failed API calls should be retried automatically with backoff.”

As a spec, you’re forced to answer: Should retries be per-job or per-endpoint? What’s the maximum retry count, and who configures it? Does the retry count reset after a successful call or accumulate? What counts as a failure, a 500, a timeout, a 429? What happens to the job if all retries are exhausted: silent failure, dead-letter queue, or user notification? Does the backoff multiplier apply globally or per job type?

These aren’t edge cases you figure out later. They’re decisions that determine what the code actually does. If you don’t make them before you start, the agent makes them for you, inconsistently, and probably not the way you’d want.

That’s what a spec is. The decisions are made explicit before the code exists.

The Methodology: Spec-Driven Development

Spec-driven development (SDD) formalizes this into a workflow: write the spec first, derive the implementation plan from it, then generate the code. The agent’s job is to implement the spec, not to interpret your intent.

Traditional specs were written for humans. They were read, interpreted, and then implemented, and they went stale within weeks. SDD specs are different: version-controlled alongside code, written to be agent-readable, and structured to work as validation gates. Instead of the agent deciding what to do when it hits an ambiguous decision, it checks against the spec.

The shift is subtle but significant. You go from prompting “build me a notification system” to handing the agent a document that specifies exactly how the system behaves, what it stores, what it exposes, and what the edge cases are. The agent implements that, not its interpretation of a sentence.

Who’s Actually Doing This

Although the buzz around SDD is recent, the adoption of this seems to be increasing.

GitHub Spec Kit is the most prominent. GitHub open-sourced a dev kit that brings SDD to AI coding agents, including Copilot, Claude Code, and Gemini CLI. It’s a four-phase structured process that integrates with around 30 coding agents. Teams using Spec Kit report roughly an order of magnitude fewer “regenerate from scratch” cycles compared to ad-hoc prompting.

AWS Kiro is Amazon’s implementation, available as both an IDE and a CLI. AWS has documented cases where features that would have taken 40 hours were shipped in under 8 hours of human time when authored spec-first. The time savings come almost entirely from reduced rework.

OpenSpec is the open-source option from Fission-AI. It enforces a three-phase state machine (proposal, apply, archive) before any code is written, and it’s specifically designed for iterating on existing codebases, tracking what changed relative to existing functionality using delta markers: ADDED, MODIFIED, REMOVED.

Thoughtworks covered SDD as one of the key emerging AI-assisted engineering practices of 2025, and Martin Fowler’s site has published a detailed comparison of the tooling landscape.

Easy Hack For A Good Spec

Writing a spec cold is hard. You sit down to document your feature and you don’t always know what you don’t know. The decisions you need to make aren’t obvious until something forces you to make them.

Grill-me is a Claude Code skill created by Matt Pocock that solves this. It’s three sentences long as a skill definition, but it’s one of the most practically useful things I’ve added to my workflow.

The idea: instead of writing the spec yourself, you describe what you want to build, and Claude interviews you about it. One question at a time, it walks down each branch of the design tree, surfacing dependencies between decisions and resolving them one by one. If a question can be answered by reading the codebase, it reads the codebase instead of asking you. By the end of the session, you have a spec, not one you drafted cold, but one that emerged from a structured conversation.

It’s SDD with the spec-writing friction removed.

What That Looks Like in Practice

I was building a draft-saving feature for a content tool I’m working on. Simple enough idea: auto-save drafts as users type, let them restore a previous version if they want. I had a rough mental model and ran grill-me before writing a single line.

The first few questions were expected: how often should drafts be saved, should saves be triggered by time or by keystroke count. Fine, I had answers.

Then it got interesting. Claude asked whether drafts should be scoped to a user or to a session. I hadn’t thought about that. It asked whether restoring a draft should overwrite the current content immediately or prompt the user first. It asked what should happen if a user has two tabs open editing the same document. It asked whether drafts should persist after the document is published, or be cleaned up, and if cleaned up, immediately or after some retention window.

None of these were in my head when I started. Every single one would have become an unplanned decision mid-implementation, made in a hurry, inconsistently with whatever else Claude had decided on its own.

By the end of the session, I had a document covering data model, save triggers, conflict handling, version retention policy, and UI behavior for each state. Claude Code built against it. One iteration.

What SDD Is Not

The sharpest criticism is that it looks a lot like waterfall: write a big upfront document, commit to it, then build. The software world spent years moving away from that for good reasons: requirements change, constraints shift, and the most important insights often only emerge once you start building. Critics like Marmelab have made exactly this argument, calling SDD “a waterfall with a new coat of paint.”

They’re not entirely wrong. A detailed spec can give you a false sense of control. It feels like all cases are covered. You commit to it, implementation starts, and then reality diverges, a constraint you hadn’t anticipated, a better approach that emerges mid-build, a product decision that shifts. If you treat the spec as a frozen contract, you’ll either fight the drift or ignore it, and both are bad.

A spec only stays useful if you treat it as a living document. When a decision changes mid-implementation, update the spec before or alongside the code change, not after. Some tools make this easier: OpenSpec’s delta markers are specifically designed to track how implementation diverged from what was originally proposed. GitHub Spec Kit has a living-spec mode where the document stays in sync as agents work. For grill-me users, the lightweight version is: when you change direction on a decision, run a quick grill-me pass on the new decision before implementing it, so the reasoning is captured somewhere.

For small tasks, bug fixes, and isolated UI changes, the overhead isn’t worth it at all. And even with a detailed spec, agents don’t always follow it faithfully. The spec improves the hit rate, but it doesn’t guarantee it.

SDD’s core philosophy is front-loading clarity so the agent can execute with confidence in as few passes as possible. The idea is not to one-shot the entire large feature implementation (although you could but many devs don’t like that). Once you have the spec, you could choose to implement it in pieces instead of one-shotting, giving the model the clarity it needs and giving you more control over the implementation.

When It’s Worth It

Any feature complex enough that ambiguity would force choices you haven’t consciously made is a candidate. That applies equally to new features in an existing codebase and to greenfield work.

For things like bug fixes, well-understood tasks with no branching decisions, one clear prompt to one agent is usually faster than creating a detailed spec.

If you’re new to this, start with grill-me. Zero setup, no new tool to learn. Run it before your next medium-sized feature and see what questions it surfaces that you hadn’t answered. If you want something persistent and versioned that a whole team can reference and update, look at GitHub Spec Kit or OpenSpec.

The Problem Isn’t the Model

The developers I keep meeting aren’t wrong that AI coding tools produce inconsistent results.

But the model only generates code against what it’s given. Give it ambiguity, you get ambiguous code. Give it a spec, you get an implementation of the spec. The upstream work of deciding what you’re building, in enough detail that an agent can act on it without guessing, hasn’t gone away. It’s just become more visible now that the code-writing itself is fast.

Most teams building with LLMs in 2026 are still asking the same question they were asking in 2023: Should I use prompt engineering, RAG, or fine-tuning? There are hundreds of articles, decision trees, and comparison tables trying to answer it. Most of them give you the same answer: start with prompting, add RAG when you need grounded knowledge, and fine-tune only as a last resort.

That advice was reasonable when LLMs were stateless tools you queried one at a time. It does not hold when you are building agents.

Agents changed the rules. Retrieval, memory, and behavioral consistency are no longer separate decisions you make once at the start of a project. They interact at every step of the agent loop, and the failure modes look completely different from what the classic framework predicts.

This article is not another comparison table. It is an attempt to rebuild the mental model from first principles, grounded in what is actually happening in production agentic systems in 2026. By the end, you will have a diagnostic framework you can apply to a real system you are building today, not just a theoretical checklist.

What the Old Framework Got Right (and Exactly Where It Breaks)

The classic ladder model, start with prompting, move to RAG for knowledge grounding, and fine-tune only when you need durable behavioral changes that prompts and RAG cannot achieve, was genuinely useful for a specific class of problems. If you were building a single-turn chatbot, a document Q&A interface, or a summarization tool, it gave you a sensible path with clear escalation points. It also kept teams from reaching for expensive solutions before cheaper ones had been tried.

The model was built on three assumptions that held for single-turn systems:

1. There is one system prompt that governs the entire interaction

2. Retrieval happens once, before generation begins

3. The output of the LLM is the final product, not an input to the next step

All three of these assumptions break in an agentic system.

In an agent, prompting is not a one-time setup. Every node in the agent graph has its own instructions, its own scope, and its own failure modes. Retrieval does not happen once at query time. An agent doing a multi-step research task might need to retrieve different information at step 2, step 4, and again at step 6 based on what it found at previous steps. And the output of each step is not a final product. It is a structured intermediate that gets passed downstream, where errors compound and context degrades.

Consider a concrete example: a sales intelligence agent that takes a prospect’s company name and produces a personalized outreach brief. The task involves at least four distinct steps: enriching the company profile from external data sources, summarizing recent news and funding events, cross-referencing the prospect against your CRM for relationship history, and synthesizing everything into a structured brief with a recommended angle.

A static RAG pipeline retrieves some chunks before the first LLM call and hopes they cover all four of those needs. They almost never do. The agent has no mechanism to recognize that it found recent news but missed the funding context. It cannot loop back for more. It cannot evaluate whether what it retrieved was relevant to the specific synthesis task it is doing at step 4. It generates the output with whatever it has and the gaps show up as confident-sounding hallucinations in the final brief.

This is not a retrieval quality problem. It is an architectural problem. Static RAG was designed for single-hop, single-turn retrieval. The moment the task has more than two steps, the linear pipeline is the wrong shape for the job.

How RAG Actually Evolved (and Where It Stands in 2026)

Understanding where RAG is in 2026 requires tracing how it got there, because the evolution is not linear and the current state is messier than most articles admit.

The Linear Pipeline Era (2022-2024)

Classic RAG had a simple architecture: chunk documents, embed them into a vector store, retrieve by cosine similarity at query time, append the top-k chunks to the prompt, generate. The implementation was fast and the concept was clean. It also had a ceiling that most real-world use cases hit quickly.

The core problem was that single-shot retrieval assumed the first query would surface everything the model needed. In practice, the information required to answer a complex question is rarely colocated in a few chunks. It is distributed across sections, dependent on earlier context, and sometimes only meaningful after you have found something else. The CRAG benchmark showed that even state-of-the-art RAG solutions at the time could only answer 63% of questions without hallucination. The model had no way to know when retrieval had failed, and no mechanism to recover when it did.

Self-RAG and Corrective RAG (2024-2025)

The first wave of improvements focused on making the model a more active participant in its own retrieval. Self-RAG introduced a training approach where the model learns to insert special tokens during generation: tokens that indicate whether retrieval is needed at all, whether the retrieved documents are relevant, and whether the generated output is grounded in what was retrieved. The result was a measurable drop in hallucination rate, with Self-RAG achieving a 5.8% hallucination rate on benchmarks versus higher rates in standard RAG.

Corrective RAG (CRAG) took a different approach. Rather than training the generator to self-critique, it adds a lightweight retrieval evaluator that scores documents after retrieval and, if the score falls below a threshold, triggers one of three corrective actions: refine the query and re-retrieve, fall back to a web search, or combine both. The key insight was that the retrieval evaluator does not need to be a large model. A small classifier fine-tuned on relevance judgments can do this job at low cost and low latency.

A practical note for teams building on proprietary APIs: you can approximate Self-RAG behavior through structured prompting without access to fine-tuning. Ask the model to explicitly score the relevance of each retrieved document before generating, output a structured object with a confidence field alongside the answer, and use that confidence score to decide whether to re-query. You capture roughly 80% of the benefit without the fine-tuning infrastructure overhead.

The Modular and Agentic Phase (2025-2026)

By 2025, the community had moved decisively toward modular RAG, where each component of the pipeline (query planner, retriever, re-ranker, answer generator) is independently replaceable and orchestrated by a central controller. Adaptive RAG added another layer: the controller dynamically selects between different retrieval strategies based on query complexity. Simple factual questions use direct vector search. Complex analytical queries trigger multi-step agentic workflows with multiple retrieval rounds and intermediate synthesis steps.

The architecture of a production Agentic RAG system in 2026 looks roughly like this:

The loop between Synthesis and Re-retrieve is what makes this genuinely different from classic RAG. The system can recognize that it has found partial context and decide to run another retrieval pass before generating. This is not free: each loop adds latency. But it dramatically reduces the rate of confident-wrong outputs that are the most damaging failure mode in production.

GraphRAG: When Your Knowledge Has Structure

GraphRAG, developed originally by Microsoft Research, represents a different approach for a specific class of problems. Instead of chunking documents and indexing them by embedding similarity, GraphRAG structures the knowledge base as a graph of entities and relationships. Retrieval becomes graph traversal rather than vector search.

This matters when your questions require multi-hop reasoning across connected entities. “Which of our enterprise customers use the same tech stack as the prospect we are pitching?” is a question that vector similarity will answer badly, because the answer requires joining information across multiple entities and following relationship edges. GraphRAG traverses those edges. For knowledge bases with meaningful entity relationships, such as product catalogs, customer-partner networks, or regulatory frameworks with cross-references, it can surface connections that flat retrieval misses entirely.

For most knowledge bases that are flat document stores, GraphRAG adds significant infrastructure overhead without much benefit. Know the difference before you invest in building it.

The Biggest Shift: Context Architecture and the Case Against Vector RAG

This is the development that most articles are missing, and it is the most important one for how you make decisions today.

Anthropic’s team building Claude Code, one of the most widely used AI coding tools in production, abandoned vector-based RAG entirely. Boris Cherny, the lead engineer, confirmed publicly that their approach uses glob-and-grep style file system search rather than embedding similarity. The agent directly searches the codebase using file system tools. The agentic search approach outperformed vector RAG by a significant margin.

What does this tell us? Vector search is a solution to a specific problem: you have more data than fits in context, you need to find the relevant subset, and the relevant subset is determined by semantic similarity to a query. For many real-world retrieval problems, especially structured or semi-structured data, semantic similarity is not the right signal. Direct lookup, keyword search, or SQL is faster, more precise, and requires no embedding pipeline to maintain.

The architectural pattern this points to is what is now being called context architecture. Classic RAG pushed data into the agent before the model was called. Context architecture flips this: the agent pulls what it needs at runtime through tool calls, treating the data layer as a live resource rather than a pre-loaded payload. The reasoning happens first. Data access follows, driven by the agent’s understanding of what it needs at each step.

In a context architecture, your “retrieval” is a set of well-defined tool calls. One tool queries your SQL database. Another searches your internal document store. A third calls an external API. The agent decides which tools to invoke, in what sequence, based on where it is in the task. There is no pre-built pipeline that decides upfront what context the model will have. The agent assembles its own context dynamically.

MCP as the Retrieval Infrastructure Standard

The infrastructure that makes context architecture tractable at scale is the Model Context Protocol. Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation in December 2025, and both OpenAI and Google subsequently adopted it. MCP is now the standard interface for connecting agents to external data sources and tools at runtime.

If you are building an agent that touches external data in 2026, MCP is the default starting point. It gives you a standardized way to expose your data sources as tools the agent can call, with consistent auth, error handling, and observability. The ecosystem is rich: there are MCP servers for Google Drive, Slack, GitHub, SQL databases, and dozens of other systems. For most teams, the question is no longer whether to build this plumbing yourself. It is which MCP servers to connect and how to write tool definitions that give the agent enough information to use them correctly.

The practical implication: before you spend two weeks building a chunking pipeline, embedding model, and vector store, ask whether the data access problem you are solving could be handled by a well-defined MCP tool. For structured data, the answer is almost always yes. For truly unstructured large-scale document sets where the retrieval question is genuinely about semantic similarity, a vector store is still justified. But that use case is narrower than the industry has behaved.

How Prompting Behaves Differently Inside an Agent

In a single-turn system, prompt engineering is primarily about format, tone, and instruction following. You iterate on a system prompt until the model outputs what you want. In an agent, this is a small fraction of the actual prompt engineering work.

Every node in the agent graph has its own prompt. A modestly complex agent might have 8 to 15 distinct node-level prompts: a query analyzer, a planning node, two or three retrieval evaluation nodes, a synthesis node, a drafting node, a review node, and a routing decision node. Each needs to be scoped tightly, because agent errors compound.

Here is the failure mode that catches teams repeatedly: a node-level prompt that is too broad or underspecified produces an output that is subtly wrong, not obviously wrong. The next node accepts it as valid input and builds on it. By step 5, the agent is operating on a corrupted premise, and nothing in the pipeline is designed to surface this. The final output looks coherent. It is wrong in ways that require careful reading to catch.

The discipline this requires is different from single-turn prompt crafting. A few principles that hold in practice:

Each node should know exactly one thing it is responsible for. A node that evaluates retrieval quality should not also be deciding how to phrase the final response. A node that drafts content should not be making routing decisions. Narrow scope makes each node easier to evaluate and easier to debug when it fails.

Output format is not optional. Every node in an agent graph should produce structured output, ideally JSON with a defined schema. The downstream node should never be parsing free-form text to extract what it needs. Structured outputs reduce the surface area for inter-node communication failures, and they make evaluation dramatically easier.

Explicit uncertainty is more useful than confident hedging. Prompts should instruct nodes to surface uncertainty explicitly rather than generating plausible-sounding output when they are not confident. A node that outputs {"answer": "...", "confidence": 0.4, "missing_context": ["funding date", "current ARR"]} is far more useful for an agent’s subsequent steps than one that fills in the gaps with reasonable-sounding guesses.

Prompt quality compounds multiplicatively, not additively. A 10% improvement at node 2 does not produce a 10% improvement in final output quality. It produces a larger improvement, because errors at node 2 that get passed downstream affect everything after it. The highest-leverage prompt engineering work in an agent is almost always on the early nodes in the graph, not the generation node at the end.

The diagnostic question for prompting in an agent: when you find a bad output, can you identify the specific node where the failure originated? If you cannot instrument your agent to answer this question, your debugging process is guesswork. Structured outputs and per-node logging are not optional for production agentic systems.

How Fine-tuning Behaves Differently Inside an Agent

Fine-tuning’s role in agentic systems is genuinely different from its role in single-turn applications, and most teams are applying it in the wrong place.

In a single-turn system, the most common reasons to fine-tune are: response style consistency, domain-specific vocabulary, output format compliance, and refusal behavior adjustment. These are legitimate targets. In an agent, fine-tuning for response style is lower-leverage than it looks, because style is mostly determined by the node-level prompt anyway.

The high-leverage fine-tuning targets in an agentic context are:

Routing accuracy. At decision nodes in the agent graph, the model needs to classify the current state and route to the right next step. Should it call tool A or tool B? Should it loop back for more retrieval or proceed to generation? Should it escalate to a human or handle autonomously? These are classification decisions that run at high frequency and need to be reliable. A small model fine-tuned on a dataset of correct routing decisions for your specific agent will outperform a large model relying on a general instruction. It is also dramatically cheaper and faster.

Tool call structure. If your agent makes tool calls, the model needs to reliably produce correctly-structured tool call JSON, including the right parameter names, types, and values. Out-of-the-box instruction-following models do this reasonably well for standard tools. For unusual tool signatures, domain-specific APIs, or high-stakes tool calls where a malformed call causes downstream failures, fine-tuning on correct tool call examples significantly improves reliability.

Edge case handling at scale. If your agent handles a specific task at high volume, like classifying customer support tickets, extracting structured data from a recurring document format, or grading submissions against a rubric, you will accumulate a long tail of edge cases that prompt engineering handles inconsistently. Fine-tuning on labeled examples of how those edge cases should be handled produces consistent behavior that prompt iteration cannot match.

The architecture pattern that is working well in production for these cases: fine-tune a small model (7B to 13B parameters) for the high-frequency routing and classification tasks. Use a larger frontier model for the complex reasoning and generation steps. The small model is cheap enough to call many times per task, fast enough not to dominate latency, and specialized enough to be more accurate on its narrow task than a larger general model following a prompt.

On the tooling side, the modern fine-tuning stack has become more accessible. QLoRA with Unsloth is the standard starting point: it trains LoRA adapters rather than full model weights, which means you can fine-tune a 7B model on a single mid-range GPU in a few hours. The cost to run a fine-tuning experiment is now measured in dollars, not thousands of dollars, which changes the economic calculus significantly.

One important caution: fine-tuning is not a solution for knowledge problems. If your agent is returning factually incorrect information because it lacks the relevant facts, fine-tuning will not fix this. RAG consistently outperforms fine-tuning for factual recall. What fine-tuning teaches is behavioral patterns. What retrieval does is provide facts. Conflating these two is the most common mistake teams make when they reach for fine-tuning as a general fix.

A second caution specific to 2026: the operational overhead of fine-tuning is not just the training cost. When a hosted provider updates their base model, your LoRA adapters may degrade silently. You need versioning, rollback plans, a retraining cadence, and regular revalidation. Budget 3 to 5x the training cost for lifecycle management over the first year. For many teams, the total cost of ownership makes fine-tuning less attractive than it appears when you only account for the initial training run.

A Diagnostic Framework for Agentic Systems

Before you pick a technique, it is important to diagnose the failure mode. This sounds obvious. It is consistently skipped, usually because diagnosis requires instrumentation that teams defer until after something has already gone wrong in production.

Here is the framework, structured as a decision tree:

Step 1: Identify which layer is failing

Run your agent on a representative set of test cases and categorize failures by type:

• Context failures: the agent produces wrong output because it was working with incorrect or missing information. The reasoning given the context was fine, but the context was wrong.

• Reasoning failures: the agent had the right information but produced a bad output anyway. The prompt at the failing node was too broad, underspecified, or the model made a logic error.

• Routing failures: the agent made the right decisions most of the time but fails inconsistently on edge cases. The decision logic is there in the prompt, but it is not reliable at scale.

• Format failures: the agent produces correct content but in the wrong structure, causing downstream nodes or integrations to break.

Each failure type maps to a different fix. Context failures are retrieval problems. Reasoning failures are prompting problems. Routing failures are fine-tuning candidates. Format failures are almost always solvable with structured output constraints and do not require any of the three main techniques.

Step 2: Apply the right fix at the right layer

For context failures:

First, ask whether the missing context could be provided via a tool call rather than a pre-built retrieval pipeline. If the data lives in a structured source, a SQL query or an API call through an MCP tool will get you there faster and more reliably than a vector search. Build the tool, test it, and see if context failures drop.

If the data is genuinely unstructured and large-scale, build a RAG pipeline, but build an agentic one. At minimum, add a relevance evaluator after retrieval that scores documents and re-queries if the retrieved context scores below a threshold. Single-shot retrieval is not a viable architecture for a multi-step agent.

If your queries require multi-hop reasoning across connected entities, evaluate GraphRAG for that specific retrieval path. Do not use it as your general retrieval architecture.

For reasoning failures:

Narrow the scope of the failing node. Identify exactly what it is supposed to do and remove everything else from its prompt. Add output format constraints. Add one or two few-shot examples showing the desired input-output behavior for the cases where it is currently failing. Re-run your test set on the node in isolation before re-integrating it.

Measure per-node accuracy, not just end-to-end accuracy. A system with 90% end-to-end accuracy but a 70% accuracy node at step 2 is one retrieval quality improvement away from 95% end-to-end, but you will never find that opportunity if you are only looking at end-to-end numbers.

For routing failures:

If a decision node is failing inconsistently at scale, and you have evidence (from per-node logging) that the prompt itself is well-specified but the model is still making wrong routing calls on edge cases, this is a genuine fine-tuning candidate.

Collect examples of correct and incorrect routing decisions from your logs. Aim for at least 500 to 1000 labeled examples covering the failure modes. Fine-tune a small model (Llama 3.2 3B or similar) using QLoRA on this dataset. Evaluate on a held-out test set that over-represents the edge cases. If accuracy on edge cases improves meaningfully, deploy the small model at that node and keep the large model for the reasoning-heavy steps.

Do not fine-tune the large frontier model for routing. The cost is higher, the iteration cycle is slower, and a small specialized model will match or beat it on a narrow classification task at a fraction of the inference cost.

Step 3: Evaluate all three layers independently

Production agentic systems need three separate evaluation layers, and they need to run continuously, not just before deployment.

Retrieval evaluation: are the right documents, chunks, or data records being surfaced for each step that requires retrieval? Metrics here include retrieval recall (did we get the relevant material?), precision (did we avoid irrelevant noise?), and contextual relevance (is the retrieved material useful for the specific step that requested it, not just generally related to the topic?). Tools like Ragas provide retrieval-specific metrics including context precision and recall as distinct signals.

Generation evaluation: given the retrieved context, is the model producing faithful outputs? Faithfulness, measured as whether each claim in the output is grounded in the retrieved context, is the primary metric here. A faithfulness score above 0.9 on Ragas is a reasonable production target. Answer relevancy, measuring whether the output addresses what was asked, is the secondary metric.

Routing and task completion evaluation: is the agent making correct decisions at each decision node? Are multi-step tasks completing correctly end-to-end? This layer requires task-level test cases with defined success criteria, not just output quality scores. An agent that produces a beautifully written output but called the wrong tool at step 3 has failed the task even if the generation quality metrics look fine.

Trajectory tracing tools like LangSmith expose every step of the agent loop with timing, tool call inputs and outputs, and intermediate states. These are not optional for production systems. Without per-step observability, you are debugging production failures by reading tea leaves.

The 2026 Mental Model

The debate between prompting, RAG, and fine-tuning is not over. It has moved up a level. The question is no longer which technique to pick in isolation. It is understanding the distinct role each technique plays at different points in the agent loop, and being honest about which layer is actually causing the failure you are trying to fix.

The architecture that is emerging in production looks like this:

Prompting is the behavioral layer. It scopes what each node is responsible for, enforces output structure, and defines the agent’s reasoning process at each step. It is the first thing to examine when outputs are wrong, because the majority of agent failures in production are prompt failures at a specific node, not systemic architecture failures. Prompt engineering in agents is not one-time setup. It is ongoing, per-node, and it compounds.

Context architecture with tool calls and MCP has replaced static RAG for most retrieval use cases. The default starting point for a new agent in 2026 is well-defined tools that the agent calls at runtime, not a pre-built pipeline that loads context before the first model call. Vector search over a document store is still the right answer when the retrieval problem is genuinely about semantic similarity over large unstructured corpora. For everything else, a tool call is simpler, faster, and more maintainable. This includes most structured data, most internal knowledge bases, and most code search.

Fine-tuning handles behavioral reliability at scale. Its primary targets in agentic systems are routing accuracy at high-frequency decision nodes, reliable tool call structure for unusual APIs, and consistent edge case handling for narrow repeated tasks. Fine-tuning a small model for these purposes is cost-effective and practical with current tooling. Fine-tuning a large model for knowledge injection is still a mistake. Put volatile knowledge in retrieval. Put stable behavioral patterns in weights.

Most teams that are building RAG pipelines right now could have shipped faster by starting with clean tool definitions and node-level prompting. Most teams reaching for fine-tuning could get most of the benefit from tightening their node-level prompts and adding structured output constraints first. The infrastructure looks like progress. It is often expensive distraction from the actual bottleneck.

The diagnostic question is more valuable than any framework: when your agent produces a wrong output, which node broke, and why? If you can answer that question consistently, you know which technique to reach for. If you cannot, instrument your agent until you can. Everything else follows from that.

What can you do today?

Take one agent you have already built or are currently building. Run it on 20 test cases that cover its expected failure modes. Log the output of every node for each test case. Categorize each failure as a context failure, a reasoning failure, a routing failure, or a format failure. Then apply the framework above to the highest-frequency failure category.

In most cases, you will find that the bottleneck is not where you expected it to be. That realization alone will save you from building infrastructure that solves the wrong problem.

What patterns have you run into in your own agentic systems? What layer breaks most often for the use case you are building? Reply and let me know.

When OpenClaw launched, it didn’t follow the playbook. No Product Hunt debut. No influencer seeding. No press release. A solo developer named Steinberger just pushed a repository to GitHub over a weekend, and within 48 hours, it was everywhere. The waitlist hit tens of thousands. Tech Twitter lost its mind. And here’s the part that tells you something real about the state of AI: the developer changed the project name three times in two days because of domain conflicts, and people kept finding it and sharing it anyway.

This isn’t just hype. It’s a signal about what the market actually wants right now, and where almost every well-funded AI company got it wrong.

What OpenClaw Actually Is

Let’s start with the straightforward definition: OpenClaw is an open-source AI agent framework. That means it gives an AI the ability to take real actions on your behalf, not in some abstract way, but practically. It can browse the web, read files, write code, send messages, and interact with applications. Importantly, it does this by reasoning through what needs to happen and executing it persistently and proactively, without you micromanaging every step.

This is different from a workflow automation tool like Zapier, where you build the exact steps and the system executes them. OpenClaw’s agent actually thinks about what needs to happen. You give it a goal like “monitor my competitors’ pricing and flag changes that matter to our business.” The agent then figures out the steps, recovers from errors, adapts to what it finds, and keeps working without you babysitting it.

The framework is self-hostable and model-agnostic. You can plug in Claude, GPT-4, or a local model depending on your needs. It’s also designed to integrate into the tools you already use, especially messaging platforms like Slack, Discord, WhatsApp, and Telegram. That last point is critical to understanding its appeal. OpenClaw doesn’t ask you to visit a new application. Instead, it shows up where you’re already paying attention.

The Four Design Decisions That Changed Everything

OpenClaw didn’t win because it was the first AI agent framework. AutoGen existed. CrewAI existed. LangGraph was already shipping. What made OpenClaw special was a specific set of design choices that other teams either never considered or ruled out too early. Here are the four that mattered most:

1. It Lived Where You Already Live

Before OpenClaw, every AI agent had the same fundamental assumption baked in: the user comes to the tool. You open the application, type your prompt, and wait for the result. The interaction model was extracted from the regular web app playbook, because that’s what enterprise software teaches you to build.

OpenClaw flipped this entirely. Instead of asking you to visit a dashboard, it connected natively to WhatsApp, Slack, Discord, Telegram, and Signal. This single design decision completely changed its trajectory.

The effect is profound. The agent didn’t become another tool to juggle. It became an active participant in your existing workflow. Instead of opening a new tab and formulating a request, you message the agent the same way you message your team. The notification lands in the same channel where you’re already scrolling. The context is already there.

Think about how many powerful tools die because they require a behavior change from the user. Evernote was technically excellent, but it asked you to clip content to a separate system. Notion is beautiful, but it asks you to switch context. OpenClaw eliminated that friction entirely. You don’t have to remember to check on the agent. It reaches out to you in the channels where you already exist.

2. It Was Proactive, Not Reactive

Every agent before OpenClaw shared the same fundamental model: you initiate, the agent responds, then it stops. You’re still the one driving everything. The agent only acts when you ask it to.

OpenClaw inverted this. It asked for broader permission upfront. This included access to your email, your schedule, and your messaging accounts. Then it stayed running continuously. It used scheduled jobs to act on a schedule. For example, it could check your email at 6am, draft replies to obvious messages, and flag anything that needed your attention by the time you opened your laptop. It didn’t wait for you to ask. It was already working.

This proactivity is what distinguishes an agent from a chatbot. A chatbot responds to what you ask. An agent anticipates what you need and acts before you ask. The agent notices you’ve had three financial alerts in the past two hours and surfaces them before you do. It sees a competitor announcement in your email, reads it, and decides whether it matters to you based on what it knows about your business strategy. It spots a new subscription charge and cross-references it against your known services list. Then it flags the ones that don’t match.

3. The Underlying Models Had Finally Caught Up

This is the one that’s often overlooked in the narratives around OpenClaw. Steinberger wasn’t the first person to try building a general-purpose AI agent. AutoGPT launched in early 2023 and went viral in its own right. But then it largely fizzled. It’s not because the idea was fundamentally wrong. Rather, the models at the time couldn’t reliably chain tools together, recover from errors, and plan multi-step strategies without spiraling into hallucinations or infinite loops.

OpenClaw shipped at a moment when that had fundamentally changed. The underlying language models were substantially better at maintaining context across long agent loops. They could handle failures gracefully. They could read the results of one action, adjust their strategy, and try a different approach. They could distinguish between scenarios like “this specific tool didn’t work” versus “this entire approach won’t work. I need a different strategy altogether.”

The models matter. The framework matters too. But the critical factor was timing. Shipping at the moment when the models were finally reliable enough made the difference between a cool proof of concept and something that actually worked well enough to be genuinely useful.

4. It Was Open Source and Self-Hostable

The last piece: OpenClaw was open source and self-hostable. You could run it yourself. You weren’t dependent on a SaaS company to keep the lights on. You weren’t writing data to someone else’s servers. You owned the deployment.

This is important for a few reasons. For paranoid enterprises and privacy-conscious individuals, self-hosting removes a category of risk. For developers and researchers, open source means you can fork it, modify it, extend it. You’re not limited to whatever features the vendor decides to ship. You can integrate it with your specific stack.

And perhaps most importantly for the narrative at hand: when people can deploy and modify the code themselves, they become invested in its success. They share it with others. They improve it with their own contributions. The community compounds the value over time instead of the vendor extracting it.

The Technical Advantages That Made It Work

Beyond the design philosophy, three technical decisions separated OpenClaw from other agents:

A built-in browser it could actually control. Many agents had API access to search. OpenClaw had something more powerful. It had a real browser it could operate. The agent could click links, scroll pages, read dynamic content, and see what humans see. This matters because most of the internet isn’t a clean API. It’s HTML, CSS, JavaScript rendering. The agent needed to see and navigate the actual web as it appears in your browser, not just call a search API.

Persistent memory without DIY vector databases. Most agent frameworks require you to set up your own vector database if you want the agent to remember context across sessions. This means doing real infrastructure work. OpenClaw handled this internally instead. You didn’t have to be a DevOps engineer to get the agent to remember things over time.

True model agnosticism. You could point OpenClaw at Claude, GPT-4, a local Ollama model, or any other LLM. The framework didn’t require you to be locked into one vendor’s infrastructure. (It’s worth noting that Anthropic later restricted OpenClaw’s ability to use Claude models for reasons that aren’t entirely transparent, presumably to maintain control over the full stack.)

Understanding the Broader Agent Landscape

OpenClaw’s success makes sense only if you understand that “AI agents” isn’t a single category. The term gets thrown around to describe three very different types of tools, and mixing them up leads to bad decisions about what to use and when.

Workflow Automation Tools

First category: workflow automation. This includes Zapier, Make, n8n, and similar platforms. With these tools, you build the logic graph yourself. You decide: when X happens, do Y, then Z. The system executes exactly what you’ve defined. It doesn’t reason. It doesn’t adapt. And that’s not a limitation, it’s the right design for a huge class of problems.

Consider a concrete example where a workflow tool is exactly the right call. You’re running a small business. Every time a new lead fills out your contact form, you want several things to happen automatically:

1. Create a record in your CRM

2. Send a templated welcome email

3. Add them to a Notion database

4. Ping your Slack channel

These are four predictable steps. They’re all structured and all triggered by one event. A workflow tool handles this flawlessly, reliably, and cost-effectively. You can audit every single step. There’s no ambiguity. There’s no judgment required. There’s no variation in what success looks like. You don’t need OpenClaw for this scenario. You could technically use it, but you’d be adding cognitive and computational overhead for a problem that doesn’t actually require it.

Model-Native Agent Systems

Second category: model-native agents. This is Claude’s subagent capabilities, OpenAI’s Agents SDK, and Google Gemini’s orchestration layer. These are deeply integrated with specific LLM providers. The reasoning quality is often excellent because the agent reasoning and the inference are tightly coupled. Tool use feels natural. You get good results quickly.

The tradeoff is significant: you’re coupled to one provider’s pricing, one provider’s rate limits, one provider’s decisions about what the agent can and cannot do. If Anthropic decides to restrict certain capabilities or changes the pricing model, you feel it immediately. Switching to a different provider later requires rewriting how your agent reasons about problems, because each provider’s models think differently.

For organizations that want excellence and don’t mind the coupling, this is often the right choice. The vendor has a strong incentive to keep the agent working well because it reflects directly on their model. But you’re making a bet on that vendor’s long-term strategy.

Open, Model-Agnostic Frameworks

Third category: open, model-agnostic orchestration frameworks. This is where OpenClaw sits, alongside projects like OpenHands, AutoGen, and others. The framework handles the agent loop, memory management, tool integration, browser automation, and file system access. You plug in whatever model you want. You own the entire stack.

The tradeoff is different. You have more flexibility and less vendor lock-in, but you also have more responsibility. If something goes wrong, you’re debugging it, not opening a support ticket. If you want a feature, you’re potentially coding it yourself or waiting for the community to build it.

Matching the Tool to the Task

The practical question: which tool should you use?

If the task is structured, repeatable, and trigger-based, fixed inputs, defined outputs, no judgment required, use a workflow tool. You get reliability, transparency, and cost efficiency. If you’re fine being deeply embedded in one AI provider’s ecosystem and you want the best reasoning quality out of the box, a model-native agent system might be better for you. You get excellent results with less operational burden. But if you have a fuzzy task that crosses multiple applications or data sources, requires judgment and adaptation, and you want to own the stack, OpenClaw and similar frameworks are built for exactly that problem.

What OpenClaw Is Actually Good For (Beyond Ordering Food)

This is where I need to be direct. Watching AI influencers post videos of themselves using OpenClaw to order food from delivery apps was genuinely frustrating. Yes, it technically works. The agent navigates the website, understands the menu, places the order. But think about what actually happened: you spent time installing a self-hosted agent framework, configuring it, connecting it to your accounts, setting up the deployment environment, to save yourself two taps on an app that already knows your address, your payment method, and your usual order.

This isn’t a use case. It’s a proof of concept masquerading as a use case. The reason this kind of demo goes viral is that it looks like the future, an AI that just handles things. But the agent is doing more work for a worse outcome than the existing solution. And it confuses people about what this technology is actually good for.

So let’s talk about the uses where OpenClaw actually earns its setup cost.

Use Case 1: Monitoring With Judgment

Standard monitoring looks something like “alert me when the price drops below X”. That is workflow automation territory. You don’t need an agent for that. A simple condition-based trigger works better.

But consider something different. You need the agent to “Check these six competitor websites every Monday morning. Read what changed on their pricing page, their feature announcements, and their recent blog posts. Only flag the things that actually matter to our business given what you know about our positioning, our target market, and our pricing strategy.”

This requires reading, interpretation, and a judgment call about relevance. A workflow tool can’t do this. A generic alert can’t do this. OpenClaw can. You get a Slack message every Monday with only the things you need to know, not a raw changelog. The agent has read the content, understood the context, and decided what’s signal versus noise.

This saves you the work of manually checking six websites, reading through changes you don’t care about, and filtering for what matters. Over a year, that’s hours of time reclaimed.

Use Case 2: Always-On Personal Finance Manager

Here’s a real workflow that OpenClaw handles well. You point OpenClaw at your financial data sources. This might look like bank email alerts, credit card statements forwarded to a monitored inbox, or UPI transaction notifications on WhatsApp. You also give it a simple file where you’ve defined your monthly budget buckets. Common categories include: rent, groceries, dining, investments, subscriptions, and discretionary spending.

Every morning at 7am, the agent parses overnight transaction emails, categorizes each spend against your budget buckets, and updates a running ledger that becomes your live source of truth for spending. Then around midday, if any category has burned through more than 70% of its monthly budget before the 20th of the month, it proactively pings you on WhatsApp with a notification: “Dining is at 72% of budget with 11 days left. Pace check?”

It also spots recurring debits automatically. It cross-references them against a known subscriptions list, services you’ve told it about, and flags anything new or anomalous. That forgotten free trial that just converted to paid? The agent catches it before you get the surprise charge.

Every Sunday, you get a digest to WhatsApp: spend versus budget by category, net savings rate for the week, and one actionable nudge. At month-end, it compiles a full report, compares it against the previous month, and highlights trends, which categories you overspent in, which you underspent in, patterns in your spending behavior. And you never asked for any of this. It just happened.

Use Case 3: Async Personal Shopper

Message OpenClaw on WhatsApp: “Find me a standing desk under 40,000 rupees with good reviews, and tell me when the best one drops in price.”

The agent researches. It checks multiple retailers, reads reviews, shortlists options based on your criteria. Then it monitors prices on a schedule, checking every day or every week depending on how you configure it. The moment a threshold is crossed, your top choice drops by 10% or a new option appears that meets your criteria, you get a message.

You don’t follow up. You don’t check back. The agent handles the monitoring. This is useful because price monitoring across multiple retailers requires manual effort if you do it yourself, but it’s also not urgent enough to justify asking friends or checking ten times a day. An agent handles this perfectly.

How to Actually Run OpenClaw

The easiest and most popular path is buying a Mac Mini and running OpenClaw locally. But that approach requires hardware in your home, constant electricity, reliability concerns if your home internet goes down, and adds another device to your network to manage.

The better path for most people is a cloud VM. You can get a small instance from providers like DigitalOcean, Hetzner, Vultr, or Linode. These typically cost 6 to 12 dollars per month with 2GB of RAM. That’s enough to run OpenClaw for personal or light team use. You SSH into the VM, follow the setup documentation, and you have a persistent agent running in the cloud, accessible from anywhere. There’s no hardware in your home. You’re not depending on your home internet connection.

The setup takes about an hour if you’re comfortable with Linux. If you’re not comfortable with Linux, there are managed options available. These services wrap OpenClaw with a web UI and one-click deployment. Services like Hostinger and others handle the infrastructure for you. You lose some configuration depth in this approach, but you gain a setup experience that takes minutes instead of an hour. For most people who want to use OpenClaw for personal productivity rather than building custom extensions on top of it, a managed option is worth the premium you pay.

Security: This Part Is Not Optional

This deserves its own section because the stakes are genuinely higher than people usually treat them. OpenClaw, by design, can take real actions. It can send messages, access files, interact with accounts you’ve connected to it. That capability is exactly why it’s useful. And it’s exactly why you need to be deliberate about locking it down before you connect anything real.

And one more critical point: do not install it on your personal laptop. Instead, install it on a separate cloud instance. You want isolation between the agent and the rest of your computing environment.

Authentication comes first. Depending on the version and how you deploy it, OpenClaw may not have login protection enabled by default. If your instance is exposed to the internet without authentication, you are essentially handing a fully capable AI agent to whoever finds the port. This is a serious security risk. Before you do anything else, put a reverse proxy in front of it with proper authentication. Caddy is the easiest option to implement. Nginx works if you prefer it. At minimum, use basic HTTP authentication. OAuth is better if you want to be thorough.

Scope your credentials carefully. If you’re connecting OpenClaw to your email for monitoring and drafting replies, don’t give it full account access. Instead, use a restricted account or (better yet) a restricted API token with only the permissions it actually needs. It needs read and draft permissions. It doesn’t need full account access. If it doesn’t need write access to something, don’t grant it. Every permission you grant is a potential vector if the agent goes rogue or if the agent’s reasoning fails in unexpected ways.

Be deliberate about browser sessions. OpenClaw’s browser can access anything the session is logged into. Don’t give it your personal browser. Instead, use a dedicated browser profile for the agent with only the sessions it genuinely needs. If you want the agent to check a competitor’s website, log into that website in the agent’s browser. But don’t also have your personal Gmail, your banking apps, or anything sensitive logged into that same browser.

Log what it does. Read the task log occasionally. If you don’t know what the agent is doing, you don’t know if it’s doing the right things. This is true. Spending five minutes on a Sunday reviewing the agent’s activity log is boring work, but it’s essential for understanding what’s happening.

The Bigger Pattern

What Steinberger did is something I’ve seen happen in every major technology wave. A solo builder, unconstrained by product committees and enterprise sales teams and requirements to support Fortune 500 corporations, ships something that’s just useful in a direct, immediate way.

The big players in the agent space were thinking about agent frameworks as infrastructure. They thought of them as platforms other developers build on. They saw them as abstraction layers. They viewed them as things you license and integrate into your own products. That’s a legitimate market. But Steinberger shipped something different. He built something an actual person could point at an actual problem and get real value from on day one. Not an abstraction. Not a framework for frameworks. A tool that actually works.

What This Means Right Now

My honest opinion on the current moment is clear: OpenClaw is probably not the final form of AI agents. The space is moving fast. Better things will be built. Some of what makes OpenClaw special now will be commoditized. Other frameworks will integrate the features that made it special.

But there’s something more important than OpenClaw itself. The category it represents matters. I’m talking about persistent, proactive, model-agnostic agents that live in your workflow rather than asking you to change your workflow. That is the category that matters. That’s the direction the entire space is going. That’s what people actually want.

If you’re evaluating tools in the agent space, you now have a better mental model for what exists and what’s actually a good fit for what you’re trying to do. And if you’ve been waiting for AI agents to feel less like science fiction and more like a practical productivity tool, the fact that OpenClaw went viral over a weekend might be the signal you’re waiting for.

All this while I’ve been tempted many times to write, but somehow have managed to put it off. With the world around changing so fast, I’ve been exasperated but also very excited. I’ve been totally sucked into the world of AI, and however much time you spend going down this rabbit hole, it still feels like scratching the surface. For now, I’ve decided to write exclusively about AI since there is so much to learn and share. Hope you find this useful.

Subscribe now