← All AI Engineer talks

AI Engineer World's Fair 2025

Beyond Conversation: Why Documents Transform Natural Language into Code

Filip Kozera· Founder and CEO, Wordware10:57

Read the talk

From Chat to Documents to Background Agents

Repeatable work needs more than a conversation: it needs a clear assignment, a trigger, and a way for people to review results without supervising every step.

From a talk by Filip Kozera

When one precise edit becomes another conversation

You have been working in Claude or an OpenAI chat, copying material into projects and assembling a workflow by hand. Now you want to change one sentence in an artifact. The conversation keeps growing, but the instructions that matter are increasingly mixed with abandoned ideas and irrelevant exchanges. This is the opening problem Filip Kozera, co-founder and CEO of Wordware, identifies: the conversation is ephemeral, while the work needs a stable specification.

The difficulty is not just remembering what was said. It is deciding what should still count. A long conversation accumulates context without providing a clean way to revise the current assignment. Kozera also wants the system to force clarity: ChatGPT may ask what a deep research request should investigate, yet ordinary interaction does not reliably surface the uncertainties that need an answer before work proceeds.

Several other limitations follow from using the conversation as the working document:

  • Version control and reuse: A useful workflow is hard to preserve, compare, and run again when it lives across exchanges and copied text.
  • Response quality: Kozera reports getting worse responses as his context grows, describing the behavior as model laziness.
  • Organization: Chat offers little support for logical grouping or nesting of an assignment.
  • Abstraction: The interface gives the user one interaction layer, rather than an explicit choice between specifying every small detail and setting a task at a higher level.

Together, these problems make structured iteration difficult even when individual responses are useful.

Slide beside the speaker lists context pollution, lack of structured iteration, no forced clarity, poor version control, limited reusability, model laziness, no hierarchical organization, and a single abstraction level.
Eight limitations of chat-based systems.
0:000:19
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:00 · section reference included

A document makes the assignment explicit

Documents already serve a familiar purpose: explaining a complex system to someone who does not know how to build it. Kozera jokes that Noah’s Ark had the first product requirements document roughly 3,500 years ago, immediately adding, “don't check me on that one.” The useful comparison is the act of specifying a system for another party, not the historical dating.

A document turns an evolving conversation into an explicit assignment. Writing it requires the author to decide what the system should do and communicate that coherently. That is the forced clarity missing from a stream of conversational revisions: another person—or an agent—must be able to understand the intended system from the specification.

2:082:25
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:08 · section reference included

The next limit is the user’s attention

Even a clear conversation can keep the user sitting at the interface. Kozera calls this interaction pattern concurrency of one: work advances through the conversation the person is currently attending to. He points to Manus and deep research as early departures from that pattern, with work continuing after the user steps away. The appeal is that something useful is happening without another prompt.

Computers have, of course, done background work for years. The change is how much judgment a workflow can exercise. Kozera moves from handcrafted automation, exemplified by Zapier, to specialized agents whose contribution might initially resemble a fuzzy if/else making one or two decisions.

ApproachHow work is directedPlace in Kozera’s comparison
Handcrafted workflowExplicitly arranged stepsFrequent, important tasks
Specialized agentA few judgment-based decisionsBounded decision-making
General agentBroader discretionEmerging use, with limits on important work

His task diagram places occurrence on the vertical axis and importance on the horizontal axis. When both are high, organizations have reason to invest in handcrafted workflows. General agents are beginning to make decisions, but Kozera observes that users remain reluctant to admit them into higher-importance work.

TASKS diagram plots occurrence vertically and importance horizontally, with regions labeled specialized, general, and hand-crafted, plus opposing diagonal arrows labeled VALUE and MARKET SIZE.
Tasks mapped by occurrence and importance.
2:523:13
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:52 · section reference included

Let the agent prepare work, then review it

A human in the loop gives an agent room to work without handing it unrestricted control over the outcome. The reviewer can approve or reject the work, change the output, or repair the logic that produced it. Those are different interventions: editing one result resolves the immediate problem, while changing the logic addresses how subsequent work will be done.

The agent can start from explicit or implicit user intent. Sending an email, sending a Slack message, or attending a meeting can provide the activating event. Kozera’s concrete example is a meeting with investors: recognizing the kind of meeting could prompt an update to the CRM. The event supplies the occasion for work; interpreting its meaning supplies the proposed task. A meeting having occurred does not, by itself, establish that a CRM update has been executed.

4:204:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:20 · section reference included

From a personal assistant to an organizational network

Multiple ambient agents create a communication problem. People need to control their agents and inspect their outputs, while agents need to exchange information about available data. One agent might ask a more general agent what is in Notion rather than independently acquiring all of that context. Protocols become the means of coordinating those relationships.

The same pattern can expand from an individual’s agents to an organization’s internal and external agents. Even the apparently dramatic idea of agents managing humans has a mundane example: an agent creates Jira tickets for engineers. It is assigning work through an existing organizational interface. These relationships form what Kozera calls the enterprise’s future graph.

His adoption forecast starts with prosumers delegating tasks such as email management to recover time. Enterprise adoption then follows more slowly, because tools must be verified and agents must have the right authority and permissions. The personal convenience of background work becomes an organizational question about who may use which tools, on whose behalf, and with what consequences.

5:075:31
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:07 · section reference included

Accept uncertainty while bounding its consequences

Delegating to probabilistic systems requires a different attitude toward uncertainty. Kozera asks whether business value can justify using a system whose behavior is not fully understood. In Kozera’s hypothetical client-closing example, a system delivers business value 99.9% of the time; the remaining 0.1% must not have catastrophic consequences. The percentages illustrate a risk argument, not measured Wordware reliability: useful outcomes do not remove the need to limit the damage of failures.

Humans remain responsible for their agents’ actions. Managing several agents therefore includes expressing taste, intent, and personal brand in their assignments. An agent acting on someone’s behalf needs more than a task description; its behavior should reflect how that person wants the work done.

Kozera identifies the Model Context Protocol (MCP) as an initial step, while asking for richer communication of agent constraints, delegated authority, and approval requirements. The historical distinction matters: the March 2025 specification already included optional transport authorization, and its tools specification recommended human confirmation and the ability to deny invocations. His broader concern is how to represent and enforce an agent’s organizational mandate, beyond access to a tool connection.

6:436:57
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:43 · section reference included

Coding makes the management skill visible

Coding provides Kozera’s early example of humans managing agents. He sees particular benefit for engineers who combine strong individual-contributor skills with the ability to manage a team of interns. They can both understand the work and direct someone else through it.

An excellent individual contributor may still find AI-generated code disappointing. Kozera suggests that expectations about quality and optimization can make delegation unattractive to someone who would prefer to do the work directly. Extracting organizational benefit from a swarm of agents demands a separate skill: setting assignments, judging results, and managing the work rather than personally producing every detail.

7:598:21
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:59 · section reference included

Put a trusted, repeatable process into the background

Chat still has a role: brainstorming. The transition comes when the exploratory conversation has produced a process worth repeating. Documenting and triggering an agent is for repeatable work, not a requirement for every exchange. Kozera’s progression is straightforward:

  1. Use the conversation to explore what the work should involve.
  2. Write a document explaining the agent’s assignment.
  3. Establish that the process is useful and trustworthy enough to repeat.
  4. Connect it to a trigger so it can start without another conversation.

The trigger might be a cron job, a Gmail event, or an implicit signal of user intent.

For the investor-meeting example, a compact assignment could make the intended work and review boundary explicit:

markdown

# Investor meeting follow-up

When a completed meeting is identified as an investor meeting,
prepare a proposed CRM update from the meeting information.

Keep the proposal concise and factual.
Ask for clarification when the information is insufficient.
Request human approval before applying the update.

The document specifies recurring behavior; the trigger determines when to invoke it. Background execution also changes the interaction budget: latency matters somewhat less when the user is not waiting at the chat window. The agent should surface an issue when it struggles or needs approval.

The person’s work shifts toward writing assignments that express their taste and reviewing the resulting work. As confidence grows, that review becomes the main interaction with a collection of background agents. Kozera’s memorable analogy is Tinder-style swiping left or right: approving, rejecting, or editing results rather than continuously prompting each agent through its task.

8:589:11
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:58 · section reference included

Where enterprise value may accumulate

Kozera closes with a forecast: wider prosumer adoption will precede a gradual move into enterprises, where organizations build tools that the newest models can use. In that future, the durable advantage belongs to the enterprise’s tools—its capacity to let agents perform valuable work—even as the models improve.

He predicts that enterprise tools will be “the moat,” before qualifying the forecast with “Let's see if it's true.” He positions Wordware as enabling these background agents. The proposed destination is a working relationship in which documents define assignments, agents perform recurring work, and people retain responsibility for deciding which results should become actions.

10:1710:40
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:17 · section reference included

Resources

From the talk

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    Hi, I'm Filip, and I'm the CEO at Wordware. Today, I want to talk to you about what sucks about chat-based interfaces, how documents can actually solve those issues, and how do they lead to, um, background agents that do tasks for you in the, uh, or in the background.

  2. 0:19

    So firstly, let's start with what are the problems with chat-based systems? When I interact with, um, Claude or OpenAI, it all seems very ephemeral. Um, I end up often creating workflows for myself using projects or just copy-pasting stuff.

  3. 0:36

    And in that way, when I'm kind of having these long conversations that I populate the context window, I realize that a lot of these, uh, things in the context window are just like

  4. 0:48

    gibberish and garbage, and so we get context pollution. I also don't get to iterate in a structured manner. If I'm working with artifacts, it ends up that I basically make the context window dirty enough with not being able to, you know, change one sentence that I really want, wanted to make sure that it's precise.

  5. 1:10

    I also sometimes lack another level of forced clarity. ChatGPT often asks me that one particular question around, "Oh, in deep research, what would you like to actually find?" But it never actually asks me in the right way when it's not actually certain about some things, and therefore not forcing me to clarity.

  6. 1:35

    Also, there's a couple more issues about poor version con-control, limited reusability, model laziness. The more the context grows, the less, uh, you know, the, the worse response I'm getting.

  7. 1:50

    Also, chat interfaces don't support any logical grouping or nesting, um, in any way. And we also are interacting with a single abstraction layer. We don't get to see and choose whether we want to specify every small detail of a particular task or just set it up in some way.

  8. 2:08

    Hence documents. Documents are actually the original way of specifying more complex systems. The first, um, product requirements doc that dates, uh, probably to Noah's Ark around three and a half thousand years ago.

  9. 2:25

    Uh, don't check me on that one, however. Uh, and, um, it's the first kind of take, um, on someone explaining a more complex system, uh, to somebody who is not aware of how to build it.

  10. 2:40

    Um, and therefore, um, documents are actually the ultimate way of humans communicating these more complex ideas. And so in that way, we get forced clarity, uh, which is great.

  11. 2:52

    But next problem with chat, and one of the biggest problems with chat is, um, concurrency. Um, we have concurrency of one with all chat-based systems. We need to be sitting there, and we are getting like the, um, inklings of how the future will look like when, um, Manus or Deep Research, uh, are running in the background and

  12. 3:13

    actually, you know, doing things for us. It feels great. It feels great that there's something in the background that's happening.

  13. 3:20

    So now, you know, let's riff off this idea of the background, um, agents that I'm gonna introduce. So we've been doing work and s- computers have been doing work for us, uh, in the background for quite a while.

  14. 3:35

    And, you know, we've kind of created workflows which are kind of handcrafted. You can think of the Zapier of this world. And then we're just barely starting to create specialized, um, agents.

  15. 3:47

    That basically means that at some stage, it k- kind of had an if/else statement that was somewhat fuzzy and it made one or two decisions. And as we can see on this diagram, when the importance of some workflow is high and the occurrence is high, we actually end up using handcrafted workflows.

  16. 4:06

    We're only now entering an area where the general agents, um, are starting to take some decisions, but whenever we have kind of higher importance, we don't let that general agent to, um, kind of enter our life.

  17. 4:20

    So how can we remedy this? Um, we remedy this by introducing a human in the loop. Um, so essentially now, uh, with the human in the loop, the agent can do a bunch of work and we get to approve, reject it, change the way that it's created the end output, or even fix its logic entirely.

  18. 4:42

    Um, they normally react to some kind of implicit or explicit user intent or trigger. So you can think of, of these background agents as being activated by a sent email, sent Slack message, maybe your meeting.

  19. 4:56

    That could be an implicit trigger that you had a meeting with a name, um, party and that party with investors, and that could prompt you to update your CRM.

  20. 5:07

    And with having a bunch of these ambient agents, you end up cr- having to create protocols of how humans and the AIs communicate between themselves. And that basically means that, you know, both humans can control their agents and its outputs, but also different agents can communicate with each other to educate themselves around, you know, sources of

  21. 5:31

    data. An agent, one agent could be communicating with a more general agent around what is in your Notion. And in that way, we'll probably start with a prosumer first, where a bunch of agents are working in the background, but very soon that starts to be about an organization.

  22. 5:49

    And we'll start having organizations which have their own agents and also external agents. And in that way, we might even get agents which manage other humans, which sounds ridiculous at the beginning, but actually, you know, that could be just an agent which creates Jira tickets for all of your engineers.

  23. 6:07

    And in that way, we basically create the graph of the enterprise of the future. I think when I think about these background agents, firstly, kind of working for the prosumer, maybe managing your emails and just making sure that you have more time for yourself.

  24. 6:23

    I think this idea like so naturally represents a bottom-up movement to enterprises, which will be more slow-moving and trying to make sure that all of their agentic tools that these agents need to be using are verified and have the right authority, and they have the right permissions, and they don't mess things up.

  25. 6:43

    So as I am thinking about the future of the agent economy, I think that the stochastic mindset of, like, we need to adopt that because we essentially need to lead with leverage over uncen-uncertainty.

  26. 6:57

    If something that you don't fully get how it works closes you clients and delivers on business value, um, ninety-nine point nine percent of the time, we not gonna care about the fact that we don't understand what's happening in that zero point one percent of the time.

  27. 7:12

    We're just gonna make sure that the impact of the zero point one percent of the time is not catastrophic. Um,

  28. 7:21

    I also think humans will manage a bunch of agents, and that's why taste and intent is so important. Um, you will need to imbue your own personal brand onto agents and take responsibility for their actions.

  29. 7:34

    We'll also need a lot more communication protocols between humans and AI, and also in between agents. The MCP is a first protocol that kind of sets it up, but I think it l-lacks more information about what are the constraints of a particular agent, what are the authority that it needs to, uh, have in order to act, whether

  30. 7:54

    it needs approval from human in the loop, et cetera. Um,

  31. 7:59

    right now, when I think about like kind of humans managing agents, we only see this properly in coding. And in coding, we basically see people who are good engineers, who are good both at IC work and at managing a team of interns really, really, really being able to take the benefit of the AI revolution.

  32. 8:21

    Um, a lot of excellent IC engineers end up saying, "Oh, I d- I don't want to use AI. It's, um, it's actually not that good as people are saying."

  33. 8:31

    And it probably isn't for them, but their bar for, uh, code might be too high. They want-- might want to have everything optimized in the right manner. And in this way, you know, this is the first time where, um, engineers are kind of managing the swarm of agents, and they need to be good at managing in order

  34. 8:50

    to actually distill, um, leverage and distill benefit for their organization.

  35. 8:58

    Um, so just to, just to wrap up, um, I think the concurrence of one of chat-based systems and the pollution you get for playing with them, it almost is like brainstorming.

  36. 9:11

    But after brainstorming, you need to sit down and create a right document to explain what an agent should be doing. This is only needed for repeatable processes. Once you have a repeatable process that you trust and you think will be very useful, you can hook, hook it up to a trigger.

  37. 9:28

    That can be either, you know, a cron job, or it could be, uh, a Gmail trigger, or it could be an implicit trigger. Then that agent is then able to act in the background.

  38. 9:39

    The latency matters a little bit less there and only surface issues to you once it is struggling with something or needs your approval. Therefore, your work is mostly around creating these assignments for the, um, for the agents, making sure that your taste is imbued there, and then approving the results of the work, making sure you trust it

  39. 10:01

    more and more and more as you keep going. In that way, we are creating swarms of agents which are working in the background, and our main job is to swipe left and right as if it's Tinder and approve and edit the results of the work of the agents.

  40. 10:17

    I think from there, the prosumer, um, market is gonna adopt this much more widely, and we're gonna see, um, it slowly entering the enterprise market. And I'm super excited about the enterprises creating most incredible tools, uh, that are gonna be agentic, and they are gonna be used by the state-of-the-art newest models, but the tools are gonna be

  41. 10:40

    the moat. So a very clear progression, uh, for the future. Let's see if it's true. Thank you so much. I'm Filip, the co-founder and CEO of Wordware, and at Wordware, we actually enable these background agents to work.

  42. 10:55

    Come build yours.