AI Engineer World's Fair 2026
Agent Memory Is Solved. Agent Learning Isn't. — Karthik Ranganathan, Yugabyte
Read the talk
Agent Memory Is Solved. Agent Learning Isn't.
Karthik Ranganathan and Heather Downing explain why agent handoffs lose hard-won context, how Yugabyte rebuilt its retrieval pipeline, and how Meko carries selected lessons across sessions and agents without making every private memory shared.
From a talk by Karthik Ranganathan and Heather Downing
At a glance
Ideas worth remembering
An output-only handoff loses rejected approaches and decision context, causing the next agent to repeat discovery and spend tokens again.
Reusable shared context needs supervised promotion and traceable sources, because making information accessible does not make it reliable.
The slide reports Markdown faithfulness improving from 14% to 65%, PDF faithfulness from 20% to 74%, and context precision from 5% to 82%, alongside a reduction from over 7,000 context chunks to about 1,000.
The email-incident demo distinguishes session resumption from sharing: Claude retrieves a saved private memory, while Codex finds it only after promotion into shared knowledge.
Human promotion supplies examples of what a team values. Using those examples to train future orchestration is a proposal; human selection remains part of the demonstrated system.
A remembered conversation does not teach the next agent
An agent finishes a task and hands over a Markdown file, a PDF or another document. The next agent receives the result, but loses the reasoning that produced it: which alternatives failed, what constraints mattered and why the team settled on this approach. It must discover those things again, spending tokens to repeat work someone already did. This handoff problem drives Karthik Ranganathan’s distinction between individual memory and collective learning.
Yugabyte encountered the problem while building four agents: two for internal customer support and sales–marketing coordination, and two for customers. PerfAdvisor handled database administration; Voyager helped migrate and modernize databases. Nearly a year of trying to make these agents work exposed a data problem that more scalable vector, graph or relational storage did not resolve. For a database company, Ranganathan says, “it becomes personal.”
The human analogy is a new teammate proposing alternatives the team considered weeks or months ago. A useful onboarding conversation includes the project’s history, rejected approaches and current working assumptions. Agents need a comparable handoff. Saving a conversation for one agent supplies memory; making its useful lessons available to another agent requires additional infrastructure for sharing, selection and retrieval.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Shared context needs selection and a source
Ranganathan challenges five common responses to the handoff problem. His objections concern preserving and reusing lessons across agents; they should be read within that scope rather than as universal claims about the usefulness of these techniques.
- More memory: storing more material does not decide which lessons another agent should use.
- Shared state: access to the same file does not automatically supply the reasoning behind it.
- Retrieving every transcript: a larger searchable pile can introduce irrelevant material and make the model spend more tokens interpreting it.
- Fine-tuning: he rejects repeated custom training as a scalable way to persist agents’ newly discovered lessons.
- Bigger context windows: adding capacity leaves the quality and deterioration of the context unresolved.
The proposed replacement has three requirements. Agents must be able to work from shared context. Contributions must pass through supervised promotion because shared context can degrade. And each piece of information must be traceable to a source—a person, conversation or data source—so someone can investigate a questionable claim and improve it. The comparison to code review is useful: producing a contribution and accepting it into the team’s working knowledge are separate decisions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A scalable RAG pipeline still needed diagnosis
The first implementation treated the problem as a knowledge base: put everything into a distributed, elastic retrieval-augmented generation pipeline. It scaled, but did not produce useful results. The next attempt gave each agent a tiny Postgres database. That moved storage closer to the individual agent while leaving repeatable workflows to be reinvented on every run. A subsequent backend-heavy design omitted the UI because agents supposedly did not need one; humans then could not tell what was happening.
The displayed slide separates three reported results: Markdown faithfulness rose from 14% to 65%, PDF faithfulness from 20% to 74%, and context precision from 5% to 82%. Faithfulness concerns whether an answer stays grounded in its retrieved material; context precision concerns how much of that material is relevant. The 82% endpoint therefore describes retrieval precision, rather than faithfulness. The spoken transcript renders the precision baseline as 57%, differing from the slide; the displayed metric labels and paired endpoints clarify the comparison.
Tracing and changing one variable at a time improved those separate grounding and retrieval measures. Meanwhile, the context fell from over 7,000 chunks to about 1,000—roughly one-seventh as much material. The recording does not identify the benchmark, changed variables or full evaluation conditions, so this is an account of Yugabyte’s pipeline improvement rather than a reproducible recipe or general performance guarantee.
The consequential decision was to inspect retrieval behavior rather than keep adding capacity. Less context accompanied better grounding and higher precision. That reduces the material an LLM must process and gives the team a reason to expect lower token spending, while preserving the more useful evidence. The lesson is specific: scalability did not substitute for tracing and tuning what the pipeline actually returned.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Data packs make private work available for deliberate reuse
Meko packages these lessons into an agent-native persistence layer. Its organizing unit is a data pack, which can hold a knowledge base, memories, conversations and observability information over multiple storage types, including vector, graph, relational and NoSQL databases. An agent writes context into a private space; selected pieces move into a shared space through promotion. Other agents and humans retrieve that promoted context to continue the work.
The talk’s own deck provides a collaboration example. Heather Downing wrote a demo outline, created a Meko data pack and sent Ranganathan a share request. He brought the outline into Claude Desktop, asked it to break down the talk, edited the outline and generated a deck. A poor diagram prompted a separate design pass. Downing then reviewed the finished material to connect it with her demo.
The shared outline supplied enough context for the collaborators to work with different tools without first agreeing on an agent harness or holding a meeting. Human judgment still changed the outline, rejected the initial diagram and checked the final handoff. The reusable part was the project context; the people remained responsible for deciding what the presentation should become.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resume an email incident in a fresh session
Downing’s demonstration separates two capabilities: resuming work in a new session and sharing knowledge with a different agent. Application-specific memory or projects can support continuity inside one tool, but she wants context she can carry between desktop, coding and mobile workflows. Cloud persistence makes that possible; permission to retrieve a memory still has to be controlled.
The concrete lesson is an early-access launch incident. Sign-up emails failed because the team used an email-service sandbox rather than production and exceeded its limit during testing. In Claude Desktop, Downing asks to save the conversation in an early-access launch data pack. A connected Model Context Protocol (MCP) server exposes the operations, and a skill guides the agent’s use of them. The agent creates the data pack and adds the incident fact as searchable memory.
She then ends the session and opens a fresh chat outside a Claude project, without relying on Claude’s built-in memory. Asking about the incident retrieves the saved explanation from Meko. There is a small orchestration stumble: the agent tries to search before creating a new conversation record. The MCP server instructs it to create that record so the resumed interaction can also be stored, and the search finds the earlier incident.
This changes the next session’s starting point. The original investigation involved a back-and-forth with an LLM; the new session can retrieve its result through a tool call instead of repeating that investigation. The memory must first be captured, however, and the skill determines how frequently the agent writes it. Persistence and the instructions for using persistence both participate in resumability.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A connected agent cannot read an unpromoted memory
The same email incident next becomes a sharing test. Downing asks Codex whether it knows a cause for failing sign-up emails. Codex can see that it is connected to a new data pack, but cannot find the explanation. The incident memory remains private in the Claude Desktop workflow. Connecting a data pack has not exposed all of its contents.
Downing switches accounts to access the data pack and promotes the incident memory into shared knowledge. The first response still does not find it; after she repeats the question, the agent retrieves the fact. The observable change is from an unavailable explanation to a retrievable one after promotion. It is the same incident and question, with the memory’s sharing state changed.
What changes between saving a lesson and making it useful to another agent? The flow below follows the email incident through private storage, session resumption and supervised sharing. Its two retrieval paths show why resumability and shareability need separate treatment: the originating workflow can recover its private memory, while another agent receives the selected lesson only after promotion.
Promotion can be fine-grained. A maintainer can open the whole data pack, but Downing demonstrates releasing one useful piece of information. This supports sharing a best practice or an ongoing process without exposing every memory gathered while working on it. The cost of that control is a human selection step; the benefit is a smaller, intentional body of shared knowledge.
Sign-up emails failed after sandbox limits were exceeded.
Saving supports a fresh session. Promotion makes the selected incident available to another agent.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspect the savings; keep promotion human for now
The way to inspect token savings is to follow the stored conversation down to its tool calls. Meko includes embedded Langfuse traces, which Downing describes as exposing the decision trace and token usage. That lets a team compare repeated investigation with retrieval of a saved lesson. The demo gives a mechanism for reducing repeated work and a means of inspecting it, but does not present a quantified before-and-after token comparison.
Human promotion also creates a possible future training signal. Each decision that a memory is worth keeping becomes a labeled example of useful shared knowledge. Downing proposes using those examples to train an agent around a team’s preferences and improve orchestration over time. That remains a future direction in this recording; the demonstrated system keeps a human in the loop. Its present learning mechanism is the accumulation and reuse of selected context, rather than a demonstrated automatic training loop.
An outage illustrates why collective context could matter operationally. Without shared knowledge, several agents may repeatedly call the same unavailable server while people ask the same questions in Slack. Downing proposes having the first agent record the failure so the others can retrieve it. The shared observation would let subsequent agents start from a known incident rather than independently rediscover it; the recording does not develop how that observation would expire or be updated when the service recovers.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn launch experience into team knowledge
The team uses Meko to launch Meko. Beyond the early-access launch work, Downing created a separate troubleshooting data pack after some initial users had trouble accessing their packs. Colleagues load that shared context into their preferred agents: engineers use coding tools such as Claude Code or Codex, while Ranganathan works mainly in Claude Desktop. The same operational knowledge supports different kinds of work without requiring everyone to use the same client.
The closing examples extend beyond debugging.
- Customer communication: Ranganathan uses a data pack containing context about his writing voice to help draft an apology email for a user who could not get access, and to prepare LinkedIn posts.
- Onboarding: a new teammate can receive project context, get up to speed and contribute further lessons.
- Capturing working patterns: useful practices can emerge from ordinary work and then be selected for reuse, even when the person doing the work did not set out to write a formal best practice.
These uses bring the discussion back to tribal knowledge: capture what a team learns, control who can share it, and keep enough visibility to understand what agents are doing with it. Ranganathan closes by inviting people to connect an agent to Meko’s free tier. The practical starting point demonstrated here is modest and concrete: save one useful lesson, recover it in a fresh session, then deliberately make it available to another agent.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- Beating RL With Reflection: GEPA and Optimize Anything
Explores the next step beyond preserving lessons: using execution traces and feedback to improve prompts, agent programs and repository skills.
Read the complete timestamped transcript
- 0:13
Good to meet you folks. Thanks for everyone who's here. Um, today we're gonna 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 gonna talk about not just like, you know, w-what we're building, et cetera, 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
- 0:43
it, conversations, et cetera, 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
- 1:12
same infrastructure that is needed in order to learn, right? We're gonna talk a little bit more about that. Okay. So by way of background, I'm Karthik, one of the co-founders and the CEO of a database company, YugabyteDB, right? So what the hell are we doing here? Why are we building a agentic 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
- 1:42
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 PerfAdvisor, 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 cloud-native 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
- 2:12
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 is 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 of physics." So
- 2:42
what is the real failure, right? When you cut everything a-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 other-- Who's gonna 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
- 3:12
lose? This loses reasoning. This loses the dead ends, 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 fifty reasons why we should do something else,
- 3:42
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
- 4:12
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 surest way to
- 4:42
quickest failure in an expensive manner, right? 'Cause 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? 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.
- 5:12
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 tr-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.
- 5:42
So
- 5:45
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, it's gonna 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 Postgres, make it efficient." Well, we realized that every
- 6:15
repeatable workflow was being reinvented on the fly. Didn't work at all. And then we said, "Okay, fine. We'll just have some back end that does a whole bunch of processing and, you know, we'll just, you know, not even bother with a UI 'cause 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 'cause, you know, we took all the best components from the, you know, whatever the academia,
- 6:45
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
- 7:15
context chunks, which is the context size, went down from over 7,000 chunks to about 1,000 chunks. So one-seventh the context size, a lot higher precision, and a lot less money burned on tokens, right? So that's where Meko comes in. What is Meko? It's a agent-native 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 Meko works, it exposes a
- 7:45
data pack, right? As a database company, we don't call it a database 'cause it has multiple types of databases: vector, graph, relational, NoSQL, 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
- 8:15
other agents or humans that come in can now go against that promoted high-quality 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
- 8:45
using Meko as the context persistence layer, right? The way it worked was Heather, who's gonna give you, show you the demo, actually wrote up an outline and created a data pack in Meko and simply sh- 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 'cause 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
- 9:15
this. I plugged it into my Claude 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 wanna 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, Claude 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
- 9:45
go. That image came from Claude Design. Everything else came from Claude 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 'cause I haven't seen it myself, so yeah.
- 10:20
The idea is to watch collective knowledge grow over time, right? What Meko provides, uh, that I was able to use for this is the 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 Claude Desktop, they have projects for this, right? So if you do a Claude 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
- 10:50
IDEs because it doesn't matter. What if I use something while I'm on the go, like a mobile app? Maybe I use ChatGPT that isn't as sophisticated, right, as some of my coding IDEs. And so maybe I wanna 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 ChatGPT 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
- 11:20
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. 'Cause 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 Meko
- 11:50
memory, and then it brings it right back with far less tokens. 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
- 12:20
little bit of a faster speed, hopefully. All right, see this is resumability. So here I'm saying that I wanna store, um, the conversation in a certain data pack, right? Uh, let's call it the early access launch, and I wanna put a piece of information in it. In this case, um, our sign-up emails failed, true story, because we actually only use 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
- 12:50
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 Claude 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 wanna 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,
- 13:20
and it'll be retrievable in the f- 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 Claude 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 claude.ai, which would be technically a different agent. So I'm trying to prove that you can at least resume your
- 13:50
sessions after maybe days with the same agent. So the failure result there was actually that it tried to search first instead of creating, uh, a conversation, a new conversation here. We wanna save every one that we do, so it's the MCP server instructing to create like a new conversation for it so we can store this. And see now they searched Meko and it found that, hey, this is what happened back in May, and it was able to pull things back out.
- 14:22
All right. For shareability, let's go ahead and get this done. If you notice, this is a completely different IDE. In this case, it's Codex. Um, so I've asked it questions like, "Okay, um, do you have any known cause for the sign-up emails that are failing?" And so it's gonna look, and it's gonna look, and it says, "No, 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,
- 14:52
but it can't actually see anything. And why is that? Because I actually haven't shared that private memory from my Claude 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 gonna go to sign out, and I'm gonna sign in with my other account here to show you that, yes, I do have access to this data pack, and I need to
- 15:22
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."
- 15:38
So now that I've promoted it into that space, sped up for your pleasure here, 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 have 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
- 16:07
is the ongoing process that you want to keep going.
- 16:14
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 Langfuse 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.
- 16:43
Right.
- 16:49
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 labeled 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
- 17:19
support situation, it's hard to constantly have calls call the same server that's down all the time, and then it's... tells 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.
- 17:50
Hmm?
- 17:52
Hmm?
- 17:52
Yeah, so-
- 17:54
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 Meko, right? And obviously used a data pack, which is Meko, to launch Meko, right? Recursively. And, uh, you know, the first few people had a lot of trouble accessing their data packs on Meko and, you know, we-- you know, she created a data pack for troubleshooting issues with Meko, a different data pack, and so that's the thing that she was talking about.
- 18:25
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, in, in engineering, they load it straight into their, you know, Claude Code or Codex or, like, you know, whatever the coding agents are. Like, I, I myself am more of a Claude Desktop kinda 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 to Claude, help me design it, have a da- I have a data pack actually that is my voice of
- 18:54
how I speak, and same thing for posting on LinkedIn. I think it can get tiresome if you wanna 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 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,
- 19:25
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?
- 19:40
Yep.
- 19:40
Um, yeah. So I think-
- 19:41
You should, you should try it for free.
- 19:43
Yeah.
- 19:43
If you want.
- 19:44
Yeah. Try it for free. Yeah. I think the left side is, you know, uh, the website, mekodata.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...
- 20:14
Yeah. Thank you. If you guys have questions, please feel free to connect with us on the site. Thank you.