Conference talk by Rémi Louf (.txt) titled "Agent Frameworks Considered Harmful," recounting how early failures running daily agent briefs motivated building a custom agent runtime instead of using a framework. Topics covered: why agents are defined as markdown files (accessible to non-coders) and subscribe to events rather than living in a maintained graph; an append-only event log where every event is causally linked; a queue that tracks retries for duplicate handling; content-addressed prompts stored as lists of hashes (system message, skill descriptions, tool definitions, user question), enabling diffs between runs and replays against different models; typed tool calls and typed events as boundaries after ~20% of events arrived malformed; and lessons including "build before you buy," with twenty agents now running at his company. Timestamps range from the motivation (taking two weeks to explore agents) through the log, content addressing, the "kernel, not a framework" framing, and closing lessons. # Channel Identity Observations: Talk Video — Rémi Louf (.txt) ## Creator Self-Description (Explicit Claims) - **Role and company**: "I'm the CEO of dot.text... which is 15-people company." - **Product expertise claim**: "structured outputs is our special team. We've been working on this for 3 years" — describes the talk's runtime project as "a big dog fooding project." - **Content positioning**: Presenter explicitly reframes the talk: "originally I thought I was going to give a very technical talk, but I saw I was in the leadership track... I'm going to do half high-level and half technical." - **Non-commercial intent for the demo**: "You can steal the code. It's not a product that we sell and we don't intend to sell this." - **Supplementary content claim**: "I wrote a really long blog post about this" (referenced via QR code) and "I will publish something about it." ## Observable Presentation Patterns - **Audience**: Mixed technical and leadership audience at a conference with a "leadership track." Speaker addresses subgroups directly: "if there are distributed or ex-distributed engineers in the room," "if you're a small company, if you're a tech CEO." - **Scope of content**: Hands-on engineering narrative about building an agent runtime — markdown agent definitions, event-driven orchestration, append-only event log, content-addressed prompt storage, replay, typed tool calls/events — framed as a personal two-week project ("the story of me scratching my own itch for 2 weeks"). - **Style**: First-person storytelling with humor and candor about mistakes ("the first day daily brief was posted to Slack twice," "I did a very dumb thing as a CEO, which is I started coding. Don't tell my board."). - **Opinionated technical stance**: Skeptical of agent frameworks ("Agent Frameworks Considered Harmful," "I'm going to name any frameworks because they're all good in their own way and they will have flaws in their own way"); argues "You do not need graph in this case. All you need is events." - **Actionable advice to audience**: "definitely start building before you buy"; "to people building frameworks for this is please eat your own dog food"; urging leaders to "stop and actually immerse yourself in this." - **Demo-evidence offered**: Repeatedly asserts the system is real and deployed: "This is a real thing. It's working. I can show you after on my phone"; "we have 20 agents... that are not just contributed by technical people." ## Demonstrated Relationship to Company - The personal project became company infrastructure: "The result of that is actually deployed within the company after I built this" — showing a channel pattern of building in public tied to .txt's structured-outputs focus, while explicitly disclaiming that the runtime itself is a product. # Delivery Observations — Rémi Louf, "Agent Frameworks Considered Harmful" ## Tone - **Conversational and self-deprecating**, with casual asides to the audience: - > "I did a very dumb thing as a CEO, which is I started coding. Don't tell my board." - > "Uh I hope my board won't see this talk." - **Candid and informal**: filler words ("you know," "um," "I mean") appear constantly throughout, signaling a spoken, unscripted style. ## Vocabulary & Recurring Phrases - **"You know"** is the dominant verbal tic, appearing in nearly every paragraph (e.g., "you know, there was a step function," "and you know, all I wanted was my morning briefing"). - **"Rabbit hole"** repeated twice for deep-diving detours: - > "it became a really a crazy rabbit hole" - > "I got into a really deep rabbit hole in there" - **"Good old"** as a framing device: - > "it's just good old engineering problems" - > "It's just good old software orchestration." - **"Magically"** for things that work without effort: "it just magically appears... and it just magically works"; also "really magical" in the conclusions. - **"There is nothing new under the sun"** — used twice to frame his runtime work as rediscovered systems engineering. ## Teaching Habits & Communication Patterns - **Analogy-driven explanations**, especially the recurring **robot mower analogy**: 1. Introduced early ("this robot mower, which kind of works unattended all day"). 2. Extended mid-talk ("the equivalent of having a robot like a tractor mower that you still have to stay on"). 3. Recalled in the conclusion ("they feel like this, you know, robot mower"). - Also: content addressing explained as "you can think of get [git]. You can think of next [nix] and any other build system." - **Narrative structure**: a personal story ("the story of me scratching my own itch for 2 weeks") punctuated by real failure examples ("the first day daily brief was posted to Slack twice," "one of my voice notes completely vanished"). - **Honest disclosure of limitations and motives**: - > "The code is not amazing, but it works." - > "this was a really clickbait title" - Disclaimer framing: "disclaimer structured outputs is our special team... it just ended up being a big dog fooding project." - **Direct addresses to the audience** with advice: - > "I would definitely try to build before I buy" - > "please eat your own dog food" - > "what I'm urging you to do is to stop and actually immerse yourself" - **Contrast framing** ("not X but Y"): "The job of the kernel is actually to make bad actions impossible not just unlikely"; "You're just manipulating a graph... You're not manipulating strings." ## Uncertainty Notes - Delivery features like pacing, pauses, or gesture cannot be assessed from transcript alone; only a single [snorts] nonverbal cue appears. - Audience reaction is not observable, so claims about engagement effectiveness would be speculation. # Observation Record: "Agent Frameworks Considered Harmful" — Rémi Louf, .txt ## Context and Framing - Speaker: **Rémi Louf**, CEO of **.txt** (a ~15-person company). - He took **two weeks in January** away from CEO duties to explore agents, motivated by a perceived step-function improvement in agent capability around December, which he attributes to **Opus 4.6** ("I think it was Opus 4.6" — tentative). - He admits the talk title is "clickbait" but says it turned out apt. - He frames the talk as half high-level, half technical, having discovered he was in the "leadership track." ## Motivation: The Robot Mower Analogy - He rents an office in a castle and has a **robot mower** that works unattended all day — his goal was the same autonomy for his mornings. - His morning routine: browse market news, review Linear, PRs, CRM; walk an hour while recording a long voice note; then an hour processing that note. - Current agent UX stages (his analogy ladder): - **TUI (terminal)**: like a self-driving tractor you must still sit on. - **Mobile apps ("SSH web vibes", e.g., Codex)**: like a remote-control mower — useful but "absurd" and "clearly transitional." - Desired: fully unattended background agents. ## Core Thesis: Agents Without Code or Graphs - Starting with frameworks, he found himself mostly **editing prompts inside code**, which felt wrong. - Despite disliking YAML, he found **declarative agent definitions** (files dropped in a folder) far easier: versionable, diffable, reviewable in PRs; agents "magically appear" once the runtime exists. - **Cron jobs** handle scheduling, but cron only covers "when" — insufficient. - **Events** are the real primitive: dropping a voice note, a new email, CRM entry, PR opened/merged — agents subscribe and react. - Claim: **"You do not need graphs... All you need is events. You have no edges to maintain."** Topology emerges from event subscriptions; anyone, including non-coders, can add agents by dropping a file. - Example pipeline: voice-note agent (accepts voice note → transcribes → durable notes → emits `voice_note_processed`) → daily brief agent (consumes cron output + voice note events) → `slack.message.post` event → Slack brief. He says this is really deployed. ## Failures and the Emergent Runtime He reports real failure modes from the first week: - Daily brief posted **twice** to Slack. - A voice note **vanished**. - Market brief became "garbage" after a week of prompt edits — **no versioning**, couldn't recall what broke. Each failure drove a runtime feature (he insists he wasn't designing a runtime, just fixing errors as they appeared): - **Log**: append-only, causally-linked event table — "the system's memory," queryable, essential for debugging even with three agents. - **Queue / attempt tracking**: to fix duplicates. - **Content addressing** (à la git / Nix build systems): each prompt component (system prompt, skills, tools, user message) stored and hashed; prompts represented as **lists of hashes**, not rendered strings. Model answers stored the same way. ## Why Content Addressing Matters (his claims) - The Codex-style chat view "is kind of a lie" — what you see isn't exactly what the model saw; causes include **compaction**, quirks, and labs (**OpenAI, Anthropic**) not sharing thinking traces. - Benefits he claims: - **Traceability**: reconstruct exactly what entered the model's context. - **Diffs** between runs: see which prompt components changed. - **Replay**: rebuild requests from the graph, re-run on different models (he used this to try open-source models as costs ramped up). - Easier **compaction** and **KV cache management** ("you're manipulating a graph, not strings"). - **Auditability** at scale — know exactly why an agent returned what it did. ## Kernel / Userland Model - Critique of frameworks: "frameworks just call code... your agents live inside their abstractions." - Analogy (which he says he doesn't like but uses anyway): the runtime is a **kernel** that schedules, isolates, and journals agents (processes); the **markdown agent definitions are userland** — usable without the system (a .txt frontend doesn't use the markdown format at all). ## Structured Outputs — Disclosed Conflict of Interest - **Disclaimer he gives explicitly**: structured outputs are .txt's specialty ("we've been working on this for 3 years"); the project became a dogfooding exercise. - Stated reason for using it: **Anthropic "was terrible at structured outputs"** — ~20% of his events were rejected as invalid. - Design principle: the kernel should make **bad actions impossible, not just unlikely**, via typed boundaries: - Typed **tool calls** (no calls to nonexistent tools). - Typed **events** between agents — "this is non-negotiable." ## Deployment Results - After ~a month internally: **20 agents**, contributed not only by technical people (attributed to markdown's accessibility), plus an "intranet" with briefs and other outputs. ## Stated Lessons - **Well-executed background agents are "really magical"** — his morning brief appears daily and is "probably even better" than doing it manually. - The difficulties are **"good old engineering problems"** — "nothing new under the sun" in orchestrating agents. - **Open-source models are good enough** for his use cases (he removed all third-party APIs, uses local models on his laptop); he explicitly hedges: "For coding, I don't know." - **Infra category is "definitely unsettled"** — advises **"build before you buy"**, especially for small companies/tech CEOs. - Plea to framework builders: **"please eat your own dog food"** — he suspects many don't. - Glad he took the two weeks; says it "changed the trajectory of the company," urging others to immerse themselves. - The code is not a product; it can be "stolen"; he plans to publish a blog post (references a QR code and a long blog post on typed events). ## Qualifications and Tensions Preserved - His model-attribution for the capability jump ("I think it was Opus 4.6") is tentative. - He is candid that the project was partly a "distraction" and partly dogfooding of his own company's product — a disclosed incentive. - "Mostly worked" hedging on early versions; failure examples are real but dates were fabricated. - Uncertainty about the current framework landscape ("It might be different today because it was a couple of months ago"). # Video Attribution Record **Title:** Agent Frameworks Considered Harmful — Rémi Louf, .txt **Video ID:** `01a15ca7-c5b0-7fdf-9615-e50339962c83` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Single speaker | **Creator / Presenter** — self-identified as **Rémi Louf, CEO of .txt (dot.text)**, a 15-person company | "I'm the CEO of dot.text" | - No guests, narrators, or other identified speakers appear in the transcript. - The talk is framed as a conference presentation (mentions a "leadership track" and an in-room audience). ## Self-Described Provenance & Affiliations - Speaker states he is **CEO of .txt**, a **15-person company**. - **Disclaimer / promotional segment (flagged):** Speaker explicitly notes **structured outputs is "our specialty"** — his company has worked on it for **3 years**, and the project became a **"big dogfooding project."** This is a disclosure of commercial interest. - Speaker states the system shown is **not a product they sell** and they don't intend to sell it ("You can steal the code"). - Speaker jokes "I hope my board won't see this talk" and "Don't tell my board" regarding coding as CEO. ## Referenced Sources & Claims - **Model capability claims:** A "step function" in agent capability around December, which speaker attributes to "Opus 4.6" (third-party claim, unverified in transcript). - **Third-party claims about AI providers:** Speaker asserts **OpenAI and Anthropic "don't share the thinking traces"** and that **Anthropic was "terrible at structured outputs"** (third-party claim, unverified). - **Tools/products named:** Codex ("great"), Slack (delivery channel for briefs), cron jobs, "SSH web vibes" apps, LMCBP (mentioned as something he didn't want to fork). - **Own blog post:** Speaker references a "really long blog post" accessible via a QR code in the slides, and says he "will publish something about it." - **Repository:** Speaker mentions "the repo is there" in the slides; no URL given in transcript. ## Evidence Channels & Availability - **Slides/QR code/repo/blog:** Referenced but **not included** in transcript; URLs unavailable. - **Live demo:** Speaker offers to show the working Slack integration "after on my phone" — not part of the transcript. - **Comments availability:** No metadata supplied; **unknown**. - **Curated metadata:** Absent; no speaker list or sourcing metadata provided beyond the transcript itself. ## Uncertainty Notes - Failure examples shown ("daily brief posted twice," "voice note vanished") are described by speaker as **real examples with placeholder dates** ("The dates no, but it's real examples"). - Speaker notes his findings about the framework ecosystem are "a couple of months old" and "might be different today." \>\> Hi everyone. So, originally I thought I was going to give a very technical talk, but I saw I was in the leadership track, which I'm not sure what it means, but I was like, "Okay, I'm going to do half high-level and half technical." So, it's more a story about what I you know, what I did in January because in around December um agents kind of became really good. Uh you know, there was a step function, something happened. Uh I think it was Opus 4.6. And that's when I realized and I work in AI, where I was like, "Okay, this thing is really happening." And so, I took 2 weeks out. I took 2 weeks away. So, I'm the CEO of dot.text, uh you know, which is 15-people company. I just told my CTO, I was like, "Okay, I'm just going to go away for 2 weeks and I'm just going to dive in this thing and try to understand what we can get out of it and how good it is. And so, the story is, you know, it is the story of me scratching my own itch for 2 weeks and trying to figure out how we can use actually use agents and what are good primitives to build agents and whether, you know, it already exist. Um this was a really clickbait title, but actually it turns out to be a good title even for this talk. Um so, what you can see here on the left, the castle, is my office. Uh that's true. I do rent an office in the castle. And the small thing with an arrow uh that you can see is like this robot mower, which kind of works unattended all day, every day. Uh it just does its stuff in the background without anyone having to use a remote control or think about it or anything. And I kind of wanted the same thing for my morning because my mornings are always the same thing. The first couple hours is browse market news review of like linear PTROS my CRM. And also I like to walk for an hour about an hour in the morning and then the next hour is spent trying to process the really long voice note that you know was recorded while walking. And you know all I wanted was my morning briefing with my coffee. And that's kind of what we've been told for a couple of years that what the future would be. Um but then when you really start working with it even if you're not coding all you get is a TUI today. Uh so it's amazing. You can code. You can actually you know I started doing things that were not coding in it. They're great for this. Uh agents are great for this. But it's kind of the equivalent of having a robot like a tractor mower that you still have to stay on even if it's driving by itself, right? It's kind of very frustrating because you have to it can do many things but you still have to be on. And so of course the labs didn't stop there. And they came up with apps uh which I call basically SSH web vibes. That's great but in this situation when that came up I was like well that's awesome. I don't have to use like a like a SSH on my phone anymore. Codex is great. However, I noticed I just started you know and I was on my walk and I was just instructing the agent to do things while I was walking and so I wasn't thinking you know very clearly anymore. I just started running agents on my phone during my morning walk. And this is not great because this is the equivalent of this. It's you kind of midway. You it's not the tractor that you have to stay on. It can actually do something without you being right next to it but you still have this remote control that you know you kind of have to change your trajectory every now and then. Uh that's useful. It's kind of absurd when you think about it and actually when you look at people like on their phone all the time, just doing this is kind of absurd and it's clearly transitional. Like surely we're not it's not it's not going to stop there. Um And so, I did a very dumb thing as a CEO, which is I started coding. Don't tell my board. And I started to build the dumbest thing that could possibly work. And of course, it became a really a crazy rabbit hole. Uh the repo is there if you want to take a look at it. The code is not amazing, but it works. So, the first thing is that you know, I started using frameworks. I mean, there are great frameworks and I'm going to name any frameworks because they're all good in their own way and they will have flaws in their own way, which is fine. Uh but I spent all my time actually editing the prompt within the code and I was like, this is actually not very useful. So, I'm like everyone here, I hate YAML uh like the next guy, but I still found that this was actually a lot easier to start implementing agents without code. Uh you can version it, you can diff it, you can review in the PR. Um but it's just and it's just so easy. You can just, you know, write your file, you drop it in a folder, and then it just magically appears once you have the runtime and it just magically works. Um and you know, then I needed like my market watch to run every morning while I'm, you know, while I'm walking in the fields. And for that, we have things that, you know, have been around for a while, which is cron jobs. Uh and schedules specify, you know, when the agents need to be run. And also, we'll see it's very important later, uh they publish they publish events. And you know, markdown and cron, obviously, you know, it's much more complicated than that under the hood, but the interface is this. You don't write code. And that's the whole product so far. And honestly, just mostly worked at this point. I'll I'll come back on mostly later. And so, this is actually a real picture of my one of my morning walks. And so, what I do is I record voice notes while I'm walking. Uh but cron, you know, cron jobs I mean, people would use cron jobs for this because that's what's available in Cortex today, but they're not ideal because they cover when, but this is just one point in time. It doesn't cover because this happened. And you know, things that happened in our system like automatically when you drop the voice note now in the system, it will emit an event, and an agent will react to that event. And it's the same thing when you have a new email, a new entry in the CRM. I mean, anything, a new PR that's open, a new PR that's merged, etc. It just reacts to events. It's not just a cron job. And that And that means that, you know, agents of the voice note processor is just, you know, not a cron job. But here, you have accepts and returns. So, it just declare what it accepts and what it returns as an event. And here, it accepts a voice note, transcribes it, turn it into durable notes on the right, and it emits a new event. And for that, I use the structured outputs. We'll come back to this. And you know, now we finally have the future we're promised because that voice note agent emits voice note processed. And then I have my daily brief agent that actually will take the output of the cron job, will take the output of the voice note agents, and we create my daily brief, which is posted as as a Slack message. So, the Slack message.post event is actually uh is actually like um um a process actually subscribes to this and emits uh and sends a Slack message to me. It's actually this is a real This is a real thing. It's working. I can show you after on my phone. And, you know, there are frameworks that are going to sell you the fact that you need graphs for this and code. Uh you do not need graph in this case. All you need is events. You have no edges to maintain. Agents simply subscribe to events. Anyone can come in and edit this. You don't need to Yeah, you don't need to know how to code. You just need to know what events exist in the system. Funneling and funnel are free, no code, and it's just drop a file and the topology emerges. Whatever the log says happened. And, you know, then of course I I tried to run it. So, the first version took about I mean, you know, I cheated I cheated I used I used code X. And it took about like a day to write like the first thing out of my week. But of course I tried it and it broke. Uh so, these are real examples actually. The dates no, but it's real examples. Like the first day daily brief was posted to Slack twice. On Wednesday one of my voice notes completely vanished. And then, you know, towards the end of the week I I kind of like played with the prompts all week and the market brief was garbage. But I didn't version I didn't version my changes and I couldn't remember actually what I changed in the prompt that made the thing completely useless. Now, if there are distributed or ex-distributed engineers in the room, you probably know this shopping list already. Uh there is nothing new under the sun. And, you know, each failure, so each of these failure modes that you found actually led to building one piece of what turned out to be a runtime. So, the last note actually turned into a log. I just wanted everything to be saved forever so that I could go back to it and look into into what happened. The duplicates was because I was not following, you know, it did several attempts and I was not following them. I didn't have a proper queue. I wasn't counting the attempts, etc. etc. And then uh probably the most interesting part is the last prompt. I got into a really deep rabbit hole in there and I just ended up uh building a content like a content addressed system for this. Uh content addressed system you can think of get. Uh you can think of next and any other build system. And you know, that was and I didn't do this because I wanted to design a runtime. I mean, by that point I still just wanted my agents to work. And I also like the distraction. Uh and I just paid off that as it appeared like errors as they appeared. Uh I hope my board won't see this talk. Uh so, the log. The log is the system's memory. Uh nothing is lost and everything is observed. Uh you can, you know, you only have one append only events table. On the left it's a real command line uh in like command etc. events and you get all the events. They are causally linked as well. Like you know which event triggered which event, which happens to be super useful when you're debugging. And you know, even with three full agents you start having like major debugging headaches. So, that was super super helpful. Um And everything is queryable, which again is for debugging. The second thing is, you know, Okay, we have a log so we can trace back things etc. But still really hard to know what went into the like what went to the model, what prompt was sent to the model again. Because what you see when you're using Codex is kind of a lie. Like you kind of have like a live chat session with the model and so you tend to think that oh, that's what the model saw and you know, that's exactly so I can understand what happened. The truth is that's not exactly what the model saw. Um there are many reasons for that. One is I mean compaction obviously is a big is a big thing but also, you know, there are just quirks. Also, you know, OpenAI doesn't share or Anthropic for that matter don't share the thinking with you the thinking traces. So you have no idea. I mean kind of have an idea of what went in but not completely either. And so you need something different. Uh you need something different and that was the big rabbit hole which is trying to find a way to build a system where you can trace back to what the model saw internally. And so what I did was basically built I mean nothing new. This is basically how built system works. Uh so you have different parts for prompt. You have your system prompt. You have a description of your first skill, of your second skill, then you have the description of your tools. You have your user message which is the question to the model. Each one of those is stored and addressed and you know, stored somewhere as a identifier which is a hash. And so when we build a prompt instead of building a piece of I mean before rendering the text, we actually represent the prompt as a list of these uh of these hashes. And so what that means is that down the line when I have a model answer, which by the way is also stored in the same way, we can trace back to the prompt very easily and then from that prompt we can know exactly what went into the model's context, which actually matters a lot. I mean it matters a lot for debugging but it also matters I mean it makes compaction a lot easier. You're just manipulating a graph, right? You're not manipulating strings. It's just a lot easier and it makes KV cash management a lot easier as well indirectly. And but I think that when, you know, I guess probably the main advantage that's when you use that scale is really auditability. It's like you can know exactly what happened with that agent and why it returned to what it returned. And so, you know, I'm just going to go pretty pretty quickly over this. Uh what you get once you have this graph is you get diffs. Like you can say, "Okay, what changed between these two runs? Like what which components changed? Was it just my message? Did I like give the model a different skill? Did I give it a different tool?" So, you can just Yeah, you can just run this function and it will show you, you know, the difference between uh the runs. So, here you have, you \[snorts\] know, three components that were identical. There's one which is, you know, the user message changed. And then you had all these other messages that were actually, you know, that were continuing as continuation of a single session. Uh then you have another thing for free, which is replay. Uh replay turned out to be really useful for me because after a while, I mean, when I saw the cost ramp up, like the thing when you have observability, is I do realize that cost increase very quickly. I wanted to try with open source models, and so I wanted to rebuild all requests for to eval and see if I got the same thing out, if I got something satisfactory, or if I needed to change anything. And turns out that once you have, uh you know, this content addressing system, you can rebuild the request from the graph, and you can just replay it exactly the same, and you can, you know, resend, you can use a different model, uh you can use a different request if you want, you can you can change it. And so, yeah, you get actually a lot of things, I mean, for free. You need to implement the thing. Um and so, this is kind of different um from what you find I mean what I found when I started doing this. It might be different today because it was a couple of months ago. Is that out there you had a lot of libraries so it's just frameworks and frameworks just call code. Uh, your agents leave inside their abstractions. Um, and I don't like analogies with you know operating system. Okay, everyone has used that analogy but okay, let's say a kernel like runs processes and your agent kind of is a process. It doesn't matter what it does actually. Uh, but the system can schedule it cuz built to isolate it. It can isolate it and journals it with the log. And the agent definition so the markdown is user land. Like you don't need to use it with that system if you don't want to. Actually you have a front end that doesn't use this markdown. Uh, this markdown format at all. And Okay, here's a very important point and you know, that's kind of a takeaway and it's also what justifies me working on this because disclaimer structured outputs is our special team. We've been working on this for 3 years and it just ended up being a big dog fooding project and the reason why I did this at the beginning was not because I absolutely wanted to use our software. I didn't necessarily want to you know, fork LMCBP to other software etc. It's just because Intropic was terrible at structured outputs and so like 20% of my events were wrong and were rejected by the system. So that's why I ended up doing this. And the goal you know, the job of the kernel is actually to make bad actions impossible not just unlikely and so you have these two boundaries with the between agents and the external world. The first one is type tool calls the two tool calls. You don't want to you know, you don't want to call tools that don't exist etc. etc. And also the boundary of other agents which is type events and this is non-negotiable I found. Like you can get a lot of errors just from this. Uh, I wrote a really long blog post about this. Uh, it's if you follow the QR code, you'll find it. And yeah. And the result of that is actually deployed uh within the company after I built this. And now today after a month of deploying it, we have 20 agents on the left that are not just contributed by technical people, by the way, uh which is kind of what Markdown what Markdown gives you. And then on the right is, you know, we deploy it's called the intranet. There's the briefs, there's a bunch of I mean, there's a bunch of things as you can as you can see. Kind of like a few, you know, as a conclusion, a few lessons. Uh, the first one is that well-executed background agents are really magical. Uh, they feel like this, you know, robot mower that I had at the beginning is I really just sit down and I come back and I have this morning brief that is probably even better than what I would have had just doing it manually. And it just appears in my inbox every day and processes my, you know, random thoughts. Uh, the difficulties that you meet during this kind of thing is just good old engineering problems. I mean, there's really nothing new under the sun when it comes to orchestrating these things. It's just good old software orchestration. Uh, open-source models are there. Uh, they're good enough. I replaced so I don't have any third-party APIs anymore. Now I just use open-source models. And even on my laptop, I use uh local model. Uh, so it's good enough for what I do with it. For coding, I don't know, but for what I do with this, it's good enough. The infra category is definitely unsettled. Uh, I tried a few things before I started building myself. And I would advise that today like definitely start building before you buy. Uh, so if you're a small company, if you're a tech CEO, it's kind of an advantage because you can just do this without, you know, tasking engineers to do this and get them off track. But I would definitely try to build before I buy just to know exactly what I need and, you know, the limitations of what exist. Also, I will say that to people building frameworks for this is please eat your own dog food. Sometimes it's pretty clear that people building you know, agent orchestration frameworks etc. but not eating their own dog food so please do. And the other thing is I'm really glad I took these two weeks off to play with the field because that completely changed the I mean that changed the trajectory of the company. I know we're in the AI company we should be in it etc. about you know, business is such that you're always thinking about the next thing, the next thing, the next thing and it's the same everywhere but what I'm urging you to do is to stop and actually immerse yourself in this and try to see how useful it can be for your company. So, you can steal the code. It's not a product that we sell and we don't intend to sell this. You can read our blog as well. So, I haven't explained this yet but I will publish something about it and thank you for your attention.