AI Engineer World's Fair 2026
Agent Frameworks Considered Harmful — Rémi Louf, .txt
Read the talk
Agent Frameworks Considered Harmful
Rémi Louf’s attempt to get a morning brief waiting with his coffee became an event-driven runtime. Lost notes, duplicate messages, and prompt regressions explain why background agents need queues, causal logs, reconstructable context, and typed handoffs.
From a talk by Rémi Louf
At a glance
Ideas worth remembering
Schedules trigger work at a time; events trigger work because something happened. The morning brief combines both.
Background agents need ordinary operational machinery: attempt-aware queues for retries and an append-only, causally linked log for investigation.
Content-addressed prompt components make stored requests reconstructable, diffable, and replayable against another model.
A runtime can leave agent authoring flexible while checking typed tool calls and typed events where work crosses between components.
Build and operate a small workflow before choosing infrastructure: real use exposes requirements that an attractive abstraction can hide.
A morning without a remote control
The robot mower outside Rémi Louf’s office had the working arrangement he wanted: it did its job in the background without someone steering it. His own morning required reading market news, reviewing Linear and the CRM, taking an hour-long walk, and then processing the long voice note recorded along the way. The desired result was modest and concrete—a morning briefing waiting with his coffee.
After noticing a sharp improvement in agent capability, Louf took two weeks away from running the 15-person company .txt to explore that workflow. The question was what agents could actually do unattended, and which pieces of infrastructure they needed. The title is deliberately provocative; the experiment begins with a personal chore rather than a general indictment of every framework.
Terminal agents already handled useful coding and noncoding tasks. But using them resembled sitting on a self-driving tractor mower: the machine performed the work while the operator remained at the controls. Phone apps loosened that attachment without removing it. During his walk, Louf found himself sending instructions and correcting agents’ trajectories instead of thinking. Mobility had moved the remote control into his pocket.
That frustration led him to start coding, with an aside about hoping his board would not hear about it. He aimed for the smallest thing that could work. The resulting Zeta runtime would grow through failures discovered in daily use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move the prompt out of application code
The first irritation with existing frameworks was where routine changes happened. Editing an agent’s instructions meant editing prompts inside code. Moving agent definitions into Markdown files made the everyday task smaller: write a file, drop it in a folder, and let the runtime discover it. The files could still be versioned, compared, and reviewed in a pull request.
The market-watching agent needed to run every morning while Louf walked, so its first trigger was a conventional cron schedule. A schedule specified when work began; agents also published events. Markdown and cron formed a simple authoring interface, even though the machinery underneath was more complicated. At this point, it mostly worked. The meaning of “mostly” would arrive shortly.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cron says when; an event says what happened
A voice note does not arrive at a predetermined time. Its arrival is the reason processing should begin. Dropping a note into the system therefore emits an event that wakes a subscriber. New emails, CRM entries, and opened or merged pull requests can use the same mechanism. Scheduling remains useful for the market watch; events handle work triggered by changes.
Follow the morning voice note through that change. Previously, the recording left an hour of processing for Louf after his walk. In the new workflow, the voice-note agent declares the event it accepts and the event it returns. It receives the recording, transcribes it, turns the transcript into persistent notes, and uses structured output to emit a processed-note event. The recording has become an input another agent can use without Louf issuing another instruction.
The daily-brief agent combines those notes with the scheduled market output and creates the brief. It then emits a Slack-post event. A separate process subscribes to that event and sends the message. The model’s information work and the external delivery action are separate steps, connected through an explicit handoff.
How do the scheduled market report and the unscheduled recording meet? The diagram shows their convergence on the daily brief, followed by a subscriber that delivers it. The arrows explain the flow; contributors do not maintain those arrows as a separate execution graph.
Subscriptions determine the connections. Several agents can consume one event, and an agent can use outputs from several producers: fan-out and fan-in follow from the event model. Adding an agent means declaring what it consumes and produces rather than wiring a new set of graph edges in code. That lowers the authoring barrier, while making knowledge of the system’s event types essential.
Runs each morning and publishes its output.
Scheduled market work and a newly submitted voice note feed the brief. A delivery process consumes the resulting Slack-post event.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Duplicates, disappearance, and prompt drift
The first implementation took about a day with Codex’s help. Then operation exposed three distinct failures: the daily brief appeared in Slack twice on the first day, a voice note vanished on Wednesday, and unversioned prompt edits made the market brief useless by the end of the week. Louf could no longer remember which edit caused the regression.
Each failure called for a different piece of ordinary software infrastructure:
- Duplicate delivery → an attempt-aware queue. Several attempts had occurred without proper tracking or counting. The runtime needed a real queue and a count of attempts.
- Lost recording → a permanent event log. Inputs and transitions needed to remain available so an operator could investigate what happened.
- Untraceable regression → content-addressed prompts. The system needed to preserve the components used in a run, rather than depend on someone remembering a week of edits.
The queue addresses execution attempts; the log addresses history. Keeping those jobs distinct matters: remembering that two messages were sent does not itself prevent a second send. The recording explains why attempt tracking was added, without specifying an exactly-once delivery protocol.
The log became one append-only events table. New events extend the history, and causal links record which event triggered which subsequent event. For the voice-note workflow, that relationship lets debugging follow the input toward processing, briefing, and delivery, rather than inspect an undifferentiated list of messages. The history is queryable, and Louf found it valuable with only three or four agents—well before the system became large.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Store the components the model actually received
An event history answers what ran and what triggered it. It still leaves another question: what request produced this model response? A displayed chat can conceal changes to the submitted context, particularly when compaction replaces earlier conversation material. Louf wanted to reconstruct the request instead of inferring it from the chat interface. That reconstruction covers stored, submitted context; it does not reveal a provider’s hidden internal reasoning.
The solution borrows from build systems. Store the system prompt, each skill description, tool definitions, and the user message separately. Identify each component by a hash of its content. Before rendering text for the model, represent the prompt as a list of those hashes. Store the model answer in the same content-addressed system and connect it back to its prompt.
What must remain available to reconstruct an old request? The diagram follows stored components into a prompt and then a response. The component identities preserve the ingredients, while the prompt list preserves their arrangement. Following the response back to that list identifies which stored instructions, skills, tools, and question belonged to the run.
This design also resolves an apparent tension in the talk. The workflow does not require contributors to maintain an execution graph, but prompt storage deliberately uses a graph of references. Those are different jobs: subscriptions route work among agents; content references preserve the material assembled for a model request. Louf says manipulating that graph simplifies compaction and indirectly helps KV-cache management. The main developed benefit is being able to inspect a run’s inputs.
Two practical operations follow from the stored structure:
- Diff runs. Compare component identities to locate changes in instructions, skills, tools, or messages. In the example described during the talk, three components remain identical, the user message changes, and additional messages continue the session. The comparison separates reused context from changed and added material.
- Replay requests. Resolve the stored references and rebuild a previous request. Send it again, select another model, or deliberately alter part of the input. Reproducing the request supplies a controlled starting point for comparison; it does not promise the same answer.
Replay became useful when observability made rising costs visible. Louf wanted to evaluate open-source models on the requests his agents had already handled: were their answers satisfactory, and would prompts need to change? Rebuilding those requests made the comparison possible using actual work. The benefits arrive after implementing the content store and reconstruction machinery; even Louf’s description of getting them for free comes with that qualification.
System instructions, individual skills, tool definitions, and user message.
Hashes identify separately stored components. A prompt records their arrangement, and the stored response links back to that prompt.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A kernel that checks the handoffs
The runtime’s responsibilities now resemble those of a kernel: schedule an agent, isolate it, and journal its activity. The agent resembles a process whose internal task can vary. Markdown belongs to the authoring layer, so it need not define the runtime itself. Louf already had another front end that did not use the Markdown format. This separates a convenient way to write agents from the services required to operate them.
Structured outputs became essential at the handoffs. .txt had worked on them for three years, and the runtime became a substantial internal use of that expertise. Louf reports that roughly 20 percent of his generated events were malformed and rejected when using Anthropic in this workflow. That is a workload-specific observation, and it explains the decision to strengthen event generation rather than rely on loose text passing between agents.
Two boundaries need machine-checkable structure:
- Typed tool calls connect agents to external actions. A call must refer to an available tool and fit the permitted interface. The runtime should exclude requests such as calling a tool that does not exist.
- Typed events connect agents to each other. Producers must return an event shape consumers can accept. A malformed handoff should be prevented or rejected before it becomes the next agent’s input.
Louf describes the goal as making bad actions impossible at these boundaries. Its useful scope is structural: a valid tool call or well-formed event can still contain a poor decision. Types remove classes of interface errors; they do not establish that the brief is insightful or that an otherwise permitted action is wise.
After a month of company deployment, the system had 20 agents, including contributions from nontechnical colleagues. Briefs and other outputs appeared in an internal interface called the intranet. The file-based authoring decision had a visible organizational effect: extending the system no longer belonged exclusively to people who wrote application code.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Operate a small workflow before choosing infrastructure
The morning example finally reaches its intended result. Louf returns from his walk to a brief in his inbox, with his recorded thoughts already processed. He judges it probably better than the version he would have assembled manually. The improvement he values is the unattended experience: the work appears without a sequence of phone instructions.
The difficult parts turned out to be familiar orchestration problems. Queues track attempts, logs preserve events, causal links explain propagation, and stored prompt components explain input changes. The model supplies useful work inside that machinery; capability alone had not supplied the machinery.
For these noncoding tasks, open-source models became sufficient. Louf says he replaced his third-party model APIs and also uses a local model on his laptop. He explicitly leaves coding outside that judgment. The earlier replay mechanism supplies a practical way to consider such a substitution: rebuild requests from the existing workload and assess whether the alternative produces satisfactory results.
His purchasing advice follows from that experience: build before buying, especially when a small company has a technical leader who can explore without pulling engineers away from their planned work. Operating an initial workflow reveals what the organization needs and where available infrastructure falls short. This recommendation comes from his experience of an unsettled category, rather than a claim that every framework has the same deficiencies.
Framework builders receive the corresponding request: use the systems in daily work. Duplicate delivery, disappearing inputs, and malformed events become hard to overlook when they interrupt your own morning. Louf credits the two-week immersion with changing his company’s trajectory and urges leaders to interrupt the constant pursuit of the next business task long enough to learn what agents can do for their company.
The closing invitation is to take the code and learn from it. This runtime is not a product .txt sells or intends to sell. It is the result of trying to make a useful workflow work every morning.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explore the code behind the talk’s event-driven agents. The repository documentation includes an inbox-summarizer example, event schemas, queue inspection, and prompt tracing.
Further reading
A practical guide to inspecting stored prompts, comparing their components, rebuilding requests, and comparing model responses.
The .txt structured-output library provides a concrete place to explore constrained generation and reliable machine-readable handoffs.
Related talks
- No more bad outputs with structured generation
Louf’s earlier talk explains how constraints mask invalid token continuations before sampling, developing the generation mechanism behind structured handoffs.
- 12-Factor Agents: Patterns of reliable LLM applications
Continue with another treatment of reliability patterns for LLM applications after the queue, log, and request-reconstruction examples here.
Read the complete timestamped transcript
- 0:12
Hi everyone. So originally I thought I was going to give a very technical talk but I saw I was in the
- 0:17
leadership track which I'm not sure what it means but I was like okay I'm gonna do half high level
- 0:23
and half technical. So it's more a story about what I you know what I did in January because in around
- 0:32
December agents kind of became really good you know there was a step function something happened
- 0:38
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
- 0:45
is really happening and so I took two weeks out I took two weeks away so I'm the CEO of dot text
- 0:51
which is 15 people company I just told my CTO I was like okay I'm just gonna go away for two weeks
- 0:56
and I'm just gonna dive in this thing and try to understand what we can get out of it and how good
- 1:02
it is and so the story is you know it is the story of me scratching my own edge for two weeks and trying
- 1:08
to figure out how we can use actually use agents and what are good primitives to build agents and whether
- 1:15
you know it already exists. This was a really clickbait title but actually it turns out to be a good title even
- 1:22
for this talk. So what you can see here on the left of castle is my office that's true I do rent an office in that
- 1:32
castle and the small thing with an arrow that you can see is like this robot mower which kind of works unattended
- 1:40
all day every day it just does its stuff and the background without anyone having to use a remote
- 1:47
control or think about it or anything and I kind of wanted the same thing for my morning because my
- 1:55
mornings are always the same thing the first couple hours it's browse market news review of like linear
- 2:00
could be Jira's my CRM and also I like to walk for about an hour in the morning and then the next hour is
- 2:08
I spent trying to process the really long voice note that you know was recorded while walking and you
- 2:14
know all I wanted was my morning briefing with my coffee and that's kind of what we've been told for
- 2:23
couple of years like what the future would be but then when you really start working with it even if you're
- 2:31
not coding all you get is a TUI today so it's amazing you can code you can actually
- 2:38
you know I started doing things that were not coding in it they're great for this agents are great
- 2:43
for this but it's kind of the equivalent of having a robot like a tractor mower that you still have to
- 2:50
stay on even if it's driving by itself right it's kind of very frustrating because you have to it can do
- 2:55
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
- 3:03
which I call basically SSH with vibes that's great but in this situation when that came up I was like
- 3:11
well that's awesome I don't have to use like a term like SSH on my phone anymore codex is great
- 3:17
however I noticed I just started you know and I was on my walk and I was just instructing the agent to
- 3:22
do things while I was walking and so I wasn't thinking you know very clearly anymore I just started running
- 3:27
agents on my phone during my morning walk and this is not great because this is the equivalent of this
- 3:33
is you're kind of midway you know it's not the tractor that you have to stay on it can actually do
- 3:38
something without you being right next to it but you still have this remote control that you know you
- 3:43
kind of have to change the trajectory every now and then that's useful it's kind of absurd when you
- 3:49
think about it and actually when you look at people like on their phone all the time just doing this
- 3:54
is kind of absurd and it's clearly transitional like surely we're not it's not it's not going to stop
- 3:59
there and so I did a very dumb thing as a CEO which is I started coding don't tell my board and I started
- 4:09
to build the dumbest thing that could possibly work and of course it became a really a crazy rabbit hole
- 4:16
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
- 4:25
is that you know I started using frameworks I mean they're great frameworks I'm not going to name any
- 4:31
frameworks because they're all good in their own way and they will have flows in their own way which is fine
- 4:37
but I spent all my time actually editing the prompt within the code and I was like this is actually not
- 4:42
very useful so I'm like everyone here I hate YAML like the next guy but I still found that this was actually a lot
- 4:50
easier to start implementing agents without code you can version it you can def it you can review in the
- 4:57
PR but it's just and it's just so easy you can just you know write your file you drop it in a folder
- 5:04
and then it just magically appears once you have the runtime and it just magically works
- 5:11
and you know then I needed like my market watch to run every morning while I'm you know while I'm walking in
- 5:18
the fields and for that we have things that you know have been around for a while which is cron jobs
- 5:26
and schedules specify you know when the agents need to be run and also we'll see it's very important later
- 5:33
they publish they publish events and you know markdown and cron obviously you know it's much more
- 5:42
complicated than that under the hood but the interface is this you don't write code and that's the whole
- 5:47
product so far and honestly just mostly worked at this point I'll come back on mostly uh later and
- 5:55
so this is actually a real picture of my one of my morning walks and so what I do is I record voice
- 6:02
notes while I'm walking uh but cron you know cron jobs I mean people would use cron jobs for this
- 6:08
because that's what's available in codex today but they're not ideal because they cover when but this is
- 6:14
just one point in time it doesn't cover because this happened and you know things that happened in our
- 6:21
system like automatically when you drop the voice note now in the system it will emit an event and an
- 6:29
agent will react to that event and it's the same thing when you have a new email a new entry in the crm
- 6:34
I mean anything a new pr that's open a new pr that's merged etc just reacts to events it's not just a cron job
- 6:40
and that and that means that you know agents of the voice note processor it's just you know not a cron job but here you have
- 6:49
accepts and returns so it just declare what it accepts and what it returns as an event and here it accepts a voice note
- 6:57
transcribes it turn it into durable notes on the right and it emits a new event and for that I use the structured outputs
- 7:04
we'll come back to this and you know now we finally have the future we're promised because that voice note
- 7:13
agent emits voice note processed and then I have my daily brief agent that actually will take the output
- 7:19
of the cron job we'll take the output of the voice note agents and we create my daily brief which is posted
- 7:26
as a slack message so the slack message dot post event is actually uh is actually like a process actually
- 7:35
subscribes to this and emits uh and sends a slack message to me it's actually this is a real this is
- 7:42
a real thing it's working I can show you after on my phone and you know there are frameworks that are
- 7:50
going to sell you the fact that you need graphs for this and code you do not need graph in this case
- 7:56
all you need is events you have no edges to maintain agents simply subscribe to events anyone can come in
- 8:04
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
- 8:09
exist in the system finding and found out are free no code and it's just drop a file and the topology
- 8:15
emerges whatever the log says happened and you know then of course I I tried to run it so the first version
- 8:26
took about I mean you know I cheated I cheated I used uh I used codex and it took about like a day to
- 8:33
write like the first thing uh out of my week but of course I tried it and it broke uh so these are real
- 8:41
examples actually the dates know but it's real examples it's like the first day daily brief was posted
- 8:46
to slack twice um on Wednesday one of my voice notes completely vanished and then you know towards the end
- 8:54
the week I I kind of like played with the prompts all week and the market brief was garbage but I didn't
- 9:00
version uh I didn't version my changes and I couldn't remember actually what I changed in the prompt that
- 9:06
made the thing completely useless now if there are distributed or ex-distributed engineers in the room
- 9:15
you probably know this shopping list already there is nothing new under the sun
- 9:21
and you know each failure so each of these failure modes that you found actually led to building one
- 9:30
piece of what turned out to be a runtime so the last note actually turned into a log I just wanted
- 9:37
everything to be saved forever so that I could go back to it and look into uh into what happened the
- 9:44
duplicates it was because I was not following you know it did several attempts and I was not following
- 9:49
them I didn't have a proper queue I wasn't counting the attempts etc etc and then probably the most
- 9:56
interesting part is the last prompt I got into a really deep rabbit hole in there and I just ended up
- 10:02
building a content like a content address system for this content address system you can think of git
- 10:09
you can think of next and any other build system and you know that was and I didn't do this because I
- 10:16
wanted to design a runtime I mean by that point I still just wanted my agents to work and I also like the
- 10:23
distraction and I just paid off debt as it appeared like errors as they appeared I hope my board won't see
- 10:32
this talk so the log the log is the system's memory nothing is lost and everything is observed
- 10:41
uh you can you know you only have one append on the events table on the left it's a real common line uh
- 10:48
it's like command zeta events and you get all the events they are totally linked as well like you know
- 10:55
which event triggered which event which happens to be super useful when you're debugging and you know even
- 11:03
with three four agents you start having like major debugging headaches so that was super super helpful
- 11:12
and everything is queryable which again for debugging the second thing is you know okay we have a log so
- 11:20
we can trace back things etc but it's still really hard to know what went into the like what went to the
- 11:28
model what prompt was sent to the model again because what you see when you're using codex it's kind of a lie
- 11:34
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
- 11:40
model saw and you know that's exactly so i can understand what happened the truth is that's not
- 11:46
exactly what the model saw um there are many reasons for that one is i mean compaction obviously is a big
- 11:52
problem is a big thing but also you know there are just quirks also you know open ai doesn't share or
- 11:57
anthropic for that matter don't share the thinking with you the thinking traces so you have no idea
- 12:01
i mean kind of have an idea of what went in but not completely either and so you need something different
- 12:07
uh you need something different and that was the big rabbit hole which is trying to find a way to build
- 12:15
a system where you can trace back to what the model saw internally and so what i did was basically built
- 12:22
i mean nothing new this is basically a build system works so you have different parts for a prompt you'll
- 12:29
have your system prompt you'll have a description of your first skill of a second skill then you have the
- 12:34
description of your tools you'll have your user message which is the question of the model each one
- 12:39
of those is stored and addressed and you know stored somewhere as a identifier which is a hash and so when
- 12:47
we build a prompt instead of building a piece of i mean before rendering the text we actually represent the
- 12:53
prompt as a list of these of these hashes and so what that means is that down the line when i have a model answer
- 13:04
which by the way is also stored in the same way we can trace back to the prompt very easily and then from
- 13:09
that prompt we can know exactly what went into the model's context which actually matters a lot i mean it
- 13:15
matters a lot for debugging but it also matters i mean it makes compaction a lot easier you're just
- 13:21
manipulating a graph right you're not manipulating strings it's just a lot easier and it makes kv cache
- 13:27
management a lot easier as well indirectly and but i think that when you know i guess probably
- 13:36
the main advantage that's when you use that skill is really auditability it's like you can know exactly
- 13:42
what happened with that agent and why it returned what it returned and so you know i'm just going to go
- 13:50
pretty pretty quickly over this uh what you get once you have this graph is you get diffs like you can say
- 13:58
okay what changed between these two runs like which components changed was it just my message did i like
- 14:05
give the model a different skill did i give it a different tool so you can just yeah you can just run this
- 14:10
function and it will show you you know the difference between the runs so here you have you know three
- 14:17
components that were identical there's one which is you know the user message changed and then you had
- 14:23
all these other messages that were actually you know that were continuing it's continuation of a single
- 14:28
session uh then you have another thing for free which is replace uh replace turned out to be really
- 14:34
useful for me because after a while i mean when i saw the cost ramp up like the thing when you have
- 14:42
observability is that you do realize that coast increase very quickly i wanted to try with open
- 14:47
source models and so i wanted to rebuild all the requests for to eval and see if i got the same thing
- 14:53
out if i got something satisfactory if i need to change anything and turns out that once you have
- 15:00
you know this content addressing system you can rebuild the request from the graph and you can just replay
- 15:05
it exactly the same and you can you know resend you can use a different model you can use a different
- 15:11
request if you want you can you can change it and so yeah you get actually a lot of things i mean for
- 15:18
free you need to implement the thing um and so this is kind of different um from what you find i mean
- 15:25
what i found when i started doing this it might be different today because it was a couple of months ago
- 15:30
is that out there you had a lot of libraries so it's just frameworks and frameworks just call code
- 15:34
uh your agents leave inside their abstractions um and i don't like analogies with you know operating
- 15:43
system okay everyone has used that analogy but okay let's say a kernel like runs processes and your agent
- 15:49
kind of is a process it doesn't matter what it does actually uh but the system can schedule it because
- 15:55
built to isolate it it can isolate it and journals it with the log and the agent definition so the markdown
- 16:01
is use the land like you don't need to use it with that system if you don't want to actually have a
- 16:05
front end that doesn't use this markdown uh this markdown format at all and okay here's a very important
- 16:12
point and you know that's kind of a takeaway and it's also what justifies me working on this because
- 16:17
disclaimer structured outputs is our specialty we've been working on this for three years and it just ended up
- 16:23
being a big dog fooding project and the reason why i did this at the beginning was not because i
- 16:29
absolutely wanted to use our software i didn't necessarily want to you know fork lamma cpp to other
- 16:36
software etc it's just because anthropic was terrible at structured outputs and so like 20 percent of my
- 16:41
events were wrong and were rejected by the system so that's why i ended up doing this and the goal you
- 16:47
know the job of the kernel is actually to make bad actions impossible not just unlikely and so you have
- 16:53
these two boundaries with between agents and the external world the first one is type tool calls the two
- 16:59
tool calls you don't want to you know you don't want to call tools that don't exist etc etc and also
- 17:05
the boundary of other agents which is type events and this is non-negotiable i found like you can get a
- 17:10
lot of errors just from this uh i wrote a really long blog post about this uh it's if you follow the qr
- 17:16
code you'll find it and yeah and the result of that is actually deployed it uh within the company after i built
- 17:25
this and now today after a month of deploying it we have 20 agents on the left that are not just contributed
- 17:31
by technical people by the way which is kind of what markdown uh what margon gives you and then on the
- 17:37
right is you know we deploy it's called the intranet there's the briefs there's a bunch of i mean there's
- 17:42
a bunch of things as you can as you can see kind of like a few you know as a conclusion a few lessons
- 17:49
uh the first one is that well executed background agents are really magical they feel like this you
- 17:56
know robot more that i had at the beginning is i really just sit down when i come back and have this
- 18:01
morning brief that is probably even better than what i would have had just doing it manually and it just
- 18:07
appears in my inbox every day and processes my you know random thoughts uh the difficulties that you meet
- 18:14
doing this kind of thing it's just good old engineering problems i mean there's really nothing new
- 18:19
under the sun when it comes to orchestrating these things it's just good old software and orchestration
- 18:25
open source models are there they're good enough i replaced so i don't have any third-party apis anymore
- 18:31
now i just use open source models and even on my laptop i use a local model so it's good enough for
- 18:38
what i do with it of coding i don't know for what i do with this it's good enough the info category is
- 18:45
definitely unsettled i tried a few things before i started building myself and i would advise that
- 18:51
today like definitely start building before you buy so if you're a small company if you're a tech CEO
- 18:58
it's kind of an advantage because you can just do this with uh you know tasking engineers to do this and
- 19:04
get them off track but i would definitely try to build before i buy just to know exactly what i need
- 19:10
and you know the limitations of what exists uh also i will say that to people building uh
- 19:18
frameworks for this is please eat your own dog food sometimes it's pretty clear that people are building
- 19:24
you know agent orchestration frameworks etc but not eating their own dog food so please do
- 19:29
and the other thing is i'm really glad i took this two weeks off to play with the field because that
- 19:33
completely changed i mean that changed the trajectory of the company i know we're an AI company
- 19:38
we should be in it etc but you know business is such that you're always thinking about the next
- 19:43
thing the next thing the next thing and it's the same everywhere but what i'm urging you to do is to
- 19:47
stop and actually immerse yourself in this and try to see how useful it can be for your company
- 19:55
so you can still the code it's not a product that we sell and we don't intend to sell this
- 20:01
you can read our blog as well so i haven't explained this yet but i will publish something about it
- 20:07
and thank you for your attention
- 20:11
you