Machine-generated source transcript; recognition errors remain. Timestamps and subtitles use the selected source recording’s clock, not clip-relative time. Section links use cited source moments; sections without a verified moment return to the talk start.
3:48:31All right.
3:48:32It's very nice to be here.
3:48:35The clicker works, the computer works.
3:48:37I'm Lance from Anthropic.
3:48:39I know we've had some issues with the prior keynotes,
3:48:42so we're set to go.
3:48:44I'm going to tell two stories about getting the most out of Claude
3:48:47and exploring Claude's frontier capabilities.
3:48:49So the first is multi-aging.
3:48:51This is a blog I wrote with the Fable 5.2 launch,
3:48:53and I want to kind of tell the story of what happened here.
3:48:57So for math slash theorem,
3:48:58it's one of the more kind of famous claims in mathematics.
3:49:01It's stood and proven for around 350 years,
3:49:04and it's actually a very simple statement.
3:49:05Just A to the N equals B to the N,
3:49:07equals C to the N has no solution
3:49:09for any positive whole numbers greater than 2.
3:49:12Now, this deceptively simple kind of statement
3:49:15has proven to be quite difficult to actually prove
3:49:18in the mid-90s, Sir Andrew Wiles did prove it.
3:49:23He put out a proof, and it took him seven years of work.
3:49:25It was extremely painstaking.
3:49:27And since that time, a major effort and interest in mathematics
3:49:31has been formalizing that proof,
3:49:32or basically computationally checking every step.
3:49:34So proofs are kind of long chains of logic,
3:49:37and you actually can computationally check proofs
3:49:39using different systems, which I'll talk about, for example, using Lean.
3:49:44So this is just kind of a visual kind of explaining the,
3:49:46There's a very interesting video showing the effort that he went through.
3:49:49It was an extremely pain-stricken process to establish this proof.
3:49:54And in September, we published that we used CLAW to formalize it.
3:49:59This was the
3:50:00first very important result that we shared along these lines.
3:50:05And we used Lean to do it.
3:50:07So Lean allows you to computationally verify every step in a proof.
3:50:11Now doing this, though, is extremely painstaking.
3:50:14We started with a team of down a dozen agents.
3:50:17And this is kind of just showing a schematic of that team.
3:50:20Very early on, that team didn't work very effectively.
3:50:24We had to give it something called ProofToMe.
3:50:26Now, this is kind of a platform for orchestrating mathematics proofs,
3:50:30and it helped the agents significantly manage the state of the project.
3:50:35Lean, you can think about as a harness.
3:50:38So basically, it provides the agents with a graph that they can query.
3:50:41So it's basically lots of scaffolding around this problem statement.
3:50:44You can think of it as like a very domain-specific harness, okay?
3:50:48Now, this is all setting up what we actually did.
3:50:50We reported. This was back in September.
3:50:53the formalization. Now what I want to do for 5.2 is show can we have a much larger team of agents,
3:50:59so going from around a dozen to a thousand, do this formalization with no domain-specific
3:51:05harness, so without proof to me, and with no human steering with respect to the solution.
3:51:11So the report we talked about in September had both this domain-specific harness, proved to me,
3:51:15and a lot of support from a researcher. This is testing whether or not a large team of FABL2 agents
3:51:21can autonomously develop this formalization themselves.
3:51:26So this is just giving you a sense for the harness.
3:51:29It looks kind of complicated, but it's actually pretty simple.
3:51:32Each of the 1,000 agents has its own sandbox
3:51:34with restricted network access.
3:51:36Most of this is directed on safety and security.
3:51:40So we have 1,000 agents.
3:51:42Each have their own sandbox.
3:51:43They can connect to two different things,
3:51:45a Git and a SQL database.
3:51:46That's it.
3:51:47Those are the core primitives that we give this team.
3:51:50And we have real-time monitoring looking at every tool call for things like escapes.
3:51:55We also have offline monitoring looking at runs of all the agents every 10 minutes.
3:51:59This is kind of the setup.
3:52:011,000 agent team, very simple primitives, just Git and a database.
3:52:06The prompting is pretty simple.
3:52:08It establishes one lead agent, 999 helper agents.
3:52:12It gives them awareness of Git and the database and the problem statement.
3:52:18That's really it.
3:52:19We want to see if this team could then do this formalization.
3:52:23What's interesting is this is kind of the story of what the team did.
3:52:26The lead, very early on, five minutes into the run,
3:52:30basically created these database tables.
3:52:32So agents now are sufficiently advanced
3:52:35that they can actually build primitives
3:52:37that they need to solve hard problems.
3:52:38We didn't tell them to these tables.
3:52:40These are the tables that the agent actually just kind of built.
3:52:43A table where the lead can announce things,
3:52:45assign roles to workers.
3:52:47everyone, you know, agents can post notes, a subtask table, a table that indicates whether
3:52:52or not things are landed. So the lead just creates these tables to orchestrate this team.
3:52:56And this is a visualization showing how the agents wrote to and read from these tables over the
3:53:03course of this run. Now, red on the top is showing writes to the tables, green is showing reads.
3:53:08What's really interesting is you can see occasionally the lead right into the announce
3:53:11table. This kind of announces major global, like, kind of announcements about the problem.
3:53:17it also signs workers, these helpers,
3:53:20different statements in this theorem as they proceed.
3:53:23Notes are where they communicate and share kind of progress.
3:53:26Land is where they kind of actually write the lean code
3:53:29as part of the proof.
3:53:31And so the agents all autonomously,
3:53:33without specific prompting,
3:53:35use the database in this way to coordinate their work
3:53:37on this extremely hard long horizon task.
3:53:40This ran for around 30 hours.
3:53:42And for particularly challenging parts of this proof,
3:53:46They actually developed their own abstractions.
3:53:48This is actually a task tree for this Lagrange tunnel.
3:53:50This is one of the harder statements in the proof.
3:53:52And this is actually showing the different dependencies of the tasks within this tree.
3:53:57And this is actually showing over time how, you know, the progress from, like, in progress to done in red.
3:54:03So the point of all this is really just to kind of highlight,
3:54:07agents can solve very long horizon problems without much scaffolding.
3:54:11This is showing kind of the overall kind of allocation of the agents across these different tasks over the course of this run.
3:54:20And this kind of shows how the lead and the agents themselves kind of reallocate themselves and kind of reassign themselves to different parts of the problem as it progresses.
3:54:30And as these statements, there's 60 statements in this proof, are all solved.
3:54:34So the agents using simple primitives, Git, and the database
3:54:38can coordinate themselves across this very hard problem
3:54:41to solve it progressively over time.
3:54:44That's really the key point, and you can see time progressing here.
3:54:47From one of our runs, this is one of the notes that the agents left,
3:54:50basically saying total freeze of the origin, effective now,
3:54:54magnificent work, all 999 of you.
3:54:57So basically, what is really interesting about this
3:55:00is we were able to show this formalization,
3:55:04which was expected to take many, many years.
3:55:07Back in September, we showed initially
3:55:08we could do it with like a dozen agents
3:55:10with a lot of scaffolding.
3:55:12This proved to be a harness
3:55:13and a lot of poking and support from a researcher.
3:55:17This new result is showing
3:55:19we provide a lot of structure
3:55:21in terms of safety and monitoring,
3:55:23but the agent team was able to accomplish this task
3:55:26with very simple primitives,
3:55:28without a domestic harness in this particular case.
3:55:31and agents are getting increasingly good at orchestrating themselves
3:55:34and knowing how to coordinate using these simple primitives
3:55:37for very challenging long-horizon tasks.
3:55:39That's really the key kind of observation,
3:55:40which is very interesting from this work.
3:55:44Now, I want to shift gears and talk about memory,
3:55:46which is entirely different when I talk about it in terms of multi-agent,
3:55:50but it's highlighting another area
3:55:51where we're seeing Claude gain significant capabilities.
3:55:54So previously, we talked kind of about Claude's ability
3:55:56to orchestrate large teams to solve very long-horizon problems.
3:55:59memory is a different capability.
3:56:01It's showing that Claude is increasingly capable
3:56:03to organize this context
3:56:04to help solve long horizon problems.
3:56:08So I published an Eng blog on this fairly recently
3:56:10and this is actually the lead line of the blog.
3:56:13I think this actually encapsulates the idea of the blog
3:56:15and like one of the central ideas around memory
3:56:17I think is very interesting.
3:56:19And this is from the philosopher Kierkegaard
3:56:21so life can only be understood backwards
3:56:23but it must be lived forwards.
3:56:24This is a fundamental paradox of agent memory
3:56:27because agents write to memory typically as they go about a task.
3:56:30They encounter something weird or interesting, they write to memory.
3:56:34But memory needs to be a coherent map of an agent's knowledge
3:56:38that agents can look back on and reflect on.
3:56:40So when they're writing to memory, they're writing kind of myopically.
3:56:43They're looking greedily within a session,
3:56:45saying, ah, this seems important for this task at hand.
3:56:47But memory needs to be something that's globally coherent and not redundant.
3:56:51So this is like a very tricky paradox of memory.
3:56:54And frankly, we as humans have the same kind of challenge.
3:56:58We go about our day, we write to short-term memory.
3:57:01It's believed that the hippocampus kind of is the place that that's orchestrated.
3:57:04At night, it's believed that the hippocampus replays to the neocortex
3:57:08is where long-term knowledge is stored.
3:57:11So it's believed that actually this dreaming process for humans
3:57:13helped consolidate the fragments or like the most important aspects
3:57:17of our daily experience into long-term knowledge.
3:57:19There's this decomposition between daily memory and kind of long-term knowledge.
3:57:24And we found agents can benefit from the same decomposition.
3:57:27That's really the key point of the post.
3:57:30Now, here's some results kind of telling the story.
3:57:32So this is actually an open-source continued learning benchmark called CLBench.
3:57:38And this is showing that different models, as you go from like Sonnet up to like Opus 5.5,
3:57:45get increasingly good at using memory.
3:57:47Now, this task is a very simple setup.
3:57:48it asks Claude to solve 40 questions about a database. In between each question
3:57:53it's a fresh session and Claude can write to notes like a memory directory
3:57:57between each session. So it's kind of like a set of sequential questions and Claude
3:58:01can write memories to help with future questions, right? So what happens is the
3:58:07dark bars are showing when you give Claude the memory store and then the
3:58:11hash is like without memory, okay? Now what's interesting is with Sonnet 4.6
3:58:16giving Sonnet memory, you can see in the dark blue, has very little benefit. Can't
3:58:22really use memory. And we looked in the results and we found Sonnet doesn't
3:58:26doesn't reliably know when to write to memory. It also doesn't really naturally
3:58:31read from memory, okay. It's also worth noting that these experiments are done
3:58:36with no specific memory prompting. It just tells the agent the directory is
3:58:40available. Use memory if you want. That's really it. So Sonnet 4.6 doesn't natively
3:58:45memory effectively sonnet 5 does indeed better opus and so on and so basically the models get
3:58:51better and better with the same simple instruction at using memory and really the key idea here is
3:58:57that what happens is with stronger models they know intrinsically when to write to memory
3:59:03and they kind of know intrinsically when to read from memory to retrieve information their
3:59:07memories are also better they're like they're highly verified statements or predictions about
3:59:11kind of the state of the database or what may happen next versus earlier models tend to write
3:59:17lower quality memories. I'll show you a very fun example of this from a different game.
3:59:22This is from Pokemon. So this is showing you Cloud 3 7's memory directory from Pokemon versus Fable 5.
3:59:31Here is the key point. The size of each box indicates the
3:59:36the number of memory files in each of these directories.
3:59:40Okay, so when we have Claude Pay Pokemon,
3:59:42we give Claude a memory directory,
3:59:43just like I did in that prior benchmark, right?
3:59:46Claude can write whatever it wants that directory
3:59:47while it plays the game.
3:59:49What's really interesting is,
3:59:51Sonnet 3.7, we see it writes a huge amount to memory.
3:59:54And when you look at the memories, it's indiscriminate.
3:59:56It's basically writing down all sort of experience.
3:59:59It creates this
4:00:00huge, unwieldy, just disgusting memory directory of things that are not really relevant or strategic for gameplay.
4:00:05And it proceeds much worse in the game than Fable 5.
4:00:09Fable 5's memory directory is much tighter. It's really strategic insights, tactical knowledge, things you can't just get from game state very easily.
4:00:17So what we see is better models have much better instincts for salience and what to write to memory.
4:00:23and you can see this reflected in the size of the memory directories,
4:00:26it's much tighter, it's much more strategic,
4:00:28and gameplay, indeed, with Fable 5, gets much further than Sonic 3.7.
4:00:32So it gives another intuition around the fact that Claude
4:00:35is much better at writing to memory,
4:00:37knowing what to write in salience and what's salient,
4:00:41and also using and reading from memory.
4:00:44So models are getting more and more effective
4:00:47at knowing salience, knowing what to write, and also reading.
4:00:51Now both of these represent what I would consider in my initial framing of like writing to memory during experience
4:00:58So basically in both of these tasks we let Claude write to memory while plays this game
4:01:02We let Claude write to memory while it does the CL bench benchmark
4:01:06But as I mentioned there's also the dreaming side of memories
4:01:09This is allowing Claude to reflect over memories to fix things and I'll show some interesting examples of that
4:01:16This is kind of a framing of dreaming
4:01:19And so you can think about memory in terms of there are transcripts.
4:01:25Transcripts you can think about as kind of the foundation of memory.
4:01:27So imagine a memory system could very simply be just transcript search.
4:01:32Claude writes your transcript as it goes about a task.
4:01:35Future sessions can read from the transcript.
4:01:37Of course, transcripts are large.
4:01:39It's very unwieldy.
4:01:40We talk a lot about in the blog post the fact that transcripts often contain information that,
4:01:44you know, a very, very small amount of information in transcripts is actually salient and matters.
4:01:48So we also allow Claude to do things like writing memory notes.
4:01:51That's what I just talked about.
4:01:52As it goes, it can write notes to memory.
4:01:54But dreaming lets you do more.
4:01:56Dreaming lets you reflect over transcripts and these written notes
4:01:59and re-represent them.
4:02:01Build memory representations like wikis, as an example.
4:02:05Actually promote certain memories to injected context
4:02:07and load it preemptively into every future session.
4:02:09So dreaming is this mechanism where you can kind of process existing transcripts
4:02:14or existing memory notes and build new things from them,
4:02:17including representations, injected contexts, and more.
4:02:21So some fun examples of this.
4:02:23This is from Pokemon Gameplay.
4:02:26Dreaming is an effective way to correct mistakes in memory.
4:02:28So as I talked about, when Claude's going about a task,
4:02:30it can write incorrect notes to memory.
4:02:33It makes a mistake.
4:02:34This happened in this particular game.
4:02:39Claude incorrectly wrote the location
4:02:41of a particular landmark in the game.
4:02:44Now what happened is with this incorrectly written memory,
4:02:48Claude got trapped in a loop where basically it would mislocalize itself
4:02:52at this particular point in the game, fall down this trap door,
4:02:54and it would basically send it back to the prior level.
4:02:56That's like the high-level intuition.
4:02:58The details aren't that interesting or important.
4:03:00The key idea is a poison memory was injected and it's stuck there.
4:03:05Dreaming can rescue that.
4:03:06That's really the intuition on why dreaming is extremely powerful
4:03:09for reflecting over memories and correcting them.
4:03:12So this is showing some trajectories of the game.
4:03:15Where orange is memory and dreaming, up is good.
4:03:19So basically up represents game progress,
4:03:21and down represents kind of game regression.
4:03:23And what's interesting is raw memory,
4:03:27basically without dreaming, we can see crashes out.
4:03:31An incorrect memory is planted,
4:03:33and Claude continues to basically regress or fall in the game
4:03:36when it hits that particular point.
4:03:37Where dreaming it rescues that mistake,
4:03:39Claude proceeds to the next level.
4:03:41That's really the key observation.
4:03:42And this is a very general principle,
4:03:44that Claude can use dreaming to correct mistakes in memory
4:03:46that are otherwise stuck there.
4:03:48It's a very important way you can kind of correct from errors.
4:03:52Now, this is another fun example
4:03:54of building representations in memory.
4:03:56So there's been a lot of interest in wikis
4:03:58as kind of general kind of ways
4:04:01that Claude can organize knowledge.
4:04:03This is a really fun example from,
4:04:06we acquired a company, Stainless, back in May.
4:04:09And we had access to the company corpus,
4:04:12all its documents and Slack messages and so forth,
4:04:14and we anonymized things,
4:04:16and we built kind of a data set from it
4:04:20which allowed us to test Dreaming.
4:04:22So what we did was we created kind of an email set
4:04:25of 25 questions about the company
4:04:27that can only be answered from this corpus.
4:04:29We allow Claude to build a wiki from this information
4:04:33to help it answer questions.
4:04:35What you see is we compare a raw search tool
4:04:38That's just like some kind of semantic search over this kind of documentation.
4:04:42We compare that as a baseline, which does reasonably well.
4:04:45You can see it's like 53% just for search.
4:04:48We also test letting Claude build a wiki over this knowledge.
4:04:53You can see as you push, you add more and more dreaming tokens,
4:04:56the wiki gets better and better and better allowing Claude to answer questions.
4:05:00So Claude natively can kind of build up over time
4:05:03a representation of this kind of corpus of knowledge through a wiki.
4:05:08And as you add more dreaming compute, the wiki gets more and more useful.
4:05:11We think there's a really nice mental model to think about how agents can kind of build knowledge over time.
4:05:16They can be given access to kind of raw corpuses of text, of transcripts,
4:05:20and they can kind of build these representations that allow them to search those contexts much more easily,
4:05:24to answer questions and to connect their knowledge in effective ways.
4:05:28We also find that adding the wiki and the search tool together actually bumps further beyond just raw search.
4:05:33So it's kind of another intuition that basically Claude can also build representations like wikis in its kind of memory in order to help it solve problems.
4:05:44And a final example, this is from a different benchmark, but this is showing two different wikis that Claude built.
4:05:52So this is prior to dreaming and after dreaming.
4:05:55What we saw is when Claude was building wikis in this particular case, there were some gaps.
4:06:00And, for example, this initial wiki had a bunch of placeholders
4:06:03for pages that didn't exist.
4:06:05This can happen when Claude's kind of building
4:06:06different memory representations.
4:06:08And without Dreaming Compute, there may not be opportunities
4:06:10to rescue or fix those errors.
4:06:13What we saw is when we ran Dreaming,
4:06:15Dreaming can look over Claude's existing representation,
4:06:18like, for example, a wiki, and can fill in mistakes.
4:06:21So in this case, it fills in all the missing gaps.
4:06:23It creates an index.
4:06:24And so, again, Dreaming is a way that Claude can reflect
4:06:27and kind of apply compute across its memory to improve it
4:06:30by correcting mistakes, like I talked about,
4:06:32by filling in gaps in its knowledge, like we see here,
4:06:36or, for example, by creating new representations like wikis.
4:06:41So with that, I thank you all for listening,
4:06:44and I'll be at the Anthropic booth,
4:06:48so please come see me and happy to talk about any of this.
