A talk by Sally-Ann Delucia on context management for AI agents, based on a year of lessons building Alyx, an Arize agent that analyzes its own trace data. Covers the feedback loop where growing trace spans hit the context limit, why naive truncation breaks reasoning and why summarization proved unreliable, and the approach that worked: head/tail preservation with a retrievable memory store. Also addresses long-session evaluation, offloading tasks to sub-agents, and findings from examining the Claude Code source release. # Video Identity Observations — "How we solved Context Management in Agents — Sally-Ann Delucia" ## Explicit Self-Description by the Creator - **Speaker role and affiliation (stated):** The speaker introduces herself directly: > "I'm Sally Ann. I'm the head of product at Arize. I have a technical background. I started out in data science and now I build products for teams." - **Dual role claim:** She describes functioning as both PM and engineer: > "I'm a core contributor of Alex. I'm not only a PM, but I also function a little bit as a part-time AI engineer as well." - **Team and effort claim:** The talk presents a team-built product: "my team and I have been building for honestly close to a year now, which is our AI agent Alex." - **Company/mission framing (stated):** > "My job today really is to turn those pains into tools that may actually help AI engine[ering] AI teams." ## Claimed Scope of the Presentation - **Topics the speaker says she will cover:** context engineering problem, "a vicious loop that we got stuck in, how we escaped that loop," long conversations breaking agents, sub-agents, and ongoing work — "I'll tell you a little bit about what we're still working on cuz we certainly haven't figured everything out." - **Scope limits stated explicitly:** "I don't want to spend a lot of time on Alex. If you want to know more about what we built, come find me in the booth downstairs." ## Product Scope Claims (Arize / Alex) - **Alex described as an AI harness:** > "Basically what Alex is is an AI harness. It's here to help you build your AI applications. We have advanced planning, 40-plus skills built into it, core workflows across prompt engineering like prompt optimization, data gen, data augmentation, annotations, etc." - **Platform relationship:** "Alex is built on top of Arize, which is our observability platform." - **User base claim:** Takeaways are framed as coming "from our experience as well as our experience with all of our user base." ## Observable Intended Audience - **AI engineers and AI product teams** — indicated by: - "tools that may actually help AI engine[ering] AI teams" - "I know the pain of building these products firsthand and it is not easy to build a successful agent" - Q&A audience question referencing Claude Code's caching strategy, suggesting a technically sophisticated, practitioner crowd. - **Live conference/talk format** — evidenced by "Thanks so much for coming today," "come find me in the booth downstairs," applause, and Q&A with an in-room question. ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Candid engineering-narrative style:** Walks through failed approaches with specifics — naive truncation ("take the first 100 characters, and then we just dropped the rest... it worked until it didn't"), summarization ("too inconsistent"), then the current solution (head/tail truncation with a memory store). - **Openness about unsolved problems:** Includes an explicit "what we're still figuring out" section: huge contexts, long-term memory, heuristic context selection ("We don't really have a principled context budget or clear metrics for context quality yet"). - **Product framing of engineering topics:** She asserts a product/UX perspective: > "Context management is a product and a UX problem, not just an engineering one." - **Marketing/promotional element present:** Closing includes a QR code — "Want to try out Arize? ... You can try out Alex, our agent. We're downstairs at the booth if you'd like to see a demo." - **Takeaway-driven closing:** Three named takeaways: "context engineering really does matter. Memory matters and evaluation matters," plus the thesis line "agents don't fail because of prompts, they fail because of context." ## Claim vs. Demonstration Distinction - **Claims:** Product capabilities (40+ skills, advanced planning), team experience (~1 year building Alex), that strategies are "really really successful." - **Demonstrated:** Detailed technical lessons (truncation limits, summarization failures, sub-agent architecture, 10-turn/11th-turn eval method) that substantiate practitioner expertise, but product effectiveness itself is only asserted, not demonstrated in the material. # Delivery Observations — Sally-Ann Delucia, "How we solved Context Management in Agents" ## Tone & Overall Manner - **Conversational, first-person engineering narrative.** She frames the talk around her own team's experience rather than abstract theory: *"We built Alex using Alex"* and *"it is not easy to build a successful agent."* - **Enthusiastic but candid.** She repeatedly signals both excitement and limitation: *"I'm really excited because I get to talk about something that my team and I have been building for honestly close to a year now"* alongside *"we certainly haven't figured everything out."* ## Vocabulary & Register - **Plain, informal engineering vocabulary.** She self-describes approaches as naive: *"some very naive truncation"* and *"Pretty pretty naive."* - **Technical terms introduced in accessible language.** Key terms are defined rather than assumed: *"context engineering is really choosing strategically what the model sees."* - **Colloquial hedges and fillers.** Frequent *"you know," "kind of," "a little bit," "like"* — e.g., *"It's kind of this combination of truncation with a little bit... of of compression here."* ## Recurring Phrases & Patterns - **"A little bit" as a minimizer** — appears extremely often: *"talk a little bit about,"* *"I'm going to walk through each of these and and tell you a little bit."* This is a stable verbal tic, not an isolated moment. - **Immediate self-corrections / restarts.** Transcript shows repeated mid-sentence repairs: *"remember what it needs to um, and forget what it doesn't,"* *"context management isn't is a product and a UX problem,"* *"AI engine AI teams."* - **Emphasis through repetition.** Doubled words for stress: *"really really focused,"* *"really really successful,"* *"tool calls can be really really long."* ## Teaching Habits & Structure - **Signposted agenda up front.** She previews the arc explicitly: the problem, *"a vicious loop that we got stuck in, how we escaped that loop,"* sub-agents, and open problems. - **Problem → attempted solution → lesson learned pattern.** Each technical segment follows this rhythm — e.g., truncation *"worked until it didn't,"* summarization *"was too inconsistent,"* then the smart truncation memory that *"we actually use in Alex today."* - **Quotable takeaway formulas.** Distilled lessons stated as aphorisms: *"the best context strategy is one that lets your agents remember what it needs to... and forget what it doesn't"* and *"agents don't fail because of prompts, they fail because of context."* - **Rhetorical question framing.** *"So, who am I?"*, *"But what happens when they want to see patterns across all of their traces?"*, *"So how did we solve that?"* - **Audience-directed invitations.** Repeated calls to action: *"come find me in the booth downstairs,"* *"We're downstairs at the booth if you'd like to see a demo."* ## Audience Interaction - **Explicitly reserves Q&A time.** *"I wanted to leave some time for questions"* and *"I wanted to just leave some time to honestly be able to have you know, some Q&A."* - **Direct, unguarded answers in Q&A.** Admits current limits openly: *"we haven't gone too much into the cash... that's where I'm getting the most complaints."* ## Uncertainty Notes - Vocal delivery features (pace, pauses beyond marked *"um"*) can't be fully assessed from transcript alone; one audible moment is marked: *"[snorts and clears throat]."* Read-aloud emphasis like *"that was a game-changer"* is inferred from wording, not audible delivery — treat that specific observation as low confidence. # Position Record: "How we solved Context Management in Agents" — Sally-Ann Delucia ## Speaker - **Sally-Ann Delucia**, Head of Product at Arize; core contributor to the AI agent **Alex**; technical background in data science; describes herself as both PM and "part-time AI engineer." ## Framing & Central Claims - **Context engineering has overtaken prompt engineering** as the primary problem, citing a trend from "mid last year" and referencing an excerpt from **Andrej Karpathy** on "context engineering over prompt engineering." - > "The best context strategy is one that lets your agents remember what it needs to and forget what it doesn't." - **Context management is a product/UX problem, not just engineering**: if the agent lacks the right context, it gives bad answers, and bad answers mean users won't use the product. - **Context engineering ≠ fitting under the token limit**: it is "choosing strategically what the model sees." - **Takeaway claim**: "Agents don't fail because of prompts, they fail because of context." ## Problem Context - Alex is built on top of Arize's observability platform, so it must process traces/spans: inputs, prompts, metadata, and cross-trace pattern queries, which "multiply" the data volume. - Because Alex operates on agent data, **customers' growing contexts become Alex's context problem** (system prompts, user messages, conversation history). ## The "Vicious Loop" (Failed Approach) - Team built Alex using Alex. Cycle: spans grow → too much data → context limit hit → Alex fails → retry with more data → fail again. - Core problem: **the system analyzing the data was constrained by that same data**. ## Three Solutions Described ### 1. Naive truncation (failed) - Kept only the first 100 characters. "It worked until it didn't." - Result: agent forgot everything; follow-ups looked like new conversations; over-truncation "broke the reasoning." ### 2. Summarization (failed) - Sounded like the obvious solution but was **too inconsistent** — no control over what the LLM deemed important; unreliable. - Delucia stated she was **most surprised summarization didn't work**. ### 3. Smart truncation + memory (current approach) - Keep head (first ~100 chars) and tail (~100 chars); store the middle in memory. - Keep latest result for duplicate messages/tool calls; never reset the system prompt. - Agent can retrieve stored context on demand via IDs (including a preview and position in conversation, per the Q&A). - Stable for months; described as "really really successful." - Principle stated: **"Context decides what the model sees; memory decides what survives."** ### Long session evals - Users don't restart chats; conversations grew from <10 turns to 20+ turns, causing **late-appearing failures** discovered only via user reports or late data review. - Solution: load 10 turns, test the 11th — makes context-management bugs testable proactively. ### Sub-agents - Realization: **not all context belongs in the same agent**. - Main agent keeps chat history + light context only; delegates heavy data work (e.g., search over traces with hundreds of spans) to sub-agents; results return to the main conversation. - Called a "game-changer"; the pattern they "keep returning to" for large contexts. ## Unresolved Problems (Stated Explicitly) - **Huge contexts still break things**; very large prompts/inputs still hit provider limits; sub-agents remain the fallback pattern. - **Long-term memory is still missing** — memory is only the context + memory store; new chats lose prior issue references. Engineers actively working on it (her stated priority over caching, per Q&A). - **Context selection is still a heuristic** — no principled context budget or clear context-quality metrics; evals are the current proxy; researching something more sophisticated. - **Caching**: in Q&A she acknowledged they haven't invested much; current ID-based database retrieval "is working," but they will "have to get a little bit more sophisticated." - Noted (with mild disappointment) that the **Claude Code released code** uses a similar truncation/compression strategy — no secret revealed. ## Takeaways Asserted by Speaker - Context management is **iterative**; keep learning and optimizing. - Three things that matter: **context engineering, memory, evaluation** — "from our experience as well as our experience with all of our user base." ## Qualifications Preserved - Speaker repeatedly emphasizes the team has **not figured everything out** and is revisiting the strategy. - Success claims ("really successful," "working quite well") are explicitly bounded to date ("haven't had to touch this in a few months") rather than settled conclusions. # Speaker Attribution & Provenance Record ## Video - **Title:** How we solved Context Management in Agents — Sally-Ann Delucia - **Video ID:** `01a15ca9-7377-76aa-bd4f-49f9c3bc30cf` ## Speakers & Roles ### Primary Speaker — **Sally-Ann Delucia** (Creator / Presenter) - Self-identified in transcript: **Head of Product at Arize**, technical background in data science. - Describes herself as a **core contributor to "Alex"** (Arize's AI agent), acting as both PM and "part-time AI engineer." - Delivers the full talk; all main content is her first-person account of her team's work. ### Audience Questioner — **Unidentified audience member** - Role: **Guest / audience participant** (Q&A only). - Asks about Claude Code's approach to **cache invalidation in context management** and whether Arize does similar work. - Identity not established in transcript or metadata. ## Referenced Sources & Third-Party Claims - **Andrej Karpathy** — Speaker cites "an excerpt from Andre Karpathy" on context engineering over prompt engineering (spelled "Andre Karpathy" in transcript). - **Claude Code** — Speaker claims its released source code uses "a similar truncation and compression strategy" to Arize's; states this was "surprising" to her team. Audience questioner references Anthropic's work on cache invalidation (transcript renders as "invalidating the cash"). - **Claude / Cursor** — Cited as examples of users keeping everything in one chat. - **Arize's own product / Alex** — First-party claims about "smart truncation memory," sub-agents, long-session evals (10 turns loaded, 11th tested). ## Promotional Segments (Flagged) - **Opening product pitch:** Description of Alex (AI harness, "40-plus skills," planning, prompt optimization, data gen, annotations), invitation to visit booth for a demo. - **Closing promotion:** QR code to "try out Arise" and try Alex; repeated booth/demo invitation ("We're downstairs at the booth"). ## Provenance & Availability Notes - **Comment availability:** No metadata supplied; comment availability **unknown**. - **Curated metadata:** None supplied beyond transcript; speaker identity comes solely from the transcript's self-introduction. - **Uncertainty:** Speaker's name rendered as "Sally Ann" in transcript vs. "Sally-Ann" in title; audience member unnamed. \>\> All right, welcome. Thanks so much for coming today. I'm here to talk a little bit about context windows and I'm really excited because I get to talk about something that my team and I have been building for honestly close to a year now, which is our AI agent Alex. So I'm going to talk a little bit about some of the lessons we learned about context management and escaping the context window. So, who am I? I'm Sally Ann. I'm the head of product at Arize. I have a technical background. I started out in data science and now I build products for teams. I'm hands-on. I'm a core contributor of Alex. I'm not only a PM, but I also function a little bit as a part-time AI engineer as well. So I know the pain of building these products firsthand and it is not easy to build a successful agent. My job today really is to turn those pains into tools that may actually help AI engine AI teams. I'm going to talk a little bit about Alex. I don't want to spend a lot of time on Alex. If you want to know more about what we built, come find me in the booth downstairs. I'll give you a demo, but basically what Alex is is an AI harness. It's here to help you build your AI applications. We have advanced planning, 40-plus skills built into it, core workflows across prompt engineering like prompt optimization, data gen, data augmentation, annotations, etc. That's just a screenshot from our product, but yeah, come find me if you'd like a demo. For taste I'm going to talk a little bit about the problem of context engineering, context management, tell you a little bit about a vicious loop that we got stuck in, how we escaped that loop, and then how long conversations can break agents, a little bit about what we learned about sub agents, and then I'll tell you a little bit about what we're still working on cuz we certainly haven't figured everything out. So, the problem. I think like mid last year this term context engineering started to become more and more popular. This is an excerpt from Andre Karpathy about plus one in context engineering over prompt engineering. I think very early on everybody was really really focused on the prompts, but we started to realize that the context is what really made an agent fail or succeed. Um, and so the stack has really changed. We're no longer really focused just on the prompts, we're focused on the new engineering problem, which is context. So, my little perspective is the best context strategy is one that lets your agents remember what it needs to um, and forget what it doesn't. Oh, we got a little bit of a thing. And so we're going to talk a little bit about how you do that, but first let's talk about why context management even matters. So, I think a lot of folks think um, like context management is just like what fits in the window, but context engineering is really choosing strategically what the model sees. It's really important that you think about what the data is that is most important and not just think about, oh, I only have X amount of tokens, let's shove as much as I can in there and see how it does. So, it's not just saying under that token limit, it's being strategic about it. And that's why it really matters. All these different applications, a lot of times it's running on top of your context. And so, what you choose let the model see really matters. It can make or break the experience there. And so our reality with Alex is Alex is built on on top of a rise, which is our observability platform. So, we have to deal with all of the traces that come with AI agents. And so, we have one trace, we're getting, you know, the input from the user, there's prompts, there's all of this metadata, then the user is interacting with Alex. And so, it becomes really large. And that's just when we're talking about one trace. But what happens when they want to see patterns across all of their traces? Well, this just continues to multiply and multiply and multiply. Um, so being strategic about context was a non-negotiable for us. We really had to figure out, okay, what was most important for Alex to see? And how do we handle when it needs to kind of see everything? Um, and so this is the problem that we really aim to solve. And so, I as a product person like to say that context management isn't is a product and a UX problem, not just an engineering one. It's certainly one that the engineers are going to try to solve. There's going to be a lot of different strategies that people try, but ultimately comes back to the product and the UX, because if an agent doesn't have the right data, it doesn't have the right context, it's going to give bad answers. And if you give bad answers, nobody's going to want to use your product, right? And so that's why it really becomes a product problem and not just an engineering one. And this is the vicious loop that we got stuck in. So when we were building Alex, basically what we decided to do is like if we can build an agent that makes our lives easier in building our application, we'll know we'll have something that our users really want to use. And so we built Alex using Alex. And this is the vicious loop that we kept getting stuck in, where Alex would run on our our traces span data. The spans would grow, there would be too much data, we'd hit a context limit, Alex would fail. And the span has that data, so it would try again, we'd add more data to it, it would run, and then it would fail. So we kept getting stuck in this loop where our context was growing and growing. We couldn't get Alex to actually perform on it. And so we knew that we needed to come up with some kind of strategy. So the system analyzing the data was constrained by the data, and that was a major problem for us. Alex was never going to be able to succeed unless it could understand and taken all of this data. So how did we solve that? Well, it's kind of a three-part thing, three things that we really learned here to escape this loop. So how to actually control context, separating the context from memory. I think there is something that's really important about building them together, but they are kind of separate. And then moving heavy work out of one agent into another, that was another lesson we learned. So I'm going to walk through each of these and and tell you a little bit about how we approached them. So I think the the very first thing that came to mind was some very naive truncation, where it's like, "Okay, we have this long long context blob. Can we just take the beginning of it? Is just the beginning important? Is that enough information to give Alex for her to actually perform the analysis that's needed?" So we started off just taking the first 100 characters, and then we just dropped the rest. Pretty pretty naive. And it worked until it didn't. So in the beginning it seemed like for really simple things that this would work out, but the agent ultimately just forgot everything. Follow-ups looked like new conversations. If I asked one question, Alex would respond, and then I said, you know, ask a follow-up like, you know, what are the most common inputs? Okay, these are the most common inputs. Okay, can you tell me a little bit more about input B? It didn't understand what I was talking about. So, we learned pretty quickly that this was not going to be successful, so we needed to start considering some other options. Um, so the the main takeaway from this was that over truncation had broke the reasoning. It couldn't remember. We then thought, okay, well, summarization, we have all these LLMs, they're pretty good at summarizing. Can we just summarize all the context into a shorter um amount of tokens so that we can send that to the LLM and have um a better result. And that really sounded like the obvious solution, but it was too inconsistent. There was no control over what was important, you know, we're just leaving it to the LLM to look at the data, decide what to do with it. Um, and that was pretty unreliable. So, we learned pretty quickly that summarization was not going to work either. This was the second thing we we tried. Um, and so next solution was the smart truncation memory. This is what we actually use in Alex today. Um, it is kind of this combination of truncation with a little bit, I guess, of of compression here and storing in memory. Um, so we take the beginning still 100 characters. We also take 100 off of the tail. Um, and then we we take out the middle and we basically store that. So, the agent still has access to this. So, if there's any duplicate messages, um, tool calls can be really really long and Alex is making a lot of lot of tool calls. Um, and so we're keeping the latest result. We don't reset the system prompt and we truncate the middle, uh, keep the head and the tail, and then at any point of Alex feels like there's a tool call that was important or a message from the the previous conversation that's important, it can always go back and grab that context. And so it gives Alex a little bit more control, uh, over what context is actually important. Um, and we found this to be really really successful. Um, we haven't had to to touch this in in a few months. We are getting to the point, I'll talk about a little bit later, that we are revisiting our strategy, uh, but we've we found that this combination of truncation and memory has been really really uh successful. So, \[snorts and clears throat\] context aside with the model sees memory decides what survives and so this is kind of a system we built with the um smart truncation there. Um and again, this is working quite well for us. But we had another problem as we were kind of deciding how to to handle context management, which is long sessions and I think that this is something that a lot of people run into, which is users don't usually restart their chats. Um you know, I I think there are different approaches to this. Some people I know like if you're using Claude or Cursor, you know, you pull everything in one chat. Some people like to have other ones, but we really learned with Alex everybody kind of wants to stay in one chat as they're traveling to pages to pages. So, our conversations grow and our failures appear late. So, uh when we first did this smart truncation, it seemed like it was working, um but then as we saw these longer and longer conversations, there were failures happening and we didn't know about them too late until like a user reported it or I was looking at the data and I realized that Alex kind of started to forget things way late into the conversation. And so, the solution that we came up here is long session evals and I want to include this because, you know, it's maybe not um related exactly to how you handle context management, but it's a really helpful signal in understanding how your context management is doing. Uh because I think long sessions are something that naturally happen with these applications. Um and so, what we end up doing is we load 10 turns and then we test the 11th to understand how the context is doing. And so, these bugs really become testable. I don't have to wait till I find it or a user reports it. So, uh wanted to share a little bit um about that and even so, with the testability and um the uh truncation here, um there is still, you know, too much data sometimes for for one agent. So, uh one big realization that we also had is that not all context belongs in the same agent. Um so, I'm going to give an example here, our search task. So, this is where Alex is trying to search over data in Arise. Um this happens within like our main chase or even when we're just looking at, you know, one trace stack, you know, there can be hundreds of spans within it and Alex needs to figure out what data it should look at. So, there's multiple queries happening, tons of data, lots of intermediate reasoning happening step-to-step. And we really came to the conclusion that not all this needs to live in the main conversation. So, once we had one kind of main agent uh for our traces uh skills and we decided that that was not really necessary. So, the solution that we had was sub-agents. And I think this is also something really important when you're talking about context and how we manage across uh these agents that need to have a lot of data, uh which is offload the heavy tasks. The main conversation can stay small. Um so, before we had the main conversation, we had chat history, heavy data, search all in one context. This was all handled in one agent. And then after basically what we have is these this main agent plus a sub-agent. So, we have the main conversation with the chat and light context only. We keep it pretty light. What it can do is it can delegate to the sub-agents. Um and that's where the heavy data stays. So, we can keep all of the heavy data context in our sub-agent. And then once it gets a result, we can kind of pass that over to the main uh main agent again and then the user can kind of share um or keep the conversation going. And of course, it can always retrieve from the memory store as well if it ever feels like it needs more context there. So, I think this is something that was a game-changer. We've uh rolled out a lot of sub-agents now that we kind of figured out this is the right way to handle all the really, you know, data-intensive operations. So, that's a lot of what we figured out in terms of context management. It's working really well. I I think I was surprised the most by the fact that summarization didn't work. I think that was again like the obvious choice for us, but uh the combination of truncation along with being able to store it in memory uh is something that we found to be really successful. So, what are we still figuring out cuz there's quite a lot. Uh huge context still can still break things. I think it's still a problem for us. Very large prompts or inputs still hit provider limits. So, because we're operating we have an agent operating on agent data, you can imagine all of system prompts, the user message, the conversation history. That is all what our customers are trying to use Alex to understand. And so, as their context is growing, we have a bigger context issue because we have to figure out how um to to handle that. And the pattern we keep returning to is sub agents. Uh we just keep breaking things up and having context handled by different parts. Um and that is something that we are still um kind of learning about and and seeing if there's anything that we need to do to evolve that strategy even more. Long memory is still hard. This is something actually that my engineers are working on right now. So, long sessions are tricky. We are seeing conversations grow more and more. I think when we started, I was seeing like less than 10 turns per conversation with Alex, and now I'm seeing folks really go, you know, push the limits up to like 20 plus. Uh what's really happening there is they're traveling across our application using Alex. And so, as they're trying to do these longer workflows, they're obviously asking more questions and they're finding Alex to be helpful, but that's a a problem for us because we need to figure out how um to handle this. So, I think what we're really focused on right now is like real long-term memory. It's not something that Alex has. The memory is really just that um kind of context with the memory store uh that Alex can leverage. So, we don't really have long-term memory. Um I also think it's important because people want to reference issues that they've previously discussed with Alex. And so, if they're they do decide to start a new chat, Alex really doesn't have context for that. So, uh we're in the process of adding long-term memory, and I think that's something that'll be a real game-changer for us. Context selection is also still a heuristic for us. Deciding what context stays in um is just that basic, like I said, like first 100, last 100. Um but, we do keep like asking ourselves, do we keep the right things? Uh we don't really have a principled context budget or clear metrics for context quality yet. We use our e-vals a lot of the time to measure whether our context was right or not. Um but, I think there's something a little bit more sophisticated that we're researching to figure out if this is the right heuristic. Um something that was a little little surprising to us is, you know, I don't know how many people are right here, but the quad code code was kind of released for all of us to read a little bit about. We were surprised that they're using kind of a similar truncation and compression strategy as we are. We were kind of hoping to get a little bit of a a secret from from them, but I guess we'll all just have to keep you know, doing our own research there. Um and just some takeaways cuz I wanted to leave some time for questions. Um context management is iterative. We are still learning. I think everybody should continue to learn and lean in and try to optimize their context management. The few things that I think are really clear is that context engineering really does matter. Memory matters and evaluation matters. If you're going to take anything away from me or us at a rise, it's those three things and that's from our experience as well as our experience with all of our user base. And finally, agents don't fail because of prompts, they fail because of context. I think that's something that we've learned firsthand and that we're seeing more and more. In the early days, prompts were everything. Everybody was focused on prompt engineering, but ourselves and all of our users are really focused now on context engineering and there's a lot of strategies that can go into that. You want to try out a rise? Just want to give it a QR code to try it out. You can try out Alex, our agent. We're downstairs at the booth if you'd like to see a demo especially of Alex, I'd be happy to give it, but I wanted to just leave some time to honestly be able to have you know, some Q&A and answer some questions. \>\> \[applause\] \>\> Yeah, question. What was the main thing that they came out with? Hi, thank you. It was a great talk. One of the things that came out with the Claude Code Lee was how much effort they've put into not invalidating the cash with their context management. Are you doing work on that as well or how are you thinking about that? Yeah, I think right now we're really trying to focus on the long-term memory stuff. We haven't gone too much into the cash. Basically, we have it saved off in a database with IDs. And so, what Alex can do is it has a tool where it has all the IDs and like where in the conversation it needs to access. So, was it earlier on? How many messages? And it gets a little bit of a preview. Um so, that's how we've done it right now. I absolutely think we're going to have to get a little bit more sophisticated and invest in that. Uh but right now it's working. So, we're kind of focused more on the long term memory cuz I feel like that's where I'm getting the most complaints. Yeah. Any other questions? All right. Well, come find me downstairs if you have any questions. Thanks so much for the the time. \>\> \[applause\]