AI Engineer World's Fair 2026
Agent Frameworks Considered Harmful — Rémi Louf, .txt
Read the talk
From a Morning Brief to an Agent Runtime
Rémi Louf’s effort to automate a repetitive morning workflow became an argument for small, event-driven agents backed by durable logs, content-addressed prompts, queues, and typed boundaries.
From a talk by Rémi Louf
At a glance
Ideas worth remembering
Useful autonomy begins when agents react to schedules and causal events without requiring continuous supervision through a terminal or phone.
Event subscriptions can replace manually maintained graph edges for simple workflows, provided the runtime makes event contracts, history, and causal relationships observable.
Duplicate actions, lost inputs, and unexplained regressions require ordinary production machinery: attempt-aware queues, append-only logs, and immutable configuration history.
Content-addressing each prompt component makes submitted model context reconstructable, structurally diffable, and replayable with another model, while still leaving provider-internal reasoning unobserved.
A kernel-like runtime can leave agent internals flexible while enforcing typed tool calls and typed inter-agent events at the boundaries where malformed behavior would otherwise propagate.
Louf’s reported deployment reached 20 agents and nontechnical contributors, but the recording supports this only as one company’s experience rather than a general performance result.
Building a small workflow before purchasing infrastructure can expose real requirements, while operating it in daily work reveals failure modes that demonstrations and abstractions conceal.
The goal: work that continues without supervision
Rémi Louf frames the talk as the story of a two-week experiment. After perceiving a sharp improvement in agent capability, he stepped away from leading the 15-person company .txt to investigate what agents could reliably do and which primitives they actually required.
His target experience resembled the robot mower outside his office: it operates in the background without a person continuously steering it. His mornings contained repeatable information work—reading market news, reviewing issue trackers and the CRM, walking for an hour while recording a long voice note, and later processing that note. He wanted the resulting briefing waiting with his coffee.
Terminal agents could perform both coding and noncoding work, but the user still had to remain at the controls. Phone-based apps improved mobility without providing real autonomy: Louf found himself directing agents during his walk and correcting their trajectory from a remote interface. He regarded this as a transitional design—more independent than a ride-on mower, but still demanding attention—so he began building the smallest background system that might work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move agent definitions out of application code
Louf first tried existing frameworks and found himself repeatedly editing prompts embedded in code. He instead made agent definitions declarative files: a contributor could write one, place it in a folder, and let the runtime discover it. This preserved familiar software practices such as versioning, diffs, and pull-request review while removing code changes from routine agent authoring. The simplicity was an interface choice; the runtime underneath could remain more complicated.
The first trigger was conventional scheduling. A market-watching agent ran each morning while he walked, using a cron-like schedule to say when it should start. Agents also published events after completing work. At this early stage, declarative definitions plus schedules and events were nearly the whole product, and Louf says the prototype mostly worked—an important qualification that the subsequent failures would unpack.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cron answers when; events preserve why
A schedule handles work that begins at a known time, but it cannot naturally express work that begins because something happened. Dropping a voice note into the system should immediately emit an event; the same pattern applies to a new email, CRM entry, opened pull request, or merged pull request. This converts causal changes into triggers instead of repeatedly polling them on an arbitrary clock.
The voice-note processor declared the event type it accepted and the event type it returned. It consumed a voice note, transcribed and converted it into durable notes, then emitted a processed-note event through structured output. A daily-brief agent combined scheduled market output with the processed note, produced a brief, and emitted another event consumed by a Slack-message process. The resulting chain performed the morning workflow without Louf manually shepherding each step.
Louf argues that this case does not require a hand-authored execution graph. Each agent subscribes to named events, so there are no explicit edges to maintain: adding or editing a subscriber changes the effective topology. The event log records what actually happened, while the set of subscriptions determines what may happen next. This lowers the contribution barrier, but it also means that understanding the system depends on good event naming, discovery, and observability rather than on inspecting a single static graph.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Three failures reveal the missing runtime
The initial implementation took roughly a day with coding-agent assistance, then failed under use. One daily brief appeared in Slack twice, one voice note vanished completely, and a week of unversioned prompt edits left the market brief unusable without revealing which change caused the regression. These were ordinary distributed-systems and configuration-management failures appearing inside an agent product.
Each incident supplied a runtime requirement. The missing note motivated a permanent log so inputs and transitions could be recovered. Duplicate posting exposed retries that were neither queued properly nor counted as attempts, calling for a real queue with explicit attempt tracking. The untraceable prompt regression led to the deepest addition: content-addressed storage, analogous in principle to systems that identify immutable content by its hash. Louf presents these mechanisms as debt paid in response to concrete errors, not as an architecture designed in advance.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An append-only, causally linked system memory
The event log became the runtime’s memory. Events were appended rather than overwritten, queryable after the fact, and linked to the events that triggered them. That causal relation lets an operator follow a chain from an input through intermediate agents to an external action. Louf reports that even three or four interacting agents created serious debugging difficulty, making this journal useful well before the system became large.
An event trace still does not fully explain a model response unless the runtime also records the model’s actual request. A displayed chat is not necessarily the complete context sent to a model: compaction can replace earlier material, and providers do not expose every internal reasoning trace. Louf therefore separates two limits. The runtime can preserve and reconstruct its submitted context, but it cannot claim complete access to the provider’s hidden internal computation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Represent prompts as immutable components
Louf applies the structure of a build system to prompts. A request is assembled from components such as the system prompt, individual skill descriptions, tool definitions, and the user message. Each component is stored separately and identified by a content hash. Before rendering the final text, the runtime represents the prompt as an ordered list of those hashes; the model response is stored in the same content-addressed system and linked back to that prompt.
This representation makes the submitted context auditable and turns operations that are awkward on rendered strings into graph operations. Louf says it simplifies compaction and indirectly helps key-value cache management because unchanged components retain stable identities. Its central benefit, however, is narrower and stronger: the operator can identify the exact stored components associated with a run. That explains the runtime’s input, though not every hidden reason for the model’s output.
Stable component identities also produce structural diffs. Comparing two runs can show that their system instructions, skills, and tools stayed constant while the user message or later session messages changed. This is more diagnostic than comparing two large rendered prompts because it identifies which semantic unit changed and which units were reused.
Replay follows from the same design. After observability exposed rapidly rising model costs, Louf wanted to evaluate open-source models against previous requests. Because the graph retained every prompt component, the runtime could rebuild a request, send the same stored input to another model, or deliberately replace selected components. This supports controlled comparisons, although model nondeterminism means rebuilding an identical request does not guarantee an identical answer. The capabilities are not literally free: the content store, graph, reconstruction, and replay machinery must first be implemented.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A kernel-like runtime with typed boundaries
Louf distinguishes his runtime from a framework whose abstractions contain the agent itself. His kernel analogy places the agent in the role of a process: the runtime need not prescribe the process’s internal behavior, but it can schedule and isolate it and journal its activity alongside its definition. Markdown is therefore one supported authoring interface rather than the kernel’s essential representation; another front end can define agents differently while relying on the same runtime services.
The crucial safety mechanism is structured data at both runtime boundaries. Louf’s company had worked on structured outputs for three years, and this project became an internal use of that specialty. He reports that, before strengthening this layer, about 20 percent of generated events were malformed and rejected. The figure is his own observation rather than an independently verified benchmark, but it explains why loose natural-language handoffs were unacceptable for this workload.
His design goal is to make invalid actions impossible at the boundary, not merely less likely. Typed tool calls constrain interactions with the external world so an agent cannot validly request a nonexistent tool or malformed operation. Typed events constrain interactions among agents so producers and consumers agree on a machine-checkable contract. Types do not prove that a semantically valid action is wise, but they eliminate a broad class of routing and shape errors before those errors propagate.
Louf then deployed the system inside .txt. After about a month, he reports 20 agents in operation, with some definitions contributed by nontechnical colleagues through the declarative format. Their outputs appeared through an internal interface containing briefs and other workflows. These numbers demonstrate adoption within his company, but the recording does not provide independent reliability measurements or evidence that the same design will fit every organization.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the experiment changed
Well-executed background agents finally produced the unattended experience Louf originally wanted. He could return from a walk to a daily brief in his inbox, with his recorded thoughts already processed, and judged the result at least as useful as doing the work manually. Yet he emphasizes that the hard parts were familiar engineering concerns: orchestration, queues, retries, logs, isolation, and contracts—not a fundamentally new category of infrastructure.
For these particular noncoding workflows, Louf says open-source models became sufficient and replaced his third-party model APIs, including use of a local model on his laptop. He explicitly limits that judgment to what he was doing and does not claim the same adequacy for coding or every agent task. Content-addressed replay made this substitution testable against stored requests instead of forcing a decision from isolated demonstrations.
He considers the agent-infrastructure market unsettled and advises small technical organizations to build an initial end-to-end workflow before buying a platform. The purpose is discovery: operating even a small system reveals the organization’s actual needs and the limitations of available products. This is not an argument that every company should maintain a custom runtime indefinitely; it is an argument that firsthand implementation can produce a better purchasing specification.
Louf also asks framework builders to operate their own systems in real work, because failures such as duplicates, disappearance, malformed events, and prompt drift emerge through use. More broadly, the two-week immersion changed his company’s trajectory. His closing recommendation is to interrupt the normal sequence of short-term business demands long enough to learn, through direct use, where background agents genuinely help. He says the code is available but is not a product the company sells or intends to sell, points listeners toward further writing, and closes the talk.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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