Conference talk by Karthik Ranganathan (Yugabyte) on why per-agent memory is largely solved while shared learning across multiple agents is not: when agents hand off work, reasoning, dead ends, and context are lost, forcing the next agent to re-derive them. Topics include five misconceptions about memory, lessons from Yugabyte's year of building agents, and a RAG pipeline fix that reportedly raised faithfulness from 14% to 82% with roughly 7x less context. Heather Downing demos Meko, Yugabyte's agent-native persistence layer, including session resumption across agents and promoting private memories into shared data packs. Recorded at the AI Engineer World's Fair in San Francisco. # Channel Presentation Observations **Video:** "Agent Memory Is Solved. Agent Learning Isn't." — Karthik Ranganathan, Yugabyte ## Intended Audience - **AI agent builders and engineers**, addressed in a conference-talk register ("Thanks for everyone who's here") with heavy technical detail (MCP server, data packs, RAG pipelines, Claude Code, CodeEx). - Practitioners building **multi-agent systems in organizations** — the framing assumes teams of humans coordinating agents: > "learning is never done in isolation. It's when a group of agents come together and need to work with each other" - Prospective product users, given direct calls to action at the close: > "you should try it for free… the website makeata.ai… There's a free tier" > "Do join us on Discord" ## Claimed Scope - A **problem-defining thesis**: memory solved, learning unsolved. > "Agent memory is a solved problem, but agent learning is not." - **Five architectural misconceptions** the creator claims to debunk (more memory, shared state, RAG-ing transcripts, fine-tuning, bigger context windows), each labeled "an architecture gap." - **Empirical performance claims**: faithfulness improving from "14%… 20%… 57% context precision" to "65 74 82" while context size dropped "from over 7,000 chunks to about a,000 chunks." - **Product claim**: Mako is "an agentnative persistence layer that takes all the mistakes we made and all the things we got right and puts it into one box." ## Self-Description Evidence - Speaker self-identifies with role and company: > "I'm Karthik, one of the co-founders and a CEO of a database company, Yugabyte DB" - Positions himself as an infrastructure practitioner, not just a vendor: > "we're infrastructure people" - Describes hands-on agent deployment experience (two internal agents: Hagen, Growth Vector; two external: Perf Advisor, Voyager). - Frames the product as born from internal failure, stated emotionally: > "if a database company is failing at a data problem… it becomes personal" ## Demonstrated Presentation Patterns - **Dogfooding as credibility**: the slide deck itself was built using Mako as the context layer, with a collaborator (Heather) exchanging an outline via data pack rather than meetings ("we barely talked"). - **Live/recorded tool demos**: resumability across sessions and IDEs, permissioned memory promotion (private → shared), and token-cost tracing "all the way down to the tool call." - **Failure-storytelling**: multiple failed approaches narrated candidly (knowledge base, per-agent Postgres, no-UI backend, poor initial RAG benchmarks). - **Speculative roadmap claim** (explicitly framed as future): "Human promotions today kind of equal the training signal for self-improving orchestration tomorrow." - Conversion-focused close: free tier signup link and Discord community invitation. ## Notes for Synthesis - This video blends a **conference technical talk with a product pitch**; claims about benchmarks and cost savings are creator assertions, with the demo as the only in-video supporting evidence. - No curated metadata beyond the title was supplied; the title itself frames the channel's positioning around a memory-vs-learning distinction. # Delivery Observations — "Agent Memory Is Solved. Agent Learning Isn't." (Karthik Ranganathan) ## Tone - **Conversational and self-deprecating**, built around failure as a narrative device: > "We failed to ship anything and make it work at all. It was really hard." > "We built a whole distributed rag pipeline, extremely scalable, very elastic, amazing. It was just amazing, right? And it didn't do anything good for us." - **Emphatic and informal**, with casual intensifiers ("the hell," "shitty") used for emphasis rather than shock value: > "So what the hell are we doing here?" > "Well, it turned out even that was shitty" - **Humorous asides** appear throughout, often aimed at infrastructure budgets: > "at some point this is ridiculous right it's breaking the laws physics" > "if a database company is failing at a data problem be it for agentic it becomes personal" ## Vocabulary - Heavy use of **concrete, tangible metaphors** for abstract concepts: context as something that can be handed off, promoted, degrade, rot, or burn tokens: > "Your context rots." > "You need to go through a process of supervised promotion." - **Metrics used as punchlines**: benchmark numbers are delivered rapid-fire to show honest failure and then recovery: > "14% faithfulness using an MD benchmark... 57% context precision" > "we were able to jump to 65 74 82" > "17th the context size, a lot higher precision and a lot less money burned on tokens" - Framing around **token spend as a recurring cost motif** ("burning tokens," "burn through tokens again and again," "less money burned on tokens"). - Product-agnostic comparisons by nickname ("cloud desktop," "chat EBT" for ChatGPT) rather than polished brand names. ## Recurring Phrases and Fillers - **"Right?" as a check-in tic** — appears constantly, e.g.: > "today we're going to talk about sharing context, right? Everything in AI is about the data you give it." - **"How hard can it be?"** — repeated as a setup for each failure: > "we started building this by assuming how hard can it be" > "Tiny Postgress, make it efficient. Well, we realized that every repeatable workflow was being reinvented on the fly." - **"What the hell"** recurs as an emphatic marker ("what the hell are we doing here," "what the hell's going on," "where the hell did this piece of information come from"). - Frequent **"you know," "okay,"** and **"um"** fillers, especially at paragraph and slide transitions. ## Teaching Habits - **Contrast-driven framing**: nearly every concept is defined by what it is *not*: > "Agentic memory is not learning. It's just more memory, right?... Shared state is not shared knowledge... Rag transcripts... is not equal to learning and quality." - **Numbered lists as structure** ("So, five things, misconceptions," "So the first thing we did was..."), keeping the talk checklist-organized. - **Real failure stories over abstractions**: the signup email incident, the benchmark numbers, the failed pipeline attempts all serve as teaching anchors. - **Human analogy as the primary explanatory device** — repeated multiple times: > "When a new person joins the team, they're going to be told, 'We're going to do X.' And they come up with 50 reasons why we should do something else." ## Communication Patterns - **Rhetorical-question openers** for each section ("What is the real failure? What is Mako? How do you even know that it saves you tokens?"). - **Collaborative, handoff-aware delivery**: he explicitly defers to his co-presenter and frames the talk itself as evidence of the product: > "This slide deck that you're looking at was built using Makeo as the context persistence layer" > "We barely talked, right? We didn't need to. We just shared context and our agents did the work" - **Direct audience address with honesty about uncertainty**: > "I hope the demo's good because I haven't seen it myself. So, yeah." - **Closing with clear calls to action**: free tier, Discord, "get your agents to start learning right right away." ## Uncertainty Notes - The "Right?" tic and "how hard can it be" refrain are well-supported by multiple instances; they appear stable across the talk. - The candid, humor-forward tone is consistent throughout, but since this is a single talk, it's uncertain whether this tone holds across other venues or formats. - The final minutes include another speaker (Heather) whose delivery is interleaved and not separable cleanly from his in the transcript, so quotes near the end may include mixed voices. # Observation Record: "Agent Memory Is Solved. Agent Learning Isn't." — Karthik Ranganathan, Yugabyte ## Speaker Identification - **Karthik Ranganathan** — identified via curated metadata (co-founder/CEO, Yugabyte DB) and self-introduction in the transcript ("I'm Karthik, one of the co-founders and a CEO of a database company, Yugabyte DB"). - **Heather** — referenced by name by Karthik as demo presenter; appears to speak during the demo segments and Q&A responses (indicated by `>>` turns), though the transcript does not include her self-introduction. Attribution to her is based on Karthik's statements ("Heather was was in charge of the early access and launch of Mako"). --- ## Core Thesis - **Agent memory is a solved problem; agent learning is not.** Per Karthik: memory works per-agent via feeding conversations and extracting/reusing memories, but *"learning is never done in isolation"* — group agents working together must share and learn jointly, which remains unsolved. - Infrastructure built for single-agent memory *"is often not the same infrastructure"* needed for shared learning. ## The Stated Problem: Lost Context - When Agent A hands off to Agent B, it can only share **outputs** (MD files, PDFs, documents) — not the **reasoning, dead ends, or failures** that produced them. - Consequences stated: - Receiving agents **re-derive** context, *"burning tokens and paying somebody else for it."* - Analogy to human teams: new members are briefed on project history rather than re-litigating settled decisions; agents lack this onboarding context. ## Five "Misconceptions" (all attributed to Karthik) | Claim | Position | |---|---| | More memory | Agentic memory is not learning; it's just more expensive memory | | Shared state | Sharing a file ≠ shared knowledge | | RAG over transcripts | ≠ learning/quality; creates "garbage" that wastes tokens | | Fine-tuning | Not scalable for persisting agent lessons | | Bigger context windows | "The quickest way to failure in an expensive manner" — "your context rots" | He summarizes: *"Every single one of these is an architecture gap."* ## Failure Iterations (self-reported by Karthik) 1. **Knowledge base approach** — built a distributed RAG pipeline; "didn't do anything good for us." 2. **Per-agent tiny Postgres databases** — repeatable workflows were "reinvented on the fly." 3. **Backend-only, no UI** — "No human in the loop equals really bad results." 4. **RAG pipeline quality** — even with "best components from academia," initial metrics were poor: - **14%** faithfulness (MD benchmark), **20%** (PDF), **57%** context precision. - After one-variable-at-a-time tuning: jumped to **65, 74, 82**. - Context chunks shrank from **~7,000 to ~1,000** (claims "17th the context size," noting his own arithmetic is approximate). ## Design Principles (Karthik) 1. **Shared context** between agents closes the lost-context problem. 2. **Supervised promotion** — context can degrade; not everyone contributes, "just like code." 3. **Provenance/traceability** — ability to ask where any piece of information came from ("a data source, a person, a conversation"). ## Product: Mako - Described as an **"agent-native persistence layer"** exposing a **"data pack"** (deliberately not called a database; contains vector, graph, relational, NoSQL types). - Stores: knowledge base, memory, conversations, observability. - Flow: agents push context to a **private space** → promote to **shared space** → other agents/humans retrieve promoted context. --- ## Demo Claims (attributed to Heather) - **Resumability**: killed a session and resumed from a fresh chat window — not using Claude projects or memory features; also works across different agents (e.g., claude.ai vs. desktop) because context lives in the shared data pack, gated by promotion for security. - **Sharability**: in a different IDE (Codex), a second account could see the data pack but not the memory until it was **promoted** to shared space; promotion is **fine-grained** (per-piece, though whole data packs can be opened by maintainers). - **Cost observability**: embedded language traces provided "for free," showing decision traces down to tool calls to verify token usage. - **Example incident**: signup emails failed because they used the SES sandbox instead of prod; stored as a searchable memory in an "early access launch" data pack. - **Human promotion as training signal** (Heather): *"Human promotions today kind of equal the training signal for self-improving orchestration tomorrow"* — each human approval is a labeled example of "good promotion"; human-in-the-loop is retained now, with potential future agents trained on individual taste/preferences. ## Organizational Use Cases (Karthik) - Yugabyte runs four agents: internal — **Hagen** (customer support), **Growth Vector** (sales/marketing go-to-market); external — **Perf Advisor** (agentic DBA), **Voyager** (migration/modernization). He reports: *"We failed to ship anything and make it work at all"* for ~a year before diagnosing the data problem. - The deck itself was built via Mako: Heather sent an outline via share request; Karthik used an agent harness (cloud desktop) to build slides; one diagram came from "cloud design." He notes: *"We barely talked... We just shared context and our agents did the work"* and admits *"I hope the demo's good because I haven't seen it myself."* - Other uses: apology email drafting, a data pack capturing his "voice" for LinkedIn posts, onboarding new team members (who "contribute... either willingly or unwillingly" via pattern extraction). - Support scenario (jointly discussed): when a server goes down, multiple agents otherwise waste tokens redundantly checking; a shared data pack lets the first agent inform the rest. ## Closing Position - Goal stated: *"get it closer and closer to how humans work"* — capture tribal knowledge, share it, control sharing, and observe what's happening. - Offer: free tier at makeata.ai, Discord community for feedback. --- ## Unresolved / Qualifications Preserved - Karthik's "17th the context size" claim is arithmetically loose (7,000 → 1,000 is 1/7th, not 1/17th); recorded as stated. - Karthik explicitly disclaims knowledge of Heather's agent harness ("I really don't know. I didn't ask her") and hasn't seen the demo before presenting it. - Heather's claim that human promotions are "a training signal" is framed as current signal with speculative future training ("maybe in the future"), not a settled capability. - Performance metrics (14/20/57% → 65/74/82%) are self-reported without methodology detail beyond "one variable at a time" tuning on public benchmarks. # Observation Record — Video Attribution & Provenance ## Speaker Identification | Speaker | Role | Evidence | |---|---|---| | **Karthik Ranganathan** | Creator / presenter; self-identified co-founder and CEO of Yugabyte DB | "I'm Karthik, one of the co-founders and a CEO of a database company, Yugabyte DB" | | **Heather** (last name not given) | Guest / colleague; delivered the live product demo | "I'll invite Heather to talk to this slide"; demo segment in first person from her perspective | - Unattributed short interjections (">> Yeah," ">> If you want") during the closing segment cannot be definitively assigned; likely alternation between Karthik and Heather, but the transcript does not label speakers. ## Talk Structure & Attribution Boundaries - **Main talk**: Karthik — motivation, five misconceptions about agent memory vs. learning, failed build iterations, benchmark numbers, introduction of **Mako** (agent-native persistence layer exposing "data packs"). - **Demo section**: Heather — resumability, sharability, token cost savings, human-in-the-loop promotion, incident example (signup email failures via SES sandbox). - **Closing**: Karthik wraps up, summarizes use cases, points to free tier and Discord. ## Provenance Facts Recorded ### Referenced tools, products, and benchmarks - Yugabyte DB (Karthik's company); four internal/external agents named: Hagen, Growth Vector, Perf Advisor, Voyager. - Benchmarks cited: MD benchmark, PDF benchmark; **14% faithfulness**, **20% (PDF)**, **57% context precision**, improving to 65/74/82; chunk size reduced from >7,000 to ~1,000 ("17th the context size"). - Third-party tools mentioned: Claude Desktop, Claude Code, Claude Projects/memory, Codex, ChatGPT, MCP server/tool calls, Slack, Postgres. - Slide-deck diagram attributed to "cloud design" (Claude-based design tool); rest of deck built via Claude Desktop on a Mako data pack. ### Third-party claims (unverified within the video) - "Agent memory is solved, agent learning isn't" — Karthik's framing. - Token-savings and cost claims about Mako — product claims by the presenting company, not independently verified. - Anecdote: real signup email failure incident (SES sandbox over-limit) used as demo data. ### Self-reported product context - Mako is Yugabyte's product; the talk includes first-person accounts of internal dogfooding (launching Mako using Mako, troubleshooting data pack, LinkedIn voice data pack). ## Promotional Segments (flagged) - **Product promotion**: Mako / makeata.ai — presentation is effectively a product talk by the company building it. - **Closing call to action**: "Try it for free" — free tier at makeata.ai; **Discord community** promoted for feedback and roadmap communication. - Demo content doubles as product demonstration (resumability, sharability, cost, human promotion features). ## Availability Limits - No paywall or restricted content noted. - Live demo portions were pre-recorded/sped up ("I have recorded this for you at a little bit of a faster speed"; "sped up for your pleasure"). - No comments section referenced in the source material; Q&A deferred to off-platform contact via website/Discord. ## Uncertainty Notes - Heather's full name, exact title, and which "agent harness" she used are not specified ("I'm sure she used some agent harness. I don't know what it is"). - Audience questions in the closing exchange are not clearly attributed in the transcript. Good to meet you folks. Thanks for everyone who's here. Um, today we're going to talk about sharing context, right? Everything in AI is about the data you give it. Bad data, bad outputs, right? Agent memory is a solved problem, but agent learning is not. And we're going to talk about not just like you know what we're building etc. It's about how why we built it and how we're using it for ourselves. Okay. So as we said agent memory works you know there's a bunch of stuff you feed it conversations etc. And you're able to extract memories from the conversation and agents are able to reuse them. It's per agent. However learning is never done in isolation. It's when a group of agents come together and need to work with each other, they have to now start learning and sharing, right? And that is an unsolved problem because we're infrastructure people and infrastructure built for a single agent to do memory is often not the same infrastructure that is needed in order to learn, right? We're going to talk a little bit more about that. Okay, so by way of background, I'm Karthik, one of the co-founders and a CEO of a database company, Yugabyte DB, right? So what the hell are we doing here? Why are we building a aentic data infrastructure? What are we doing doing that? Right? We actually found this the hard way. We run agents for ourselves. We run two agents internal to the company. Hagen for customer support and growth vector for a coordinated go to market between sales and marketing. And we run two agents externally for our customers and users. The first one is Perf Advisor, which is an agentic database admin, right? So it runs databases for our customers as a database company. Pretty useful. And Voyager, which helps them migrate and modernize from other databases to a cloudnative one, right? So four agents. We failed to ship anything and make it work at all. It was really hard. We've been trying for almost a year before we realized we were failing at the data problem right and if a database company is failing at a data problem be it for agentic it becomes personal right so yes it became personal we're like what the hell's going on and when we then realized that a lot of people were asking us like yes we can do scalable vectors we can do scalable graph we can do scalable relational or people came to us and said more scale more performance less cost we're like wait a minute at some point this is ridiculous right it's breaking the laws physics. So what is the real failure? Right? When you cut everything o apart and just go to the core, it's because agent A, my agent is doing some work and I need to work with say one of you guys, say maybe Heather, right? My who's going to be showing a demo and I am not able to give that context. I'm only able to give the output. The output being an MD file, a PDF, a document, a something. But I'm not able to give the reasoning behind it. Right? So what does this lose? This loses reasoning. This loses the deadends, the number of failures you've had before you actually succeeded. And it loses the whole context. Right? That means Heather's agent is going to be rederiving all of this stuff. And it's not for free. You're burning tokens and paying somebody else for it. This is the same as a group of humans working together. When a new person joins the team, they're going to be told, "We're going to do X." And they come up with 50 reasons why we should do something else. And each time, yes, we considered that two weeks ago, two months ago. That's not how humans operate. We actually bring the person in and says, "Okay, look, this is the context. This is the history of the project. This is how it's done. Now, let's go from here." That context is missing for agents. So, five things, misconceptions. Okay, really quick. More memory. Agentic memory is not learning. It's just more memory, right? Like it's more expensive. Shared state is not shared knowledge. Just because you can share something with somebody else, like an MD file or something, doesn't mean you have shared knowledge. Rag transcripts, let me rag everything, is not equal to learning and quality. It just means there's a whole bunch of garbage there and now LLMs get to burn even more tokens to give you even worse results. Fine-tuning is not scalable. You cannot, you know, save and persist lessons that agents have come up with through fine-tuning and building custom infrastructure. And a bigger context window is the shest way to quickest failure in an expensive manner, right? Because it doesn't do anything. Your context rots. Every single one of these is a architecture gap, right? So this is what we realized we needed to plug for ourselves, right? Right. And we've been finding a lot of users are are really enjoying and really liking this approach of thinking about context. Firstly, if there's a context that agent A can share with agent B, it closes the lost context problem. They're working on the same context. Second thing is this context can degrade. That means not everybody can contribute to that context. It's just like code. Not anyone can contribute. You need to go through a process of supervised promotion. And only then does it make it durable. And lastly, you need to be able to ask your the question, where the hell did this piece of information come from? It makes no sense at all. And be able to trace it back to something, a data source, a person, a conversation from which it was extracted. And that's the first step to improving your context. So we started building this by assuming how hard can it be. So the first thing we did was it's just a knowledge base. We throw everything in the knowledge base. is going to be great, right? And how wrong we were. We built a whole distributed rag pipeline, extremely scalable, very elastic, amazing. It was just amazing, right? And it didn't do anything good for us. And then we said, you know what? This whole shared stuff doesn't work. We'll let every agent spin up a tiny database. We're a database company. How hard can it be? Tiny Postgress, make it efficient. Well, we realized that every repeatable workflow was being reinvented on the fly. Didn't work at all. And then we said, "Okay, fine. we'll just have some backend that does a whole bunch of processing and you know we'll just you know not even bother with the UI cuz agents don't need UI and then we realized we couldn't tell what was going on. No human in the loop equals really bad results. Okay. And then we thought okay at least we have the rag pipeline. Well, it turned out even that was shitty because, you know, we took all the best components from the, you know, whatever the academia academia says and we put it all in there and we got poor numbers. 14% faithfulness using an MD benchmark, public benchmark, 20% on a PDF, 57% context precision using all of this other stuff. And when we actually started looking and tracing and doing our traces and tuning and experimenting, we realized a lot of things were off. And as we improved them one variable at a time, we were able to jump to 65 74 82. Right? And here's the kicker. Our context chunks, which is the context size, went down from over 7,000 chunks to about a,000 chunks. So 17th the context size, a lot higher precision and a lot less money burned on tokens, right? So that's where Mako comes in. What is Mako? It's a agentnative persistence layer that takes all the mistakes we made and all the things we got right and puts it into one box. Right? And the way Mako works, it exposes a data pack, right? As a database company, we don't call it a database because it has multiple types of databases. Vector, graph, relational, no SQL, whatever, right? And what it does is stores aspects of the context, knowledge base, memory, conversations, observability, a lot more, right? And what it enables is it enables agents to come in and push pieces of their context into a private space and promote that to a shared space, right? And then other agents or humans that come in can now go against that promoted highquality context and quickly retrieve stuff and you can now continue to add more people and more agents and do the handoff efficiently. Right? Hopefully that makes sense. Um the idea is take the durable repeatable workflows and make it infrastructure. Okay, before we go into a demo, right, a confession. This slide deck that you're looking at was built using Makeo as the context persistence layer, right? The way it worked was Heather, who's going to give you show you the demo, actually wrote up an outline and created a data pack in Mako and simply sh sent sent me a share request, right? And she said, "I'm doing the demo. Here's the outline of my demo. Here's the rough talk track that needs to lead up to it because that's what makes sense." I took it and I'm I'm sure she used some agent harness. I don't know what it is. I really don't know. I didn't ask her. I didn't even have a meeting with her. She just sent me this. I plugged it into my cloud desktop and said, "Take this outline and break it down for me." And it gave me a few bullet points. This is what you're talking about. I'm like, "Okay, great. I want to change a couple of things." Changed a couple of things and said, "Here's the new outline. Can you build me my slide deck based on this?" And it did. And that diagram on the left, it built a really crappy diagram, right? It didn't look good at all. So, I said, like, you know what? Everyone's saying this uh cloud design is the rage, so why don't I give that thing a go? And it actually did a better job. So, you know, there you go. That image came from cloud design. Everything else came from cloud desktop. Shot it back to Heather and, you know, Heather took the final pass over it to get hook it up with the demo and here we are. So, we barely talked, right? We didn't need to. We just shared context and our agents did the work and uh you know, you can go you can watch it. I think maybe I'll invite Heather to talk to this slide and and the thing after. I hope the demo's good because I haven't seen it myself. So, yeah. The idea is to watch collective knowledge grow over time, right? What Nico provides uh that I was able to use for this is a resumability. So resumability I'm going to show you is being able to start a session and then kill it and then start it again with the same agent. Right now if you do it with something like cloud desktop, they have projects for this, right? Right? So if you do a cloud project, everything's together or if you turn on memory. But in this case, I guess like two months ago, I turned off all the memory on all of my idees because it doesn't matter what if I use something while I'm on the go, like a mobile app. Maybe I use chat EBT that isn't as sophisticated, right, as some of my coding idees. And so maybe I want to continue working on that topic. I can do that because all of the context is shared in our cloud now. And by sharing I mean that obviously chatbt is a different um agent but it's still my account so I should be able to get to it right but because we're security focused and security minded we don't want like just any agent to get to it so I have to promote the kind of memory that that agent can also retrieve in like a collective pool and because you do this the cost itself goes down tremendously because the first time I figure stuff out I'm going back and forth with my LLM I'm burning lots of tokens to get to an end goal, whether that is code or it's just a knowledge work. But the next time that I want to retrieve it from another agent or another session, it doesn't need to burn through that. It just calls to the Miko memory and then it brings it right back with far less token. So, we're already saving a lot of token spend. The alternative to this would be to just again keep things in empty files or keep things where you have to constantly traverse with every single agent's LLM and burn through tokens again and again in order to retrieve. Does that make sense? The difference here is just an MCP tool call. So to kind of prove that out because we have sensational internet here, I have recorded this for you at a little bit of a faster speed hopefully. All right. See this is resumability. So here I'm saying that I want to store um the conversation in a certain data pack, right? Let's call it the early access launch and I want to put a piece of information in it. In this case, um our signup emails failed. True story because we actually only used the SCS's sandbox instead of the prod. So uh we kind of went over the limit there when we were testing things. And that's a good piece of information for maybe our our ops team, right? So in this process, it's calling data pack create uh because I've connected the MCP server to clot here and I've created a skill that will tell it what to do. You can decide how often you want it to call or if you just want to do it judiciously here. And so now it's storing the incident fact as a searchable memory with memory add. And then it's done now. So the data pack has been created. there's a conversation in there and it'll be retrievable in the in the future sessions. That sounds great. Awesome. Now I've killed that session and notice I'm not in projects. This is just a new chat window. Now I'm going to ask the same question so I can resume. Before I had to again have to make sure I turn on cloud memory or turn or put it inside of a project, but it's not in either one of these. I could be logged in with the same account in like claw.ai, which would be technically a different agent. So I'm trying to prove that you can at least resume your sessions after maybe days with the same agent. So the fail result there was actually that it tried to search first instead of creating uh a conversation a new conversation here. We want to save everyone that we do. So it's the MCP server instructing to create a new conversation for it so we can store this. And see now they searched Mo and it found that hey this is what happened back in May and it was able to pull things back out. All right for sharability. Let's go ahead and get this done. If you notice this is a completely different IDE. In this case it's codeex. Um so I've asked it questions like okay um do you have any known cause for the signup emails that are failing? And so it's gonna look and it's gonna look and it says, "Nope, I don't see anything. I don't see anything. I'm looking." Um, it did say that it saw that there was a brand new uh data pack that it's connected to, but it can't actually see anything. And why is that? Because I actually haven't shared that private memory from my claw desktop yet uh into a shared space. So right now, those memories are still private. If you notice the early access data pack is seen because I have connected it but I just haven't promoted it yet. So in that case I'm going to go to sign out. I'm going to sign in with my other account here to show you that yes I do have access to this data pack and I need to promote that piece of memory into a shared knowledge space. Allow it to go ahead and and go through and then I it says it doesn't see it but I said well same question. Let's try it again. So, now that I've promoted it into that space, sped up for your pleasure here \[laughter\] because we all know how long-winded our LLMs can get. Um, now it can find that piece of memory. It can find the piece of memory because I've allowed that one piece to go. It's very fine grained. It doesn't have to be. You can open the whole data pack if you want as a maintainer to it, but this is much more ideal if you're just trying to give bespoke pieces of information, maybe best practices, maybe something that is the ongoing process that you want to keep going. And then like the last part of this is the cost. How do you even know that it saves you tokens? If you go into your data pack, you can look at the conversations that are stored in there and how they were done because we give you embedded language traces for free in this. And you can actually look at the decision trace all the way down to the tool call and prove whether or not it called as much and burned as many tokens. Right? So, human promotions today kind of equal the training signal for self-improving orchestration tomorrow. Every human that says this is worth keeping is kind of a labelled example of what good promotion looks like. So, you can actually start training maybe in the future an agent that's trained on your taste and your preferences long term. But right now, we're keeping the human in the loop. Those calls are just a signal, but this is actually how it starts to learn. The biggest lift that I saw is that when something goes wrong, maybe in a support situation, it's hard to constantly have calls call the same server that's down all the time and then it's tails all this time. Hey, do you know if this is down? Is that down? Slack starts blowing up. How do your agents handle that? They're all also wasting tokens calling the same thing. If they had access to the data pack, the first agent would hit it and then tell everybody that it happened and all the other agents would know that it already happened. Yeah. So, yeah. So, thank you, Heather. Like, I think you know, pretty awesome demo. I think uh if you folks were following along what happened, Heather was was in charge of the early access and launch of Mako, right? and obviously used a data pack which is Mako to launch Mak Makeo right recursively and uh you know the first few people had a lot of trouble accessing their data packs on Mako and you know we you know she created a data pack for troubleshooting issues with Mako a different data pack and so that's the thing that she was talking about uh a lot of us in the company you know it's shared with us so we're all able to look at it load it into our agents and able to iterate with it the folks that are in engineering they load it straight into their you know cloud cloud code or codeex or like you know whatever the coding agents are like I I myself more of a cloud desktop kind of user I use it for other things like you know some a user that wanted to get access couldn't get access apology email like go through cloud help me design it have a I have a data pack actually that is my voice of how I speak and same thing for posting on LinkedIn that thing can get tiresome if you want to keep writing it in your voice you know sometimes training a data pack for the context to do so will help so a lot of these things get automated straight away and it gets you know makes it much much quicker to assemble right and obviously if a new person comes into the team very easy to share this context with them have them get up to speed have them contribute to it either willingly or unwillingly right sometimes they're just doing things they don't even know and you extract patterns out of it oh this is really great we should make this a thing right so so like um yeah so I think these are some of the things anyways I think the bottom line is we're trying to get it closer and closer to how humans work which is how can you capture tribal knowledge how can you share that How can you give controls over sharing and how can you actually tell what's going on? Right. \>\> Yeah. \>\> Um Yeah. So \>\> you should you should try it for free. \>\> Yeah. \>\> If you want. \>\> Yeah. Try it for free. Yeah. I think the left side is you know the website makeata.ai which will take you to a login. There's a free tier. You can sign up and just hook it up to one of your agents and you know get your agents to start learning right right away. And the right side is Discord. We'd love to hear from you if you do try it out. You know do drop us a note. We're working on improvements. That's how we communicate what we're building. So do join us on Discord, right? We'd love to see you guys there. So I think that brings us Yeah. Thank you. Thanks. Yeah, if we have Yeah, we're right on time actually. Yeah. So yeah, thank you. If you guys have questions, please feel free to connect with us on the site. Thank you. \>\> \[music\]