# Agent Frameworks Considered Harmful Rémi Louf, .txt | AI Engineer | 20:29 Source: https://www.youtube.com/watch?v=KHudyx5wW3U Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/agent-frameworks-considered-harmful Published: 2026-08-22 Tags: agents, observability, structured-outputs, workflows ## TL;DR - Background agents can run from events and produce a daily brief without requiring someone to stay at a terminal or phone. - An append-only, causally linked event log fixes lost events, duplicate attempts, and debugging problems. - Content-addressed prompts make model inputs reproducible, diffable, auditable, and replayable against other models. ## Summary Rémi Louf describes taking two weeks away from running .txt to build a background-agent system for his own morning routine. The system processes market news, CRM and project updates, voice notes, and other events, then posts a daily brief to Slack. He started with markdown agent definitions and cron jobs, but failures quickly exposed the need for a runtime. The runtime keeps an append-only event log with causal links, counts queue attempts, and stores every prompt component by content hash. This lets him inspect exactly what a model saw, compare two runs, and replay an old request with another model. Louf argues that agents need a small kernel with scheduling, isolation, journaling, typed tool calls, and typed events. He is candid that the work was driven by ordinary engineering failures, including malformed structured outputs. After deploying the system, .txt had 20 agents, including agents contributed by non-technical staff. His advice is to build before buying an agent framework and to use the product internally before selling it. ## Key ideas ### Two weeks of building revealed a useful background-agent model [00:01](https://www.youtube.com/watch?v=KHudyx5wW3U&t=1s) Louf took two weeks away from his role as CEO of .txt, a 15-person company, to test what agents could do. He wanted a morning briefing that gathered market news, Linear or Jira updates, CRM information, and a long voice note recorded during his walk. Existing tools still required him to sit at a terminal or keep directing an agent from his phone. He wanted the equivalent of his unattended robot mower: a system that ran in the background and delivered the result without constant remote control. ### Markdown made agent definitions easy to edit and review [04:30](https://www.youtube.com/watch?v=KHudyx5wW3U&t=270s) Louf found himself spending more time editing prompts inside application code than using the framework around them. He disliked YAML, but still preferred a no-code file format to prompts embedded in code. Agents became markdown files that could be versioned, diffed, and reviewed in a pull request. Once a file was dropped into a folder, it appeared in the runtime. This also allowed people who did not write code to add agents, as long as they understood which events existed in the system. ### Events describe why an agent runs better than schedules alone [06:11](https://www.youtube.com/watch?v=KHudyx5wW3U&t=371s) Cron jobs specify when an agent runs, but they do not express what caused the work. In Louf's system, dropping a voice note emits an event, as does receiving an email, adding a CRM entry, or opening or merging a pull request. A voice-note agent accepts a voice note, transcribes it into durable notes, and emits a new event. A daily-brief agent consumes that output along with scheduled market information, then emits a Slack message event. Agents subscribe to events, so there are no graph edges to maintain and fan-out does not require extra topology work. ### Failures in the first week became runtime requirements [08:44](https://www.youtube.com/watch?v=KHudyx5wW3U&t=524s) The first version failed in ordinary ways. The daily brief appeared in Slack twice, a voice note vanished, and prompt edits made the market brief useless. Louf had not versioned those edits and could not remember what changed. Each failure led to a runtime feature. Lost data required an append-only log. Duplicate work required a real queue that counted attempts. Untraceable prompt changes led to content addressing. He describes this as paying down problems as they appeared rather than starting with a plan to design a runtime. ### The event log preserves data and causal history [09:37](https://www.youtube.com/watch?v=KHudyx5wW3U&t=577s) Louf's log is the system's memory. It uses one append-only events table, where events are saved rather than discarded and each event records which earlier event triggered it. The events are queryable, which helps when several agents create a debugging chain. The causal links matter even with only three or four agents, because it otherwise becomes difficult to explain how a particular result was produced. The log also makes queue behavior visible, including the attempts that led to duplicate or failed work. ### Content-addressed prompts expose exactly what the model received [12:11](https://www.youtube.com/watch?v=KHudyx5wW3U&t=731s) A live coding-agent session does not necessarily show the full model input. Compaction changes the context, and providers do not share all of their reasoning traces. Louf stores each prompt component separately, including the system prompt, skill descriptions, tool descriptions, and user message. Each component receives a hash, and a prompt is represented as a list of those hashes before it is rendered as text. A model answer is stored the same way, so a result can be traced back to the exact context that produced it. ### Prompt graphs make diffs and replays practical [13:03](https://www.youtube.com/watch?v=KHudyx5wW3U&t=783s) Once prompt components are content-addressed, Louf can compare two runs and see which components changed. The difference might be only the user message, or it might be a skill or tool definition. The system can also rebuild an old request from the graph and send it to a different model. Louf used this to evaluate open-source models after seeing costs rise. The same representation also makes compaction easier because the system manipulates a graph of components instead of opaque strings. ### The runtime is a small kernel with typed boundaries [15:32](https://www.youtube.com/watch?v=KHudyx5wW3U&t=932s) Louf compares the runtime to a kernel that runs and isolates processes, journals them, and schedules them. The agent definition is user land, so another front end could replace the markdown format. Two typed boundaries constrain interactions with the outside world. Typed tool calls prevent agents from calling tools that do not exist, while typed events constrain communication between agents. Louf says this became non-negotiable after about 20% of his events were malformed and rejected by the system. The kernel's job is to make bad actions impossible rather than merely unlikely. ### Building first exposed what the company actually needed [18:05](https://www.youtube.com/watch?v=KHudyx5wW3U&t=1085s) After deployment, .txt had 20 agents, including contributions from people who were not technical. Louf says background agents can feel like the robot mower he described, producing a morning brief that includes his random thoughts without requiring manual processing. The problems were familiar software orchestration problems, while open-source models were good enough for this workload, including on his laptop. He recommends building before buying so a team understands its needs and the limits of available products. He also asks framework builders to use their own systems internally. ## Notable quotes - "I started to build the dumbest thing that could possibly work." (03:50) - "The log is the system's memory. Nothing is lost and everything is observed." (10:35) - "The job of the kernel is actually to make bad actions impossible, not just unlikely." (16:40) - "I would definitely try to build before I buy just to know exactly what I need and the limitations of what exist." (18:57) ## Tools & references mentioned - .txt - Opus 4.6 - Slack - Linear - Jira - CRM - Codex - Git - Nix - OpenAI - Anthropic ## Who should watch - You are building background agents that need to run without someone watching a terminal or phone. - Your agent workflows lose events, repeat work, or make it difficult to reconstruct what a model actually saw. - You are considering buying an orchestration framework and want to understand the runtime features you may need first.