{
  "video_id": "IGo225tfF2I",
  "channel_slug": "claude",
  "channel_handle": "claude",
  "title": "Memory and dreaming for self learning agents",
  "duration_seconds": 1294.0,
  "url": "https://www.youtube.com/watch?v=IGo225tfF2I",
  "upload_date": "",
  "transcript": "Hello. Thank you for joining us today.\nI'm excited to kick things off on uh the\nbreakout stage. My name is Ravi and I\nlead the API knowledge team within\nplatform at Enthropic. And since joining\nAnthropic last year, my focus has been\ncreating the building blocks for agents\nto interact with many forms of\nknowledge, ranging from the context\nwindow itself to skills, files, and even\ncontent on the web. And we recently\nreleased two features that I'm most\nexcited about.\nMemory and dreaming. We now have the\nbuilding blocks for agents to learn over\ntime and improve from one task to the\nnext. And I'll talk about why we think\nmemory is important, how we designed it,\nand we'll close out with dreaming, our\nnew frontier memory feature.\nThere we go.\nBut first, a quick timeline of\nmilestones that got us here. And the\nimportant thing is models have been\nimproving and agents are capable of\ncompleting tasks that take many many\nhours and are increasingly complex. So\nin 2024\nwe released model context protocol MCP\nand this gave models access to external\ntools and data in a principled way. In\n2025, we released Cloud Code and the\nagent SDK, which lowered the barrier to\nusing and building agents,\nwhich as an aside, that blows my mind\nthat that was in 2025. It honestly feels\nlike a lifetime ago. Later that year, we\nlaunched skills, which gave model models\na generic abstraction for unlocking and\neffectively bolting on new capabilities\nto complete specific tasks.\nLast month we released cloud managed\nagents a platform for reliably running\nagents that takes care of the hard\nparts.\nNow\nthe important through line here is that\nagents can do more and they can operate\nover longer and longer time horizons. So\nin 2025, Meter released a study saying\nthe length of tasks that agents can\ncomplete is doubling every seven months.\nAnd we're seeing this happen.\nBut managing context over long horizon\ntasks is still a work in progress. And\nthat's where memory comes in.\nMemory lets agents learn.\nIt lets agents carry forward learnings\nfrom their previous tasks. And in the\nsimplest sense, imagine a set of tasks.\nTask one, task two, task three, and so\non. The goal is for performance to\nimprove from one task to the next. In\nthe base case without something like\nmemory, performance on each task might\nbe similar\nbecause every agent is just starting\nfrom the same slate. In the optimal\ncase, performance improves from task one\nto two, task two to three, and so on.\nThat's the goal. Learning from task to\ntask, but also from environment to\nenvironment and agent to agent. So with\nmemory agents can learn from common\nstrategies and previous mistakes. They\ncan learn from the tools they have\naccess to or code bases and files. And\nfinally they can transfer these\nlearnings to and from other agents.\nThink swarms of agents contributing to\nand maintaining a shared understanding\nof the organization they work in.\nThis is the dream.\nSo we recently launched memory for cloud\nmanaged agents and this is a major step\ntowards this vision. It gives developers\na frontier memory system that is built\nto maximize intelligence out of the box\nand it supports multi- aent systems all\nwith enterprise control and\nobservability.\nAnd we built memory in partnerships with\nseveral teams that are using managed\nagents. And the results speak for\nthemselves. Racketin saw a 97% decrease\nin first pass errors in agents deployed\nin production. Wise docs reduced common\nissues using cross session memory in\ntheir document document verification\npipeline. And the through line here and\nthe common feedback we get is that our\nmemory primitive allows teams to focus\non building the product not the infra\nand all while reaping the benefits of\nincreased intelligence that comes along\nwith better memory.\nNow\nyou might be thinking is memory really\nnew? Rightfully so.\nMemory is a concept that's not entirely\nnew, but our approach for it with agents\nhas greatly evolved and previously we\nbuilt memory focusing on capabilities in\nthe harness. So you might be familiar\nwith claw.md for cloud code or dedicated\nmemory tools in the SDKs.\nBut one pattern we're seeing is that as\nmodels improve, we really just want to\nget out of Claude's way, similar to what\nwe did with skills. And skills was a\nvery basic format that was highly\nflexible. And it created endless\npossibilities. And the model understood\nhow to operate with it. And so with\nmemory, we've leaned into that same\ndirection with files.\nSo let's talk about some of the\ncapabilities that we design memory\naround. So right now with the current\nset of models, we know a few things.\nModels and claude are great at\nnavigating virtual environments and a\nfile system. And Claude is also very\ncapable at using familiar tools like\nbash and GP to read, update, and\norganize files.\nOpus 4.7\nthat we launched last month is a\nstate-of-the-art model at file system\nbased memory and it's increasingly\ncapable of discerning which context is\nmost important to save for its future\nself and how it should be structured and\nhow it should be represented. And so\nwith memory we've modeled it as a file\nsystem to quad. Again, the key principle\nis getting out of cloud's way and\nletting it use the capabilities it\nalready has that are very strong. Or as\nwe like to say, let it cook. This is the\ndream.\nBut we've talked about Claude's memory\ncapabilities within the context of a\nsingle agent, but we want it to work\nacross multiple agents that are\noperating in the same environment at the\nsame time or maybe across environments.\nAnd this introduces new requirements\nlike for example letting multiple\nsessions share the same memory store at\nthe same time. And maybe they want\ndifferent scopes. So we offer readonly\nscopes and read write scopes. So for\nexample, you could have organizationwide\nmemory that's readon and it's updated\nfairly infrequently and it can be\naccessed by all agents and the same set\nof agents can have access to more\ngranular memory stores that they can\nread and write freely and so this\ncreates a hierarchy and uh allows the\nmemory system to really scale.\nNow, to combat right conflicts, to make\nsure that one agent isn't clobbering\nanother's rights, we employed a\noptimistic concurrency control model to\navoid agents overwriting each other's\nchanges.\nAnd last but not least, memory needs to\nwork for real production agents. This\nmeans enterprisegrade controls. So\nversion control uh creates an audit\ntrail as agents make changes and\ndevelopers can see how memory evolves\nover times. They can even diff between\nversions and there's attribution to see\nwhich agent wrote which part of the\nmemory.\nAnd I think one of the most important\npieces is that memory has a standalone\nAPI. It enables developers to manage\ntheir memory from anywhere. And the\nreality is teams are building their\nsystems in many different environments.\nSo they can use memory via these APIs\nwhich provide standard credit operations\nbut also more enterprise focused\noperations like exports and redactions.\nOkay. So we've covered three key\ncomponents of a memory architecture.\nOne, we started with the storage layer,\nwhich is how the data is managed itself\nand how changes are tracked. Next, the\nstructure of memory, optimizing in a\nformat that allows Claude to get the\nmost out of it. And finally,\ncloud-driven processing for updating the\nmemory.\nNow, let's stop at that processing\npoint.\nagents writing memory as they work is\nvery key to the processing layer. Think\nof it as taking notes while you're doing\nsomething. But as we scaled up this\npattern to more complex multi- aent\nworks like uh use cases, we started\nseeing some limits across different\nsessions and we started seeing some\ncommon patterns. For example,\nagents were prone to making many of the\nsame mistakes and they learned from\ntheir mistakes independently. agents\nalso displayed some of the same patterns\nof inefficiency.\nAnd the general theme was memory was\nbeing updated in a locally optimal way,\nbut it wasn't globally optimal. In some\ncases, there was duplication or\nfragmentation.\nAnd so we started thinking really deeply\nabout this problem and in the last\ncouple of months we built a feedback\nloop in the processing layer that combed\nsome of these problems.\nNow, I've said it a couple times, but\nthis time I mean it. This really\nis available in research preview right\nnow, and it can be used with managed\nagents.\nIt's a process that looks for patterns\nand mistakes across agents and sessions,\nand it automatically\ncurates their memory.\nCustomers\nlike Harvey saw a six times increase in\ncompletion rates for their legal\nbenchmark with Dreaming and we're\nactively seeing other usage of Dreaming\nand we're really excited to see how\npeople are benefiting from it.\nA quick overview of how\nit is process\nfrom sessions. It's completely\ndecoupled. Think of it like a feedback\nloop. Agents write memories and dreaming\nrefines and this process repeats. And\ndreaming can be kicked off ad hoc,\nnightly, hourly, or it can even be\ntriggered by events like the end of a\nsession. It's all controlled via API.\nSo, it's very flexible.\nEach dreaming run analyzes session\ntranscripts. It inspects the existing\nstate of memory and it proposes\noptimizations to the memory in scenarios\nwhere sessions were inefficient, made\nmistakes or needed improved guidance.\nAnd the output is a verified better\norganized snapshot of memories that\nagents can choose to adopt.\nAnd dreaming truly enables continuous\nselfarning. It closes the loop on\nmemory.\nI mentioned outofband the outofband\ncomponent of dreaming is really really\ncritical\ncreating a process that's decoupled from\nthe underlying agent loop has benefits\nfor one architecture makes it useful for\nmulti- aent systems looking at cross\nsession cross agent transcripts discerns\npatterns that a single agent in\nisolation might struggle to identify\nThere's also benefits to having a\ndedicated dreaming harness. It allows\nfor clearer objectives. Since dreaming\nis an independent process, there's no\nrisks of agents needing to trade off\nbetween\nimproving their memory quality or\nactually just completing their task\nobjective.\nIt's clean separation. And lastly, it\ndoesn't add any latency to the agent.\nIt's completely removed from the hot\npass.\nSo zooming out,\nwe now have a robust memory layer that\ncan be shared across agents and\nenvironments instead of only within\nspecific tasks or usage. We also have\ndreaming, a process that globally\noptimizes and reconciles memory across\nagents.\nAnd the result is a capable memory\nsystem for organizational memory that is\ncapable of scaling up both the size as\nwell as the quality of memory. And the\nway I think about it is sharing memory\nthat's constantly improving across\nagents raises the floor for every agent\nand dreaming raises it even further.\nAnd if you really explode the size of\nthis capability and you pull it all\ntogether, memory becomes a huge source\nof knowledge.\nmodels or test time compute where\nletting models spend some tokens to\nexplore a problem on average produces\nbetter outcomes. With dreaming, agents\nare doing the same thing. They're\nspending some work up front to curate\nand produce higher quality memory and\nthat pays dividends for all downstream\nagent performance.\nWe believe that dreaming and memory form\nthe basis of a frontier memory system.\nMemory on the left helps agents learn\nand remember from task to task and\ndreaming on the right verifies,\norganizes and enriches the memory.\nThe way I think about it is dreaming is\nthe bridge between memory as we know it\ntoday and organization scale memory and\nknowledge.\nNow I'm going to flip over to a demo.\nSo this uses both dreaming and memory in\npractice. It's an agent platform for\nSRRES\nand everyone loves being on call, right?\nSo here we have a system that looks at\nincoming alerts and pages and for some\nof them it actually uh spins up agents\nthat decide how to triage and fix the\nissues as they come up\nand it has access to a couple of memory\nstores. One is a readonly orwide\nknowledge memory store. And so this\ncontains things like the SLO policy or\nrunbooks and on call mappings\ninformation that doesn't change very\noften but is important for every agent.\nAnd it also has access to read write\nmemory stores that are specific to the\ntask at hand.\nNow\nwe can dig into an interesting example\nhere where an agent investigated\nand found the root cause of an alert\nand\nit put up a fix and it noted in memory.\nYou can see the writes. It noted in\nmemory that a fix was in flight and it\nwas incoming. And then\nthe shared memory store can be read by\nuh subsequent sessions. And so here we\ncan see that when a similar issue\narises,\nthe downstream session already knows\nthat a fix is in flight and it's able to\nact based on that information.\nAnd I really think this is\njust such a cool pattern because you\nknow the I I was once an SR in my career\nand this really uh helps coordinate\nacross all agents\nand it's really cross- session memory at\nwork.\nNow for running in enterprises uh an\nimportant piece here is audit logs and\nhistory. So with memory you can see the\nfull version history. You can switch\nbetween different versions and you can\nalso attribute the rights to specific\nsessions. And there's also a\nprecondition here and that's the\noptimistic concurrency model to make\nsure that agents aren't clobbering each\nother's rights.\nNow\nwe'll flip over to the cloud console.\nOne moment.\nThere we go.\nSo, here we see the list of underlying\nmemory stores that we were using in that\napplication. And so, we'll go over to\nour team SR memory store. And you can\nsee exactly the underlying files that\nwere populated there.\nAnd we're going to head over to the\ndreams tab. And we're going to kick off\na dream. And so this can also be done\nvia the API uh but also in the UI. And\nwe're going to select the team SR memory\nstore and we're going to select a batch\nof sessions from the last seven days. So\nthat's about five.\nAnd we're going to start dreaming.\nAs it begins, you can see it making\nprogress.\nYou can look at the dream and see that\nthere are five input sessions. And then\nyou'll see there's actually an output\nmemory store that's being compiled. And\nyou can actually open the dreaming\nsession. This is an important piece.\nDreaming itself is built on cloud manage\nagents. So it's a feature for cloud\nmanage agents built on cloud manage\nagents itself. You can see that it spins\noff a series of sub aents to analyze\ntranscripts in parallel. And it has all\nthe same UX as the rest of manage\nagents. And we'll fast forward to a\ncompleted dream session. And you can see\nthe diffs on the memory store updates.\nAnd\nin this example here, we see that\nacross sessions and across agents,\nthere's a a common pattern of an alert\ntriggering 60 seconds after a CPU spike.\nAnd this is a recurring pattern. And so\nit starts to discern that there might be\nsome issue with the retry behavior.\nAnd so it makes a note. So this dreaming\nprocess makes a note and updates memory\nso that the next agent that sees this\npattern can actually\nsimilarly updates the triage log in a\nmore holistic way rather than just being\na wrote log of all the events that\nhappened.\nAnd that's memory and dreaming at work.\nSo we'll flip back over to the slides\nand we'll close out. So with that demo,\nwe saw how we can build a a production\nagent that uses memory and dreaming to\nself-improve the agents.\nAnd\nthis year I think is going to be a\nreally big one. We're going to see\nagents run for longer and longer time\nscales, days for example, and\ncontinuously building upon and improving\ntheir understanding and view of the\nworld around them is very critical to\nunlocking that capability. And I think\nmemory systems are going to be a big\npart of what makes this behavior\npossible. So give it a try. I'm excited\nto see what everyone builds with it. And\nI'll be outside if you have more\nquestions. Thank you.",
  "transcript_chars": 15833,
  "ingested_at": "2026-05-21T18:42:21.896946+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 741,
    "like_count": 41,
    "channel_id": "UCV03SRZXJEz-hchIAogeJOg",
    "categories": [
      "Science & Technology"
    ],
    "tags": []
  }
}