Kevin Madura (AlixPartners) explains recursive language models (RLMs), which treat context as an object in a REPL that the model can slice, compute over, and iterate on, and which can recursively delegate to sub-models, including themselves. He contrasts RLMs with RAG, agents, and tool calls, discusses benchmarks (a long chain-of-thought benchmark improving from 2.6% to 45.4% accuracy), and walks through use cases including cohort retention analysis, consolidating long invoices without chunking, log pattern analysis, agent harness optimization, and a security report across 500,000 lines of code. He closes with a prediction about models post-trained to be RLM-aware. # Video Identity Observations: RLM Talk by Kevin Madura (AlixPartners) ## Explicit Self-Description Evidence - **Speaker affiliation (creator-claimed):** Kevin Madura states directly: *"My name is Kevin Madura. I'm from a company called AlixPartners... We're a consulting firm."* This establishes his professional identity but is a personal claim, not necessarily a channel claim. - **No explicit channel self-description** appears in the transcript — no mission statement, channel name, or audience pitch is stated. - **Title framing:** The title *"It's Tokens All The Way Down: How RLMs are Different — Kevin Madura, AlixPartners"* presents the format as a **named speaker talk with employer attribution**, consistent with a conference/meetup recording rather than a personal vlog. ## Observable Audience Signals - **Live, technically expert audience:** The speaker opens with an audience poll: *"show of hands, who here is familiar with RLMs?"* and concludes *"not many"* — indicating he calibrates depth to the room. - **In-group references:** Mentions of *"all the DSPy fans in the room,"* *"if you were at... Code in November in New York City,"* and *"our friend Raymond here"* show an audience embedded in the **AI engineering conference community** with shared prior exposure to DSPy, agents, and tool-calling. - **Practitioner orientation:** References to *"production workloads,"* cost/latency tradeoffs, and *"battle scars"* from invoice processing target **working AI/ML engineers**, not general learners. ## Claimed Scope of Content - **Topic scope:** A technical explainer and advocacy talk on **Recursive Language Models (RLMs)** — what they are, benchmarks, when to use vs. skip them, and case studies (Predict RLM, Halo, OWASP security scanning). - **Positioning:** The speaker explicitly identifies his lineage: *"I'm very DSPy-pilled... basically a student of Omar and the rest of the group there"* — signaling intellectual alignment with the DSPy research community (Omar, Alex). - **Opinion transparency:** He distinguishes fact from opinion, e.g., *"in my opinion... largely bitter lesson pilled"* and *"I didn't look into this too deeply, there's probably some unfair math going on here"* — demonstrating hedged, evidence-conscious presentation. ## Presented Evidence Style - **Benchmark-driven argumentation:** Cites uLong and BrowseComp benchmarks with performance claims (e.g., *"from 2.6 to 45.4% accuracy"*), attributing them to others' work rather than claiming them as his own. - **Demonstrations over assertions:** Includes live code walkthroughs (cohort retention analysis on data frames) and traces, framing results as illustrative examples. - **Named-source citations:** References an Anthropic workflows release, a CIS conference mention, a Sam Hogan tweet, and an AWS engineer example — grounding claims in named external sources. ## Channel-Presentation Synthesis Notes - **What this demonstrates:** The channel (or event account) hosts **expert practitioner talks on frontier AI engineering topics**, with speakers from industry consulting firms. - **What cannot be concluded:** No channel-wide posting pattern, upload cadence, or audience scale is observable from a single video; no private motivations are stated or inferable. # Delivery Observations: Kevin Madura — "It's Tokens All The Way Down: How RLMs are Different" ## Overall Tone & Register - **Conversational, casual conference talk style**: filled with hedging, interjections, and informal connectors. - Opens with filler: > "Yep. Awesome. Thanks everyone for being here." - Frequent discourse fillers: "Um," "you know," "or whatever it is," "that sort of thing," "and things like that." - **Self-deprecating and hedging** when presenting his own examples: > "these are kind of they're somewhat unfair, I suppose, to to the base model" > "I didn't look into this too deeply. There's probably some unfair math going on here" ## Audience-Interactive Habits - **Crowd calibration at the start**: > "Just curious, show of hands, who here is familiar with RLMs? So we know how much time to spend on it." - **Direct audience addressing** and asides: > "for all the DSPI fans in the room" > "if you were at um I think it was code in November in uh in New York City" > "our friend Raymond here did some great performance testing" ## Structural / Signposting Language - **Numbered enumeration of key points**: > "that's key difference number one. Key difference number two is..." - **Explicit time management commentary** (recurring): > "I'll skip through this a bit just because I have about 10 minutes left" > "I only have five minutes left, so we won't go through this whole example" > "I know I I rushed through everything a little bit" This appears at least four times — a stable pattern. ## Recurring Phrases & Vocabulary - **"Bitter lesson pilled" / bitter lesson framing** — repeated ideological touchstone: > "it's largely bitter lesson pilled in my opinion" > "Again, being bitter or less impilled, this will get better over time." - **"Deferring to the model"** as a recurring conceptual verb: > "you should be able to defer more and more to the model" > "you're kind of deferring to the model about how to decompose the process" - **Repeated dismissive vocabulary for alternatives**: "bloat," "bloating": > "it was totally bloated in terms of the way that cloud code tried to um tried to solve these tasks" > "you don't have this additional bloat of the tool calls back and forth" - **"Churn through"** repeated for RLM processing: > "let the RLM just churn through all of that" > "the RLM being able to churn through all this information" - **"Context engineering"** as a recurring villain/contrast term (appears multiple times near the end). ## Teaching Habits - **Explains by contrast**: repeatedly defines RLMs against RAG, agents, tool calling, and coding agents: > "rag of course you kind of just stuff the context window... Agents are largely just bringing strings back" - **Uses concrete, vivid worked examples**: tax code loopholes, invoices, summing numbers across 30,000 tokens, vulnerable OWASP app, regex/data frames. - **Analogies to familiar tools**: > "It's actually interacting directly with the dataf frame as if it was typing in its own Jupyter notebook." - **Personal-experience anecdotes** to establish credibility: > "I have a lot of battle scars to to prove it." - **Explicitly flags uncertainty** about facts: > "I don't know if this is the actual kind of starting point for RLMs" > "I think it was Tar or someone similar" ## Verbal Disfluencies (Stable Pattern) - **Heavy word/syllable repetition under speed**: > "it it it has demonstrabably better performance" > "the the the context windows" > "tool calls are tool calls calls are done" - Indicates rapid, largely unscripted or lightly-scripted delivery. ## Closing Habit - **Ends with a forward-looking speculative hook**: > "The biggest promise I see here is just imagine a world where the models are actually post-trained and actually like RLM aware. I think things will get pretty crazy pretty quick." ## Uncertainty Notes - Timestamps in the transcript are unreliable (appear as bracketed segment markers, not real timecodes), so delivery timing beyond the speaker's own "10 minutes / 5 minutes" comments cannot be verified. - Audience laughter/reaction is not captured, so interactive moments beyond quoted words are unobservable. # Observation Document: "It's Tokens All The Way Down: How RLMs are Different" — Kevin Madura, AlixPartners ## Speaker - **Kevin Madura**, AlixPartners (consulting firm), sole presenter in this transcript. ## What an RLM Is (Speaker's Definition) - RLM = **recursive language model**; treats context as an object it can interact with **symbolically in its environment** (typically a Python REPL). - Differs from a tool call: tool calls pass strings/JSON interpreted elsewhere; an RLM interacts with a **symbolic environment** directly. - Second key difference: ability to **delegate to another LM** (often itself; same or different model can be specified), enabling **recursive problem decomposition** — the LLM decides what code to write, and sub-LMs can do the same. ### Bitter Lesson Claim - Madura states, **"in my opinion"** (and attributed as shared by "Alex" and other creators), that as models improve, you should defer more and more to the model to figure out what it needs to do. ## Origins and Benchmarks - Cites a tweet from **Omar** (described as Alex's adviser) about handling arbitrary-length inputs via DSPy techniques (summarization, table of contents) — Madura calls this "one of the first inklings" but explicitly qualifies: **"I don't know if this is the actual starting point for RLMs."** - Claims the paper/blogs show **demonstrably better performance** on long-context tasks: **uLong** (long-context Q&A) and **BrowseComp** (iterating large corpora), with the RLM's performance line "at the top." - **Cost comparison**: a tool-calling approach (GPT-5 calling a BM25 tool) was "even more expensive for worse performance than an RLM." - Performance testing by "our friend Raymond" on long chain-of-thought benchmarks: accuracy jump **from 2.6% to 45.4%**, especially on code-amenable tasks (logic puzzles, chess, chemistry). ## Why RLMs Differ from RAG / Agents / Tool Calling - **RAG**: "kind of just stuff the context window." - **Agents**: "largely just bringing strings back" without tight coupling of logic, execution, and results. - **RLMs**: the LLM interacts with results as **variables in the REPL**, doing additional computation instead of attending to all tokens in the context window. ### Context Rot Argument - References a talk by "Dex" (NYC, November) on context engineering and the "dumb zone" concept. - Claim: RLMs partially avoid **context rot** because full inputs aren't exposed to the main LM's context window — they live as variables; only relevant results come back. ### Relation to Coding Agents and Anthropic Workflows - Largest difference vs. coding agents: tool calls pass strings back and forth. - Notes Anthropic's **workflows** release; says someone at "the CIS conference" ("Tar or someone similar" — speaker uncertain) cited the RLM paper as a key driver. Workflows' intermediate results live in script variables, similar to RLMs. ## When to Use (and Skip) RLMs **Use cases:** - Large/dense input contexts. - Large **outputs** (hundreds of thousands of lines) — Madura flags this as **underexplored**. - Tasks amenable to decomposition (example: searching the entire tax code for loopholes). - Longer-horizon sessions. **Skip when:** fits in context, low latency needed, or the model "is as strong of a coder" (as-stated, garbled phrasing preserved). ## Demo and Simple Examples - Example: summing 12 numbers buried across 30,000 tokens — regex/code approach beats base-model attention. Madura concedes these examples are **"somewhat unfair"** to the base model. - Data frame example (cohort retention analysis): ~20 lines of code; RLM writes code directly in a REPL with the data frames, "as if it was typing in its own Jupyter notebook," avoiding tool-call bloat. - The LLM itself decides **when to stop** (via a `submit` action), with a configurable max-iteration variable. - Coding agent comparison: Madura admits **"I didn't look into this too deeply, there's probably some unfair math going on"** — Claude Code was "totally bloated" on these tasks, but "there's more work to be done." ## Ecosystem and Case Studies - Open-source libraries: **DSPy**, **axe** ("really interesting work"), **predict-RLM** (knowledge work: spreadsheets, PDFs), **fast-RLM**. - **Sam Hogan** (inference.net): tweet describing an RLM extracting insights from production workload traces to iteratively decide what to defer to a GLM 5.2-type model. - **Trampoline AI / predict-RLM**: invoice consolidation example; avoids chunking/embedding strategies for 200-page documents. Predict-RLM uses DSPy to define schemas between main LM and sub-LM calls — Madura speculates (untested) this would **improve performance for cheaper models** by enforcing typed inputs/outputs. - AWS engineer example: throwing arbitrary log data at an RLM. - **Halo project**: RLM analyzing agent traces to iterate on the **harness itself** ("meta abstraction / meta optimization"). - OWASP vulnerable-app example: ~500,000 lines of code scanned with minimal code to generate a security report. ## Closing Claim - Biggest promise: a future where models are **post-trained to be "RLM aware"** natively — "things will get pretty crazy pretty quick." ## Qualifications and Contradictions (Preserved As Expressed) - Madura repeatedly hedges attribution: "I don't know if this is the actual starting point," "in my opinion," "I think," "my sense is." - Demo comparisons to base models and coding agents are explicitly flagged as **potentially unfair / not deeply investigated**. - The cheap-model schema-performance claim is explicitly labeled as **untested speculation** ("I would want to do some experiments to test this out"). - Conference speaker attribution ("Tar or someone similar") is stated with uncertainty. # Speaker Attribution & Provenance Record **Video ID:** 01a15ca7-8f3c-76b6-b7b4-e5415e971ba0 **Title:** It's Tokens All The Way Down: How RLMs are Different — Kevin Madura, AlixPartners ## Speakers & Roles - **Kevin Madura** — **Sole speaker / presenter**. Self-identified: *"My name is Kevin Madura. I'm from a company called Alex Partners. We're a consulting firm."* (Company rendered as "Alex Partners" in transcript; likely AlixPartners per title.) - **Audience** — Present (show-of-hands interaction at open; Q&A implied afterwards). ## Roles Referenced (Not Speaking) - **Alex** — Co-creator of RLMs, per speaker. - **Omar** — Alex's adviser; originator of an early RLM concept (tweet cited). - **Dex** — Cited for a talk on context engineering at "Code in November" in NYC; coined "the dumb zone." - **Tar** (or similar, speaker uncertain: "I think it was Tar or someone") — Mentioned RLM paper as driver of Anthropic Workflows at CIS conference. - **Raymond** — Did performance testing on a long chain-of-thought benchmark. - **Sam Hogan** — Runs inference.net; recent tweet on RLM-driven production trace analysis. - **Anonymous AWS engineer** — Example log-data experiment, "from a couple days ago." ## Referenced Sources & Claims - **RLM paper / blog posts** by Alex and Omar — claimed better long-context performance. - **Benchmarks:** uLong (long-context Q&A), BrowseComp, long chain-of-thought benchmark (speaker cites jump "from 2.6 to 45.4% accuracy"; link left as "leave behind"). - **Comparison:** tool calling with GBT5 (transcript spelling) + BM25 tool noted as more expensive with worse performance than RLM. - **Frameworks/libraries:** DSPy, Axiom ("axe"), PredictRLM, FastRLM, Compound (platform, RLM/DSPy-native), Halo (trace-based harness optimization), inference.net. - **Anthropic Workflows** — cited as RLM-influenced. - **Case examples:** Trampoline AI (PredictRLM, knowledge work), OWASP ("OASP" in transcript) vulnerable web app security scan, cohort retention analysis demo. - **Claims of uncertainty:** Speaker explicitly flags an unfair coding-agent comparison ("probably some unfair math going on here") and speculation about cheaper-model performance ("I would want to do some experiments to test this out"). ## Promotional Segments - None explicitly flagged as promotional. Speaker represents AlixPartners, a consulting firm; no product pitch or sponsorship identified in the transcript. ## Availability & Limits - No curated metadata supplied (comment availability, description, cited links absent from source). - Speaker references a benchmark link "left behind" — not present in transcript. - Several attributions are hedged by the speaker ("I think," "or someone similar"). Yep. Awesome. Thanks everyone for being here. My name is Kevin Madura. I'm from a company called Alex Partners. We're we're a consulting firm. Um I'm here to talk to you today about RLMs. Just curious, show of hands, who here is familiar with RLMs? So we know how much time to spend on it. Okay. So not many. All right. Well, that's good. So we'll start with what an RLM is and and why it's different. So RLM is recursive language model. And really the the key difference here is that it treats the context as an object that it can interact with symbolically in its environment. So it differs from a tool call in the sense that typically when you do a tool call it's JSON or some type of string that's being sent being interpreted elsewhere maybe by some other program and that's that's returning effectively as a string. The key difference here is that it's interacting with a symbolic environment. So typically that's a ripple Python ripple. Um so that's key difference number one. Key difference number two is that it's it has the ability to delegate to another LM often to itself. You can specify whether it's the same model or a different model, but fundamentally because it lives in this environment, you can offload or or make a sub call to another LM with particular parameters that also lives in that ripple environment. And so you get this ability to recursively decompose problems and apply and have the LLM basically decide how to apply certain logic or certain interpretations or write its own code to solve those problems and then that recurses down. So the subLM can do the same sort of thing in terms of understanding and interpreting what it thinks it needs to do. And I added this last one here. It's largely bitter lesson pilled in my opinion, right? is and and shared by Alex and the rest of the the creators of it. But as models get better, you should be able to defer more and more to the model for it to kind of figure out on its own what it needs to do. So the I don't know if this is the actual kind of starting point for RLMs. This is one that that I consider to be one of the the first kind of inklings of it. This is a tweet from Omar who is Alex's adviser um for for RLMs. And this was a concept that he had come up with where it was basically an ability to use DSPI and some other techniques to take in arbitrary um arbitrary length inputs. And basically the use case here would be summarizing an arbitrarily long document and coming up with a table of contents and some summary of of that content. But at least to me, this is kind of the first inkling of okay, context windows might not be something you need to deliberately manage. Although there's of course benefits to doing so, uh there there could be ways to um to exceed the the the context windows using some of these clever techniques. Uh and so if you read the paper and some of the blog posts that are out there from Alex and Omar, I mean it it it has demonstrabably better performance on some of these long context tasks. So, ulong is one benchmark where um the the intent of the benchmark it's is to measure model performance on answering questions about excessively long context. This another one browse comp where it needs to iterate through a large a large body and corpus of text and answer particular questions about it. You can see the blue line at the top there is the RLM. It's very good performance as compared to some of these other models. And even on on the price curve, the the purple is actually just using tool calling um with GBT5 calling a BM25 tool. And that's actually even more expensive for worse performance than than an RLM. So it's worth reading into if you're interested in in some of the benchmarks and how RLMs perform. Um but fundamentally uh an RLM again takes in your input and you're kind of deferring to the model about how to decompose the process what code it needs to write and it is very tightly integrated with the ripple itself. So it it by itself defines what it needs to do. And so I kind of had this mental model in terms of and I'm very DSP pipel if if you couldn't tell by now basically a student of of Omar and the rest of the group there where you have this relatively deterministic shell of what you want to do like what what is your intent what is your actual task that you're trying to accomplish. You define that in terms of your inputs and your outputs and some type of guidance or prompt or what have you to the model to say this is generally what I want to achieve. go off and do it. Here's the things that you can expect as your input. Here's what I want out of it. Go figure out the rest. And so this applies for using something like DSPI, but I think it applies to RLMs as well because you don't have to worry as much now about how the actual implementation works in the middle. You can just have some guarantees about the inputs and the outputs and you can let the model figure out the rest of of that part of it. So, a lot of this comes down to if if you were at um I think it was code in November in uh in New York City, Dex had this great talk about just broader context engineering and he he coined something like the dumb zone which it's kind of grayed out at the bottom there. But the point is that we all know that there's context rot, right? Once you fill up the context window to a certain degree, performance starts to degrade. And so RLMs somewhat get around this problem because the context itself doesn't fill up as quickly because you're deferring a lot of the subtasks to the subm models and it's the full kind of context and the inputs aren't exposed to the context window itself. It lives as a variable in the ripple and so the main LM can choose how to um how to access that. It can offload some of these subtasks to to sublim. And really the only context that it gets back are the things that actually matter. So in terms of how it's meaningfully different, rag of course you kind of just stuff the context window. You want it to limit there. Agents are largely just bringing strings back and you don't have this tight coupling between the logic, the execution and the results. And so you still run into the same sort of problem there. Same thing with tool calling and and codec. And then RLMs as I mentioned you're act the the LLM is actually just interacting with the context the results as variables in the ripple so that it can do additional computation on versus it trying to attend to all these different tokens in this in its context window. It's it's a meaningfully different way of of the LLM interacting with the uh the actual content itself. And so people always say, okay, what's the difference between that and and encoding agents? Um, in my mind, the largest difference is that the way that tool calls are tool calls calls are done is passing strings back and forth. Um but you can see with the release recently of workflows that uh Anthropic is doing something fairly similar and they um at the CIS conference I think it was Tar or someone similar um mentioned the RLM paper as a key driver of workflows and how they're how they've implemented it. And you can see here the intermediate results for workflows live in script variables i.e. a variable in the context. So, it's driving some of these these breakthroughs and some of these techniques from the from the labs as well. I'll skip through this a bit just because I have about 10 minutes left, but generally speaking, when you want to use it, it's obviously for large or dense input context. An underexplored area is outputs as well. So if you have a some type of task where you need to generate hundreds of thousands of lines or whatever it might be, RLMs I think would be a good candidate for that as well. Obviously tasks that are imunable to some type of decomposition. So if you want to look through the entire I don't know the whole tax code as an example and try and find loopholes or something. You can't obviously put all of that into context at once. You could use an LLM to crunch through all of that and iteratively explore and use sub agents to explore interesting areas of this of the tax code. Bring back those sections and then reason over that and then just generally for for longer horizon sessions. And when you want to skip it, of course, it' be something that fits in context. You want something that's low latency or the the model itself is as strong of a coder. And uh our friend Raymond here did some great perfor performance testing on the long chain of thought benchmark. Um I'll leave this link as a as a leave behind after, but just to give you a sense of how well it performs on some of these tasks. It's a meaningful jump overall from from 2.6 to 45.4% um accuracy on many of these tasks. And you can see it performs really well on things that are amanable to code. So logic puzzles and and chess and chemistry and things like that where it can dynamically write code bring in only the relevant part of the context compute that and then return the result where the main model is really just harvesting the results from from the subLM and try instead of trying to do that by itself. Um I put together a few just super simple examples. I mean, these are kind of they're somewhat unfair, I suppose, to to the base model, but it it makes the point that there are certain tasks that base models just aren't really fit to do themselves because they because they have to attend all these to different tokens at once in the context window where you need or want to use some type of coding approach to that. So in this random example, summing 12 numbers that are buried across 30,000 tokens, the LLM trying to figure all that out by itself and give you the answer isn't always going to work as well as something that you can write reg x4 or something similar. And then the same same sort of thing particularly for data frames and we'll walk through a brief example here where because the LLM can interact with the data frame within the ripple. It just has a much better understanding of the content and can iterate through that much more quickly than having to pass tool calls back and forth in terms of like JSON strings and and that sort of thing. Um, and then I threw this in there in terms of running the same experiments with a coding agent. Now, I didn't look into this too deeply. There's probably some unfair math going on here, but you can see that it was totally bloated in terms of the way that cloud code tried to um tried to solve these tasks. So, there's more work to be done there, of course, in terms of like running experiments to compare base models versus RLMs versus something like a coding agent. But there's just for certain tasks for like production workloads. My sense is you probably don't want to just do cloud-p your prompt and like hope for a good result. Like you want more of a structured approach to your inputs, your outputs and you want a defined pipeline for doing so which reduces your cost, it reduces your complexity, reduces your bloat, all that sort of thing. Um where RLMs can can shine. So in the real world there are a bunch of different open source libraries that implement RLMs at some level. Some of them are more RLM focused uh like a predict RLM would be a good example of that versus others are kind of just integrating it into the broader approach or the broader framework. DSPI obviously uh there's axe which is really interesting work uh that's being done there. Predict RLM is more focused on like knowledge work. So it works with spreadsheets and PDFs and that sort of thing and then fast RLM. And then there's a tweet yesterday from this guy Sam Hogan um where who runs inference.net. He's using an RLM to basically run and extract um insights from your particular um production workload traces so that they can see what makes sense to defer off to something like a GLM 5.2 too and do that iteratively and automatically as your traffic goes through. So point being, you don't have to worry about context engineering. You can kind of just throw the RLM at it and have it figure it out. Um, I only have five minutes left, so we won't go through this whole example and I'll I'll skip to some of the traces because that's probably the most interesting. Um, but this is all you would really need to do in terms of a simple, in this case it's like a a cohort retention analysis, something that you might give to a data scientist. But this concept of applying an RLM to a complex data structure like a data frame becomes very easy to do. This is all the code you need to do it where I'm feeding in three different data frames. I'm saying these are the sorts of things you need to look for. These are the output types that I want. and then just let the RLM go on it. And I'll I'll show you some of the traces. Um, and so it has its own ripple where it can interact with those data frames. And you can see it reasoning through. Okay, first I need to do this. It's writing the code. And because it's li it's living in the ripple with the dataf frame, you don't have this additional bloat of the tool calls back and forth. It's actually interacting directly with the dataf frame as if it was typing in its own Jupyter notebook. And there there's significant advantages for for doing so. And so you can see the sorts of outputs that it gets as a result. And it by itself will iterate. And in this case it didn't, but it has the option to defer to subLM to do okay. And now I have this big whatever this big subset of the data sublm go off and do this analysis give me the result and it can do that iteratively over time. Uh but the point is that the LM is directly interacting with the data frame in its ripple um and kind of iterating through the results. And so this u this platform compound is RLM and DSPI native. So it gives you this really nice breakdown of the reasoning. It separates out the code that's being generated and ultimately you can see uh the final output which is here where it's formatting. Okay, here are the key findings that I have. Here are the recommendations. And then you have this final submit which is the final answer that gives you the the typed um outputs that you had defined up front. And the key thing here is that the LLM itself is deciding when to stop. So you have this you have a variable of max iteration. So you can just you can decide whether you want it to have a maximum of 10 or 100 or whatever it is. But it will by itself explore the data, understand what needs to happen and then when it it itself is comfortable, it can run submit and give you the final output. Again, being bitter or less impilled, this will get better over time. You can kind of just defer everything and it will figure out what to do. And so the hope would be you don't have to I mean we're already you know whatever this is 20 lines of code or something. Um, but you can you can see a world where you can continue to go up levels of abstraction. As long as you can define what your objective is and what you want it to do, the the model will kind of figure out the rest. Uh, so we just walk through a bunch of this, but um these are the different steps that it took in this example in the code that it wrote. Um, and then I'll just breeze through a few real world case studies and where it's actually being used. So I mentioned predict rm before. So the company trampoline AI I think it is they're doing really interesting work in applying RLMs u like I mentioned before for different pieces of knowledge work. So natively interacting with PDFs and and spreadsheets and that sort of thing. So in this relatively simple example okay I have a bunch of I have a directory of invoices that I need to create one consolidated inventory out of. As we all know invoices can be complicated. that can be very long, that can kind of be all over the place. To do that today without RLMs or this sort of like framework gets very complicated very quickly. I have a lot of battle scars to to prove it. Um, but with something like an RLM, you you don't need to worry as much about, okay, if I have a 200page invoice or contract or whatever it is, you can let the RLM just churn through all of that and give you the result instead of having to worry about chunking and embedding maybe and doing all these different strategies to try and get around the context window management that we've all had to to do previously. Um, so it allows you, the point there is that you can focus on the abstractions and what you actually want to do instead of the context engineering itself, which I think is a really helpful um, helpful output of all of this. And an interesting tidbit for all the DSPI fans in the room, predict RLM uses DSPI to determine the schemas between the main LM and the subLM calls, which I personally think is is a nice feature because you have a lot more readability and maintainability. So you understand exactly what the model is trying to achieve and the model can be much more precise and prescriptive about the types of data that it's looking for from the subLM. And I would want to do some experiments to test this out, but I would think that this would improve performance for cheaper models like a a Quinn or some of the other ones because you're specifying the inputs and outputs and you're enforcing those types coming back. And so you get all the benefits of the RLM being able to churn through all this information, but you have a lot more of the structure in between where when it's handing off to a sublm, it it enforces some of the uh some of those schemas. This is an example from um an AWS engineer from a couple days ago. We were just kind of playing around with it, but I just thought it was a nice example of you can kind of just throw arbitrary data at RLM. In this case, it was a bunch of log data um to surface some interesting uh results and he he found it useful. Um there's a a project called Halo which uses an RLM to look at traces of um of different t uh agent tasks. And basically the promise of Halo is that instead of optimizing a particular like workflow or DSPI uh or or other framework uh like structure itself, it's it's actually iterating on the harness. So it's like a meta abstraction almost or meta optimization of the harness itself and it uses an RLM because as we all know tracing can get very long and and complicated. So the RLM can not only take in all that context but also leverage the um the structure of those traces to to recommend a better um a better harness. And then this last one uh this is all the code you need. I ran this little experiment. There's a an intentionally vulnerable application called uh it's from OASP, but basically there's a it's a web app with a bunch of vulnerabilities in it. This is all the code you need on the right hand side to run basically an agent to run through whatever it is 500,000 lines of code to generate some type of security report. That's just an arbitrary example, but the point is you don't need a lot of context engineering. You don't need a lot of structure around it to achieve what you want to do. And so you can feed in an arbitrary uh size codebase into this and get some type of insights out. So you can imagine that being applied to other areas as well. Um so I know I I rushed through everything a little bit but I'm happy to answer questions afterwards. Uh the I'll leave you leave you with this. The biggest promise I see here is just imagine a world where the models are actually post-trained and actually like RLM aware. I think things will get pretty crazy pretty quick when they actually know how to use and kind of take advantage of the RLM methodology natively. So, thank you so much for your time.