Video entrance Opening keynote: https://www.youtube.com/watch?v=GMIWm5y90xA The capability curve: https://www.youtube.com/watch?v=tP4MGcJ80Y0 How to get to production faster with Claude Managed Agents: https://www.youtube.com/watch?v=E9gaQHrw\_rg Building with Claude Managed Agents and Asana AI teammates: https://www.youtube.com/watch?v=BrpB-h1e--k Getting more out of the Claude Platform: https://www.youtube.com/watch?v=7oO37GRhwGk Start What is really worth watching in this sharing is A How nthropic explains how the engineering architecture will change after the "stronger model" enters the real software system. The entire video is divided into five sections: Capability boundaries of Fable 5 Model capability curve How Managed Agents are built Real use cases in the team Agent deployment and cost control If you only read the release, you would think that Fable 5 is a new model that is more expensive, stronger, and has a longer context. The information in the video is more specific: After the model capabilities are improved, a good agent system will become simpler and simpler; the truly complex parts will be transferred to eval, context engineering, tool boundaries, permissions and cost routing. This is important for both developers and product managers. Developers need to ask: How much complexity can my current agent harness have that can be returned to the model? Product managers need to ask: Which processes that could only be used for demos in the past can now be used for product design? Fable 5: Anthropic's definition of "long task model" The first speaker, Diane, first placed Fable 5 in the Claude model genealogy. She said Anthropic has put 21 versions into the hands of users and developers, from Claude 2 to Haiku, Sonnet, Opus, to Fable and Mythos. Released this time are Claude Fable 5 and Claude Mythos 5 . Fable 5 was the most powerful universally available model Anthropic had ever done at the time. It comes from the same set of underlying capabilities as Mythos 5, except that Fable 5 adds stricter security classifiers and fallback mechanisms. Anthropic's positioning of Fable 5 is clear: it's for long tasks, complex tasks, and work that requires self-checking. One word appears repeatedly in the video: long-horizon autonomy, the ability to govern over a long period of time. AI programming in the past was more like autocomplete. Later, tools such as Claude Code allowed the model to read files, modify code, and run tests. The goal of this generation of Fable 5 goes one step further: the model not only completes a clear local task, but also can continue to advance for hours or days around a high-level goal, while maintaining plans, context, constraints, and judgments in the process. The speaker first used the model genealogy to explain the positioning of the Fable/Mythos generation: longer tasks, stronger reasoning, and more emphasis on safety boundaries. Diane gives two sources of abilities. First, single-shot correctness. If the problem is complex but the specs are clearly written, Fable 5 is more likely to get it right on the first go. This is critical. In complex engineering tasks, if the first round is wrong, all subsequent repairs will be more expensive. The earlier a model understands goals, constraints, and acceptance criteria, the lower the cost of tool calls, rework, and manual babysits. Second, long-horizon autonomy. Fable 5 can run around a target for longer periods of time, dispatch sub-agents, and keep those sub-agents on track. This cannot just be understood as "the context window becomes longer". Longer context just provides space. The real difference is that models can remember specifications, process feedback, adjust plans, and know when to continue and when to verify over long trajectories. Diane also emphasized a point that is easily overlooked: Fable 5 is not only good at writing code, it is better at reading code. It can read warehouse history, locate outages, track when a bug was introduced, and proactively make suggestions for improvements. For software teams, this is closer to real productivity than "generating a functional page". Because most engineering time is spent on reading, checking, understanding, verifying, and explaining. Safe Fallback: Why Fable 5 and Mythos 5 were split into two products The explanation of Mythos 5 in the video is straightforward. Mythos 5 and Fable 5 are the same underlying model, but Mythos 5 removes cyber and bio related safeguards. Anthropic previously made Mythos Preview available to a small group of partners through Project Glasswing because its capabilities in areas such as cybersecurity had become so strong that there was a risk of abuse. The public availability of Fable 5 relies on a new safeguard system. When the request touches high-risk topics such as cybersecurity, biology, chemistry, etc., Fable 5 will route the request to Opus
- 8. Responses are clearly marked and users pay Opus prices. This mechanism is not perfect. Legitimate researchers may also encounter block or reroute. Diane acknowledges that this still requires continued improvement. But Anthropic’s trade-off is to use a stricter rollback mechanism so that stronger models can be used by more people today. This has a practical implication for product design: model products will become more and more like "capability routing systems" in the future, and fixed model endpoints will gradually recede into the background. The same user request may be judged by Fable, answered by Opus, executed by Sonnet, and made a lightweight tool call by Haiku. If you are making an AI product, model selection cannot just be hard-coded in the configuration. You need to incorporate task type, risk level, cost cap, and failure fallback into the system design. This slide is crucial: the core of Fable 5’s productization is not a single model endpoint, but a combination of “model capabilities + security classifier + fallback”. Capability Curve: Why New Models Make Old Harnesses Heavier The second segment is by Theo talking about the model capability curve. He looked back at the state a year ago: At that time, many people were still asking what big language models could do, Claude Code had not yet been fully popularized, and agent autonomy was still a new concept. Now most people on site have used Claude, and many people have experienced a 2x or even 10x increase in efficiency. There have been changes within Anthropic, too. Theo mentioned that they have released content related to recursive self-improvement, and Claude participated in more than 80% of the code merging within Anthropic. The focus here is capacity growth. He took SWE-bench Verified as an example: Sonnet
- 7 is about 60%, Opus 4.8 reaches 88%, and the Mythos/Fable generation has made this benchmark close to saturation. From 62% to 88%, that looks like just 26 percentage points. But when looking at failure rates, the difference is huge: the old model failed about 3 times as often as the new model. This explains why many people feel that their experience suddenly crosses a line when using a stronger model for the first time. In terms of success rate, it only increased by 26 percentage points; in terms of failure rate, the old model failed nearly three times as many times as the new model. This is where the gap in engineering experience comes from. The experience of an engineering task is determined by the failure rate. A model that is 60% successful means that you often have to step in, correct errors, and rerun. A model is 88% successful, and many tasks will directly cross the critical point of "requiring human attention". Theo showed a comparison: having both the old model and the new model rebuild Claude.ai in one go. The old model would start writing code quickly, call tools frequently, have a lot of lines of code, and end up with an interface that looks like it, but doesn't really work. The new model will be planned first, understanding the page structure and specifications, and then implemented. It requires less code to write, fewer tool calls, and the results are more reliable. The value of this demo is to show the behavioral changes behind "write less code, adjust tools less, and get more reliable results": a strong model will first understand the specifications. There are three types of ability changes behind this. Plan first, act later Old models are like people who start assembling furniture without reading the instructions. It’s about jumping right in and then coming back to make up for it when you fail. The new model will first form specifications and plans, identify conflicts during the planning stage, and then implement them. The product should allow the model to "think for a while." If the interaction design forces the model to give results immediately, this capability will be suppressed. Therefore, in complex tasks, thinking, effort, and planning phases should become part of the product experience. The product level should give space for model planning, especially for high-risk, multi-step, and cross-file tasks. From infinite loop to self-correction A common problem with the old model is the doom loop. After it receives failure feedback, it will say "I'll try another approach", but actually it will return to the same failure path. The new model is better able to take advantage of environmental feedback and try different strategies. This gives a clear suggestion for system design: the environment should give the model actionable feedback. Test results, logs, screenshots, difference reports, graders, user comments, these things all play roles other than debugging. They are the fuel for the agent to self-correct. Keep the goal longer. The old model will lose the plot if it runs for a long time. It forgets the original goal, forgets the constraints, and starts to deviate from the mission. The new model can maintain longer attention in million-token-level contexts. This doesn’t mean you can just stuff context into it. But it means that you can give the model a more complete task: the entire codebase, complete PRD, historical discussions, logs and design drafts, reducing fragmentation and manual splicing. Theo's advice is straightforward: give the model more ambitious tasks. Don't just let it change one file. Let it understand the entire system, plan the implementation path, execute, verify, and then adjust based on the verification results. Managed Agents: Transforming agents from local scripts to managed runtimes The third section goes into Claude Managed Agents. The focus here is not on API syntax. Anthropic splits the agent runtime into several resources: Agent: model, system prompt, tools, MCP servers, skills Environment: running environment, which can be Anthropic managed sandbox or self-hosted environment Session: a specific run Events: user messages, tool results, model status, delivered through event streams The demo in the video is an SRE incident dashboard. The scenario is typical: at 2 a.m., checkout p99 latency spikes to 10 times the baseline. Human engineers usually have to open the dashboard, grep logs, check the deployment, guess the cause, and verify again. The goal of Managed Agent is to hand over this 40-minute troubleshooting process to the agent. This exercise in the official workshop only requires the implementation of 7 small functions: create agent, create environment, upload log files, start session, stream reply, process local tools, and delete session. The rest is provided by the platform and sample applications. The significance of this design is that the agent is no longer just a while loop created locally. It has a managed sandbox, it has session state, it has event history, it has tool call boundaries. More importantly, it can run code in the cloud while calling tools provided by you locally or on the server through event streams. This is exactly what the production agent needs to look like. Because in a real system, the agent must be exposed to two types of things at the same time: One is a sandbox that it can operate safely, such as reading logs, writing temporary code, and running grep. The other type is business systems that require you to control permissions, such as metrics, deploys, diff, CRM, work orders, and databases. Managed Agents attempts to break down the boundaries between these two categories. For developers, the most underestimated task when productizing agents is often not in the prompt. The difficulty is at runtime: who saves the state? Who records every step of the way? What should I do if the tool call fails? How to give permission? How do users interrupt? How to restore historical sessions? Anthropic's idea is to make these platform primitives. The really hard part isn't "making the model call the tool", it's sessions, sandboxes, permissions, event streams, checkpoints, and recovery. Team use cases: From “Q&A assistant” to “collaborator with goals” The fourth paragraph is more of a product perspective. The speaker said that Fable 5 moves the agent's responsibility boundaries upward. Previously you would have Claude write a project update. Now you can have Fable 5 responsible for “making sure the project stays on track during the week.” Previously you would have Claude generate a financial forecast. Now you can let it continuously maintain the forecast, regularly update, verify, and improve it to keep the forecast accurate. The difference here is huge. One is a one-time product. One is ongoing responsibility. This is also the most important change in agent products: what users deliver is ownership, not just prompts. In real teams, agents often deal with messy and multi-threaded input. Requirements are incomplete, data is scattered, goals change, and there are a lot of implicit constraints in team communication. The value of Fable 5 appears here: it is better able to determine what to do next in unclean requests. Several customer feedbacks are also mentioned in the video. Rakuten sees Fable 5 reflecting and validating its work in high-effort settings, making large-scale automated operations more feasible. Cognition tested Fable 5 with FrontierBench, emphasizing its long-horizon reasoning and ability to generalize in the face of unfamiliar tools and complex contexts. GenSpark reported that Fable 5 performed best on the most difficult tasks, such as UI design and game coding. Customer feedback focuses on one type of task: long links, cross-tools, requiring judgment, and new information is constantly generated in the middle. These examples point in the same direction: the longer the link, the more cross-tools, and the tasks that require judgment, the more obvious the advantages of strong models are. For short tasks, the strong model may be just a little more expensive. For long tasks, strong models require fewer detours, less rework, and less manual supervision, which may ultimately be cheaper. Deployment: The real expensive part of Agent is the context. The last paragraph is the most practical part of the entire video. The speaker uses a Hero Corp dashboard demo to explain how to deploy agents to a more controllable, cheaper, and more stable state. This demo is very interesting. At first it was an ordinary corporate CEO dashboard, but Claude Code directly asked Claude Code to change the theme to "Superhero Company" on the spot. Hero Corp's business is to rent out superheroes to help defend cities, defeat villains, and attend children's birthday parties. This dashboard tracks multiple goals from company data. The problem quickly arises: only loading the first target consumes one million token contexts. This leads right into context engineering. The definition given by the speaker is very simple: context engineering is the engineering discipline that determines what should enter Claude's context. You need to give the model enough information so that it can make good judgments. You also want to avoid stuffing irrelevant information into the model, making it slower, more expensive, and more distracting. The video talks about three techniques. Tool Search Tool: Don’t cram in 100 tools at once. Many production agents will have 10, 20, or even 100 tools. It’s no problem to have many tools. The problem is to put all tool schemas into the context at once. Most running trajectories only use a few tools, but you pay the token cost for all tool definitions and let the model make decisions among too many options. Tool Search Tool's method is: just give the model a "tool search tool". When the model determines that it needs a certain tool, it first asks tool search tool. The search tool then finds matching tools from the tool inventory and puts the schema that is actually needed into the context. Loveable reduces token usage in this way, and the model performs better. Because the context is cleaner and the judgment is more focused. Programmatic Tool Calling: Let the model write code to filter tool results. Many tools return large amounts of data. Outlook may return 100 messages. HTML scraping may return the entire page. Meeting transcription tools may return the full transcript. But the agent currently only needs one of the fields, a summary, and an emotion judgment. The approach of Programmatic Tool Calling is to let the model write a small piece of code to process the tool return value, and only put the necessary results back into the context. The model first gets the complete tool results, and then writes code to filter based on the schema. What ends up entering the context may be only 2% or 5% of the information. In Quora's agent scenario, this type of method is very helpful for processing large amounts of HTML. It no longer crams complete pages into context, but only takes the snippets that are really needed. Compaction: Long sessions need to be "slimmed down" Even if tool search and programmatic tool calls are used, long tasks will still hit the context upper limit. Compaction's approach is to set thresholds. For example, you have 1 million token contexts, but you want to only use 400,000 or 500,000. When the context approaches the threshold, the system pauses the agent, calls another model to summarize the transcript so far, deletes intermediate tool calls and tool results that have lost value, and only retains the current goal, decisions made, data collected, and next actions. The agent then continues running with this compressed summary. Hex has implemented a similar mechanism itself. Using platform capabilities, they removed about 300 lines of maintenance code. This is the value of a platform-based runtime: sinking state management, compression, and recovery capabilities that every team will write repeatedly into the platform. Cost Strategy: Let cheap models do the work and strong models serve as advisors. There is also a very practical strategy at the end of the video: Advisor. The speaker used a software team analogy. If a junior engineer can ask senior engineers a few questions every day, or let senior engineers review key code, his output will be significantly better. Senior engineers don't need to write code for him all the time. Same goes for models. You can let Haiku or Sonnet take care of cheap, stable, execution-oriented work, such as writing code, calling tools, and organizing data. When it encounters a critical judgment, it calls Opus or Fable as an Advisor. This allows for stronger reasoning capabilities at a lower cost. In the video demo, Sonnet originally judged that Metropolis’ deal was in the green state. In Advisor mode, Opus checked the meeting transcript and discovered that Sonnet had left out a key detail: Metropolis' mayor wanted CryoThane to attend the opening event, and the account team didn't schedule it. This deal should actually be marked red. The system therefore allows the CEO to adjust arrangements to avoid missing out on deals. This example makes cost routing clear: Fable should be used on tokens that really require in-depth judgment. Tool calling, batch processing, formatting, and general code generation can be left to cheap models. High-risk judgment, in-depth reasoning, critical acceptance, and complex conflict handling are then handed over to Opus or Fable. If you are building an agent product, model routing should become the product infrastructure. This video’s implementation checklist for developers. After watching these 85 minutes, you can condense down to a few truly executable suggestions. Let the model plan first. In complex tasks, don't demand the end product right from the start. Write a plan for the model space, list assumptions, and define acceptance criteria. Give verifiable feedback to the agent. Tests, logs, screenshots, graders, and manual annotations should all be returned to the run loop. Without feedback, it is difficult for a model to correct itself. Complete the task. Strong models are suitable for the entire warehouse, complete business goals, and long-context tasks. Just letting it change a small file will waste its main ability. Take the tool schema out of the context. When there are many tools, use tool search. Don’t run your model with 100 tool definitions every time. Also take the tool results out of the context. The large results are first filtered by the program, and only the information needed for the current decision is sent back to the model. Long tasks must have compaction. Millions of tokens still have boundaries. Long sessions require thresholds, digests, and recovery mechanisms. Strong models are suitable for advisors. Let cheaper models take care of execution and strong models handle key judgments, preserving both cost and quality. Design system for model upgrades. Anthropic has repeatedly emphasized that winning teams will regard model upgrades as business opportunities. This requires automated evals, testing processes, model switching mechanisms, and a habit of continuous experimentation. Finally: The focus of AI Agent engineering is moving. What this video is really about is one thing: as the model becomes stronger, the complexity of the agent system will be redistributed. In the old days, we wrote a lot of complexity into prompts, workflows, and harnesses because the models were not reliable enough. With the emergence of models like Fable 5, some of the harness complexity can be removed. You give it a file system, a sandbox, tools, feedback, and goals, and it can make its own judgment about longer links. But new complexities will emerge. You have to do a harder eval. You have to manage the context. You have to manage cost routing. You have to manage permissions, status, events, auditing, and rollbacks. You have to decide which experiences you couldn’t do in the past and can try now. For developers, this means that the agent project is no longer just the prompt project. It's more like a combination of runtime engineering, evaluation engineering, and product systems engineering. For product managers, the most important question should not stop at "How much better is Fable 5 than Opus?" A more useful question is: Can the process that required people to watch for three consecutive days in the past be transformed into an agent with goals, tools, verification, and cost boundaries? If the answer starts to become yes, that’s a product opportunity.