Stop Using Fable 5 Like a Chatbot: How to Build an Agent System That Improves Itself

The five-minute agent problem

Loops, workflows, routines, and the real difference between an agent that works for five minutes and one that keeps working after you close the laptop. Grounded in how Anthropic actually says to build these things.

Here is a scene you might recognize. You open Claude, paste in a big task, watch it work for a few minutes, grab the useful bit, and close the tab. It felt powerful. It also stopped the second you looked away.

That is most people's relationship with Claude Fable 5. They treat the most capable model Anthropic has ever shipped like a very smart autocomplete with a large memory. To be fair, it is genuinely great at that. But it is a little like buying an industrial CNC machine and using it as a paperweight. The impressive part is the part almost nobody turns on.

The gap is not the model. The gap is the system you build around it. An "agent system" is what you get when you stop sending one prompt and waiting, and start giving the model a goal, a set of tools, a memory, and a loop, so it can plan, act, check its own work, and keep going without you babysitting every step.

This piece is a field guide to building that. We will go from the plain-English version (what an agent even is, and when you should not build one) all the way to the parts that make a system genuinely improve over time: evals, memory, skills, subagents, dynamic workflows, and routines. I have grounded all of it in how Anthropic actually describes building these things, with sources at the bottom, because this corner of tech attracts more hype than almost any other and you deserve the real version.

One promise: by the end you will know exactly what "self-improving" does and does not mean, and you will have a build path that starts small instead of trying to boil the ocean on day one.

Part 1: Get the words right

Before you build anything, get three words straight, because most of the confusion online comes from people using them interchangeably.

A single prompt is not an agent

When you type a request and read the reply, that is just an augmented model call. Anthropic calls the basic unit the "augmented LLM," which is a model plus three add-ons: retrieval (it can look things up), tools (it can do things), and memory (it can remember). Everything else is built out of this one block. If a single good prompt with the right context solves your problem, congratulations, you are done. Do not build an agent.

Workflows versus agents

Anthropic draws a clean line between the two kinds of systems people lump together as "agentic." In their words, workflows are "systems where LLMs and tools are orchestrated through predefined code paths," while agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

Plain version: a workflow is a railway. You lay the track, the model rides it. An agent is a car with a driver. You give it a destination and it picks the route, changing course when a road is closed.

Workflows are predictable, cheap, and great for well-defined jobs. Agents are flexible and powerful and better when you cannot script the steps in advance, which also makes them slower, pricier, and more prone to wandering off. Anthropic's own advice is refreshingly boring: "find the simplest solution possible, and only increase complexity when needed. This might mean not building agentic systems at all." Frame that and hang it over your desk.

Where Fable 5 changes the math

So why is everyone suddenly talking about agents that run for hours? Because the model finally can. Claude Fable 5, which Anthropic released in June 2026, is its most capable widely released model, built for long-horizon, autonomous work. Anthropic's own line: run it in a harness like Claude Code and it can "work for days at a time: planning across stages, delegating to sub-agents, and checking its own work."

A few concrete things make it suited to this. It holds its footing across a one-million-token context window. Its "thinking" is adaptive and always on, so it decides how hard to reason at each step, and you tune that with an "effort" setting (the high setting called xhigh is meant for agentic runs over thirty minutes with token budgets in the millions). And, tellingly for our topic, Anthropic reports that giving Fable 5 persistent file-based memory improved its performance on one long task about three times more than the same trick helped an earlier model. The model was built to use notes, tools, and time. That is the whole game.

Part 2: The anatomy of an agent (the loop)

Strip away the mystique and an agent is almost embarrassingly simple. Anthropic puts it bluntly: agents "are typically just LLMs using tools based on environmental feedback in a loop." That loop is the entire engine, and the Claude Agent SDK (the toolkit for building your own agents, formerly the Claude Code SDK) describes it in four beats: gather context, take action, verify work, repeat.

Every piece of that source diagram (trigger, context, tools, decision, loop, output) lives inside this loop. Let me walk each beat.

The trigger: how it starts

Something kicks the loop off. A person types a request, a schedule fires, a webhook arrives, a pull request opens. Hold that thought, because "what starts the agent" is exactly where routines come in later.

Gather context (the part everyone underrates)

This is where most homemade agents quietly fail. The instinct is to cram everything into the prompt: the whole knowledge base, every file, the entire history. It backfires. Anthropic's team has a name for the failure, "context rot": as the number of tokens in the window grows, the model's ability to accurately recall any one of them drops. They treat context as "a finite resource with diminishing marginal returns," and the guiding rule is to find "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."

In practice that means pulling information "just in time" instead of front-loading it. Rather than dumping a database into the prompt, a good agent keeps lightweight pointers (file paths, links, saved queries) and fetches the actual content only when it needs it, the same way you do not memorize the whole internet but you do know how to search it. A knowledge base is useful precisely because the agent can reach into it on demand, not because you paste all of it up front.

Take action: tools and integrations

Tools are how an agent does things instead of just talking about them: run a query, send a message, edit a file, call an API. Two ideas matter here.

First, tool design is prompt design. Anthropic coined a nice phrase, the "agent-computer interface" (ACI), and argues you should sweat it as much as a human interface. Write tool descriptions like a great docstring for a new hire: what it does, when to use it, the edge cases. On a real coding benchmark they spent more time optimizing tools than the main prompt, and one small fix (forcing absolute file paths instead of relative ones) took a tool from error-prone to flawless. "Poka-yoke" your tools, as they put it: shape them so mistakes are hard to make.

Second, you rarely need to hand-build integrations anymore. The Model Context Protocol (MCP), Anthropic's open standard that they compare to "a USB-C port for AI applications," lets you plug an agent into Slack, GitHub, Google Drive, and hundreds of other services without writing custom authentication for each one.

Verify work: the step that separates toys from tools

Here is the habit that matters most and that most people skip. After the model acts, it should check the result against reality, not against its own optimism. Anthropic is blunt about the payoff: "Agents that can check and improve their own output are fundamentally more reliable. They catch mistakes before they compound, self-correct when they drift, and get better as they iterate."

Verification can be cheap and mechanical (run the linter, run the tests, confirm the API actually returned a success code) or it can be another model acting as a judge. The point is that it is grounded in real feedback from the environment, an actual test result or a real database row, not the model cheerfully announcing "done."

The loop, and knowing when to stop

Then it repeats: fresh context, next action, check, again, until the job is finished. Because an autonomous loop can in theory run forever (and spend real money doing it), you always set a stopping condition. Anthropic names the two normal ones: the task completes, or you hit a cap such as a maximum number of iterations. Human check-ins at key moments are the third lever, and on high-stakes steps they are not optional.

Part 3: The self-improvement engine

Now the phrase in the title. "Self-improving" is where the hype gets thickest, so let me be precise about what it does and does not mean.

It does not mean the model retrains itself overnight into a smarter version. It cannot, and you would not want an autonomous system quietly rewriting its own brain. What it means, in every serious version I have seen, is that you build feedback loops around the model so the system gets more reliable over time: it measures its own results, keeps notes on what worked, and reuses hard-won lessons instead of relearning them every run. Three ingredients do the heavy lifting.

Evals: you cannot improve what you cannot measure

This is the unglamorous foundation, and it is the one that actually works. An eval is a test for your agent: a task, plus a way to grade the result. Anthropic's guide on the subject makes the case plainly. Without evals, teams get stuck "catching issues only in production, where fixing one failure creates others." With them, "development accelerates as failures become test cases, test cases prevent regressions, and metrics replace guesswork."

The vocabulary is worth knowing because it makes the whole thing concrete. A task is an input plus success criteria. A trial is one attempt (run several, since the model is not deterministic). A grader is the scoring logic, which can be plain code, another model, or a human. And the outcome you grade should be the real end state, an actual file written or a real record created, not a friendly message claiming success. That last point is the difference between an agent that looks like it works and one that does.

The practical loop: collect the cases where your agent failed, turn each into a test, and now you have a growing safety net that catches regressions forever. Your failures become your curriculum.

The evaluator-optimizer pattern: a built-in editor

One specific pattern turns evals into live improvement. Anthropic calls it evaluator-optimizer: "one LLM call generates a response while another provides evaluation and feedback in a loop." One model writes, a second critiques against your criteria, the first revises, and around it goes until the work clears the bar. It fits best, they note, when you have clear criteria and when a human articulating feedback would visibly improve the result. It is the writer-and-editor relationship, automated.

Memory: so it stops starting from zero

An agent with no memory is stuck in Groundhog Day. Every run it re-learns your preferences, re-discovers the same dead ends, re-asks the same questions. Memory fixes that. Anthropic ships a memory tool that lets an agent store and retrieve notes across sessions, with the explicit purpose of letting it "apply lessons from past interactions, decisions, and feedback to new tasks" and "build up a knowledge base over time."

The underlying pattern is simple enough to build yourself, and it has a plain name: structured note-taking. The agent keeps a running notes file (think a NOTES.md, or a to-do list it maintains) outside the context window, and reads it back in when relevant. Anthropic's own Fable 5 results drove this home. On a long task, giving the model persistent file-based memory helped it far more than it helped a weaker model. Better models do not just reason better. They take better notes.

Skills: bottling a capability so it compounds

The last ingredient is how a system gets not just more reliable but more capable over time. An Agent Skill is a folder holding a set of instructions (and optionally scripts and reference files) that the agent loads only when a task calls for it. Anthropic describes building one as "like putting together an onboarding guide for a new hire."

The clever bit is "progressive disclosure." At rest the agent only sees each skill's name and one-line description, which costs almost nothing. When a task looks relevant, it opens the full instructions. If those reference more files, it opens those too, and only then. So you can accumulate an effectively unlimited library of capabilities without drowning the context window, and the agent pulls the right one off the shelf when it needs it.

Here is why skills matter for self-improvement specifically: Anthropic's guidance is to have the agent capture successful approaches and past mistakes into reusable skill content, so a lesson learned once becomes a capability forever. They are also candid that fully autonomous skill-writing, where "agents create, edit, and evaluate Skills on their own," is still an aim rather than a shipped feature. So today this is a loop you run with the model, not one it runs alone. Keep that in mind whenever someone sells you a system that "improves itself" with no human anywhere in sight.

Part 4: Scaling the work with subagents and dynamic workflows

Once one agent works, the next unlock is many of them. Two mechanisms, one manual and one automatic.

Subagents: divide, isolate, conquer

A subagent is a specialized agent that runs in its own clean context window, does one focused job, and reports back a short summary. A main "orchestrator" agent holds the plan and hands out the pieces. Anthropic's own research feature works exactly this way: a lead agent plans, spins up several worker subagents that search in parallel, and a final agent handles citations before the answer comes back.

Two reasons this helps. Speed, because the workers run at the same time instead of in sequence. And focus, thanks to a subtle context trick: each subagent can burn tens of thousands of tokens exploring, yet return only a distilled summary of one to two thousand tokens to the orchestrator. The main agent's context stays clean, holding conclusions rather than everyone's scratch work. Anthropic sums the idea up neatly: the essence of search is compression.

The honest caveat, which they also volunteer: coordinating many agents is hard, it burns a lot more tokens, and early versions happily spawned armies of subagents for jobs that needed one. More agents is not automatically better.

Dynamic workflows: when the model writes the orchestration

This is the source article's "dynamic workflows," and it is a real, shipped Claude Code feature, not a metaphor. Instead of the model coordinating helpers turn by turn in its own head, it writes an actual JavaScript script that orchestrates the whole fleet, and a runtime executes that script in the background while your session stays responsive. The plan lives in code you can read, save, and rerun, so the orchestration itself becomes repeatable.

The scale is genuinely different: a single run can coordinate up to 1,000 agents (with a limit on how many run at once), and because the coordination happens outside the conversation, the plan does not degrade as the job grows. You trigger it by just asking ("use a workflow") or by turning on a setting called ultracode. It shines on jobs too big for one pass: a bug sweep across an entire codebase, a migration touching hundreds of files, or a research question where independent agents cross-check each other before anything reaches you.

For a sense of the ceiling: Anthropic points to a developer who used dynamic workflows to port the Bun runtime from Zig to Rust, roughly 750,000 lines, with hundreds of agents working in parallel and two reviewers on each file, going from first commit to merge in about eleven days. That is not a chatbot. That is a workforce.

Part 5: Making it run on its own (routines and triggers)

Everything so far still assumes you are sitting there watching. The last step is to remove yourself from the trigger. This is the source article's "routines," and again it is a concrete feature, not a vibe.

A routine is a saved agent configuration (a prompt, plus the repositories or connectors it needs) that runs on Anthropic-managed cloud infrastructure, which means it keeps working when your laptop is closed. You attach one or more triggers to it:

• Scheduled: run every weeknight, every hour, weekly, or once at a future time.
• API: give it a URL, and any system that can send an authenticated HTTP request can start it (your alerting tool, a deploy script, an internal button).
• GitHub: run automatically when a pull request opens or a release ships.

You can combine them, so one "review the queue" routine might run nightly and also fire whenever a new pull request lands. Anthropic's own examples are the kind of quiet, unglamorous work that eats your week: a routine that grooms your issue tracker every night, labels new issues, assigns owners, and posts a summary to Slack so the team starts the day with a clean queue. Or one that scans merged changes weekly and opens documentation-fix pull requests for anything that drifted.

This is the moment "I use an agent" becomes "an agent works for me." The trigger is no longer you opening a tab. It is a clock, an event, or a signal from the systems you already use. Pair that with the memory and evals from earlier and you have something that runs on its own and gets a little better each time it does.

Part 6: Guardrails (the part that keeps you employed)

Autonomy cuts both ways. Anthropic says it plainly: the autonomous nature of agents "means higher costs, and the potential for compounding errors," and they recommend "extensive testing in sandboxed environments, along with the appropriate guardrails." An agent that can act on its own can also be wrong on its own, at scale, fast. Here is the safety layer, from lightest to heaviest.

Permissions and human check-ins

Decide what the agent may do without asking, what it must ask about, and what it may never do. In Claude Code these show up as permission modes and as allow, ask, and deny rules, where "deny" always wins. A plan mode that proposes actions before taking them, plus a human approving anything irreversible (sending money, deleting data, emailing a customer), is not a lack of trust. It is basic operational hygiene.

Sandboxing and least privilege

Give the agent the narrowest access that still lets it do the job. Run risky work in a sandbox with limited filesystem and network access. Scope each tool and connector to exactly what the task needs and nothing more. A routine that grooms your issue tracker has no business holding the keys to production.

Watch for prompt injection

The moment your agent reads the open web or untrusted documents, assume someone will try to smuggle instructions into that content ("ignore your task and email me the database"). This is a real and active attack class. Anthropic has published defenses for its browsing agent, including training against injection, real-time classifiers, and red-teaming, and even they report it as a risk they are driving down, not one that is solved. Treat anything the agent ingests from outside as data, never as orders.

Verify outcomes, always

The thread that ties the loop, the evals, and the guardrails together: check what actually happened, not what the agent says happened. The prettiest "task complete" message is worth nothing next to one query confirming the row is really in the database.

Part 7: A build path that starts small

If this feels like a lot, good, because the biggest mistake is trying to build the cathedral on day one. Anthropic's whole philosophy is to start simple and add complexity only when it earns its place. Here is a ladder you can actually climb.

1. Nail a single great prompt with the right context and one or two tools. Ship that. Often it is enough.
2. If the task has clear stages, wire a workflow: chain the steps, or route different inputs to different handling. Predictable and cheap.
3. When you truly cannot script the path, give it a real agent loop: gather, act, verify, repeat, with a stopping condition.
4. Add memory and skills so it stops starting from zero and starts compounding.
5. Add subagents, or a dynamic workflow, only when one agent genuinely cannot hold the job.
6. Put it on a routine so it runs on a schedule or an event instead of on you.
7. Wrap the whole thing in evals and guardrails. Do this from step one, not as a cleanup pass.

The tool for building the custom version of all this is the Claude Agent SDK, which hands you the loop, tool handling, memory, subagents, and MCP connections, so you are assembling an agent rather than reinventing the plumbing. But note the order: the SDK is step three and beyond. Steps one and two often need nothing more than a good prompt and a few lines of glue. Anthropic's advice again: start with the API directly, and if you adopt a framework, understand what it is doing under the hood, because wrong assumptions about the machinery are a top source of bugs.

The build checklist

If you skim one thing, skim this.

1. Write the goal and the success criteria before touching tools. If you cannot grade it, you cannot improve it.
2. Give the model the smallest set of high-signal context, and let it fetch the rest on demand.
3. Design tools like you would document them for a new hire. Test them harder than the prompt.
4. Make "verify against reality" a required step in the loop, not an afterthought.
5. Set a stopping condition so a runaway loop cannot actually run away.
6. Turn every failure into an eval. Keep the notes file. Bottle repeat wins as skills.
7. Reach for subagents or dynamic workflows only when one agent cannot hold the task.
8. Schedule it as a routine once it has earned your trust.
9. Sandbox it, scope its permissions, and keep a human on the irreversible steps.

Start at line one. Add the next line only when the last one is solid.

The mistakes that keep your agent at five minutes

The patterns I see most:

• Confusing a big prompt for an agent.If there is no loop and no tools, it is a very smart reply, not a system.
• Building an agent when a workflow would do. Autonomy you do not need is just latency, cost, and risk you paid for on purpose.
• Stuffing the context window. More tokens is not more intelligence. Past a point it is less, thanks to context rot.
• Skipping verification. An agent that never checks its work will confidently compound one mistake into fifty.
• No evals. Without a test set you are not improving the system. You are just reacting to whatever broke in production today.
• No memory. If it starts from zero every run, it can never get better, by definition.
• Full autonomy, no guardrails. The fastest way to turn a useful agent into an expensive incident.
• Believing "self-improving" means "hands-off." The improvement is a loop you design and supervise, at least for now.

One last thing

Strip away the vocabulary and the whole thing is intuitive. You are not summoning a genie. You are onboarding a very capable, very fast new hire, then building the scaffolding any new hire needs to do great work unsupervised: a clear brief, the right tools, access to what they need when they need it, the habit of checking their own work, a notebook so they remember what they learned, and a manager who reviews the big calls.

Fable 5 is good enough that the scaffolding is now the interesting part, not the model. The people getting extraordinary results are not the ones with a secret prompt. They are the ones who built the system: the loop, the memory, the evals, the guardrails, the schedule. All of that is buildable this week, and you do not start with all of it. You start with one honest loop that checks its own work, and you add a rung at a time.

The five-minute version closes the tab. The real version is still working after you have closed the laptop, and it is a little better at the job than it was yesterday. Go build that one.

Sources and further reading

Grounded in Anthropic's own engineering posts and documentation (verified mid-2026):

• Building effective agents (workflows vs agents, patterns, the loop, tool design) — anthropic.com/engineering/building-effective-agents
• Effective context engineering for AI agents (context rot, high-signal tokens, note-taking, subagents) — anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Building agents with the Claude Agent SDK (gather, act, verify, repeat) — anthropic.com/engineering/building-agents-with-the-claude-agent-sdk
• Subagents — docs.anthropic.com/en/docs/claude-code/sub-agents · How we built our multi-agent research system — anthropic.com/engineering/multi-agent-research-system
• Agent Skills — anthropic.com/news/skills
• Demystifying evals for AI agents — anthropic.com/engineering/demystifying-evals-for-ai-agents
• Memory tool — docs.anthropic.com/en/docs/agents-and-tools/tool-use/memory-tool
• Model Context Protocol (MCP) — docs.anthropic.com/en/docs/agents-and-tools/mcp
• Dynamic workflows in Claude Code — code.claude.com/docs/en/workflows · announcement — claude.com/blog/introducing-dynamic-workflows-in-claude-code
• Routines (scheduled, API, and GitHub triggers) — code.claude.com/docs/en/routines
• Permission modes and guardrails — code.claude.com/docs/en/permission-modes
• Claude Fable 5 — anthropic.com/claude/fable · launch — anthropic.com/news/claude-fable-5-mythos-5