AI Engineer Europe 2026
Agents need more than a chat
Read the talk
Agents need more than a chat
When agents can produce complex work cheaply, the hard part becomes steering and reviewing it. Persistent documents and tables put human judgment where the work happens.
From a talk by Jacob Lauritzen
Fix clause three. What happened to clause four?
Ask an agent to research a matter, draft a contract and make no mistakes. It starts reading, launches subagents, searches the web and writes files. Then it launches more subagents, reads more material and writes more files. In Jacob Lauritzen’s opening example, the contract arrives after thirty minutes—and clause three looks wrong. You ask it to check another document and correct the clause.
The agent replies, “You're absolutely right.” Then comes compaction. Lauritzen presents this as the moment the user loses confidence that the agent will retain the context it needs. Another round of work produces another contract, but now the question is larger than whether clause three is correct: did anything else change? The slide makes the concern concrete with a follow-up question about clause four. A targeted correction has become another whole-document review.
Lauritzen introduces himself as CTO of Legora, a collaborative AI workspace for law firms. Lauritzen reports more than a thousand customer organizations across more than fifty markets. He describes substantial fundraising and rapid growth; the suggestion that it might be the fastest in history is something he says he has been told. He also invites engineers to join the London team. The product objective behind that growth is the same one facing other vertical AI companies: enable agents to complete increasingly complex work end to end.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cheap execution moves the bottleneck
Lauritzen describes a shift over the preceding six to twelve months: doing the work has become cheap enough that planning and reviewing it increasingly dominate the effort. Someone still has to specify the desired result, establish the non-functional requirements and inspect what comes back. A large GitHub pull request captures the problem: generating a substantial change can be easier than understanding whether it is right. Asking an agent to review its own work may help, but Lauritzen leaves its reliability open.
The verifier’s rule, attributed in the talk to Jason Wei, offers a way to reason about this bottleneck. Lauritzen summarizes it as: if a task is solvable and easy to verify, AI will solve it. For foundation models, useful verification enables reinforcement-learning environments and post-training. He extends the idea to agents: run the task, identify what is wrong, provide corrective feedback and repeat. His expectation is that the agent will eventually get there; the rule itself does not establish a solution-time or convergence guarantee for such a loop.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A vertical contains many kinds of verification
Verification difficulty varies within an industry, not just between industries. Legal work makes the distinction particularly visible. Checking contract definitions is straightforward to perform and inspect. Producing contract language is also easy for an agent, but establishing whether that language will achieve its intended legal effect is much harder. Lauritzen’s strong framing is that the ultimate test comes when the contract reaches court and a judge interprets it.
Litigation strategy is harder still in his account. Ask five lawyers how to pursue or defend a case and they may give different answers; there may be no single objective answer against which to score the agent. Coding has the same variation: a bounded implementation task can be readily checked, while building a successful consumer application depends on an outcome that is difficult to verify in advance.
| Task | Verification problem |
|---|---|
| Check contract definitions | Inspect whether defined and used terms agree |
| Draft a contract | Assess whether language achieves its intended effect |
| Choose litigation strategy | Judge competing approaches without one agreed answer |
| Build a successful consumer app | Establish success beyond implementation correctness |
The practical unit of analysis is the task, rather than the label “legal” or “coding.”
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Control determines steering; trust determines review
The goal is to involve humans where their judgment matters and let agents handle work that can safely be delegated. Two dimensions determine how that collaboration should operate:
- Control: How effectively can a person put their knowledge into the agent’s work and steer its decisions?
- Trust: How much of the work does that person need to review? With low trust, they may inspect every trace; with high trust, they may inspect little or nothing.
These are distinct questions. A user can need strong control over a strategic choice while trusting the agent to carry out the resulting mechanical work. Which intervention matters depends on the task’s position on the solvability and verifiability spectrum.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the agent something it can check
One way to increase trust is to make the task more verifiable. For feature implementation, browser access and test-driven development give the agent ways to inspect behavior and test whether its work meets requirements. Lauritzen mentions analogous opportunities in finance, then returns to contracts. When direct verification is unavailable, previous successful contracts can serve as reference examples: compare the new draft with these golden contracts. Similarity is a verification proxy, not proof that the new language is legally correct.
Decomposition creates further opportunities. Instead of delegating “write a contract” as one undifferentiated task, separate the decisions that require judgment from the operations that admit clearer checks:
- Human judgment: Choose the risk profile, precedent documents and negotiation stance.
- Agent execution: Apply formatting consistent with existing contracts and check definitions.
Definition checking is essentially linting. Are all defined terms used? Is every used term defined? Those questions provide a much tighter feedback loop than asking whether the entire contract is good.
For an implementation sketch, once defined terms and term uses have been extracted, the two checks are simple set differences:
typescript
function lintDefinitions(
definedTerms: readonly string[],
usedTerms: readonly string[],
) {
const defined = new Set(definedTerms);
const used = new Set(usedTerms);
return {
unusedDefinitions: [...defined].filter(term => !used.has(term)),
undefinedTerms: [...used].filter(term => !defined.has(term)),
};
}
const findings = lintDefinitions(
["Agreement", "Effective Date", "Services"],
["Agreement", "Services", "Business Day"],
);
// unusedDefinitions: ["Effective Date"]
// undefinedTerms: ["Business Day"]
This isolates a checkable subtask; extracting and interpreting the terms remains a separate concern. The agent can receive specific findings to fix while the human retains the contract’s strategic choices.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Trust can also come from limiting scope
Guardrails increase trust by reducing the set of actions the agent can take. Lauritzen’s examples are concrete: edit only three specified files, read only designated contents of a directory, or search only approved websites. The user has less to worry about because the agent’s scope is smaller.
Claude Code illustrates the extremes. At one end, the agent asks permission for every action, making useful progress cumbersome. At the other, the user bypasses permission checks and lets it run—the slide shows --dangerously-skip-permissions, accompanied by Lauritzen’s warning about deleting a production database. The engineering distinction is between requesting a restriction and enforcing it: current Claude Code guidance treats permissions as harness controls, not something a prompt can change. That documentation describes the current product rather than the historical version on the slide.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Planning only reaches the work it can anticipate
To understand control, model a complex agent task as a tree of work—or, more generally, a directed acyclic graph. Lauritzen’s example is a report on employment contracts. The agent first researches the organization, then reviews several aspects of each contract, then drafts the report. If the human can intervene only at the root, they issue a request and wait for all the downstream work to finish before supplying more judgment. That recreates the opening contract problem at a larger scale.
Planning improves this arrangement by aligning on the approach before execution. The human can approve the steps, identify the clauses to inspect and specify review criteria. This gives the agent more direction than a broad request for a finished report.
But knowing enough to produce a complete plan may require doing much of the task already. A long planning exchange can ask many questions without establishing that all the necessary information has been collected. An unusual clause in one employment contract may not become visible until the agent reads that contract; neither side can settle its treatment in advance without discovering it first.
The collaboration resembles a coworker who agrees on an approach and then disappears until the final document is ready. Upfront alignment helps, but there is no opportunity to respond to discoveries along the way. Lauritzen therefore predicts that planning will not remain the dominant collaboration method. The limitation is the distance between the moment judgment is supplied and the moment it is needed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put judgment at the point of discovery
Skills place reusable human judgment at individual nodes of the work graph. Instead of describing the entire report in advance, a person can specify how confidentiality reviews should be conducted. A termination-review skill can also contain guidance for a special EU-law case. When that contingency appears during execution, the relevant instruction is already available.
Lauritzen calls out progressive discovery: the agent picks up relevant guidance as work unfolds. This handles situations that were not enumerated in the initial plan, but only when suitable guidance exists. There will not be a skill for everything.
For uncovered cases, the next mechanism is elicitation: ask the human about the particular uncertainty encountered during the task. The question arrives with a concrete problem, rather than demanding that the user anticipate every possible problem before work begins.
Lauritzen recommends avoiding unnecessary blocking by combining elicitation with a decision log:
- When uncertain, make a provisional decision.
- Record that decision in the log and continue working.
- Let the human review the log afterward and reverse decisions where necessary.
The decision has been used to continue the work, but it has not thereby received human approval. Keeping it visible and reversible is what makes later intervention possible.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Review decisions inside the artifact
Now imagine the work graph becoming ten or a hundred times larger. A chat containing fifty questions is not necessarily an effective way to obtain fifty useful answers. Each question needs the context of the contract, clause or decision it concerns. A linear conversation flattens that branching structure into a stream the user must reconstruct.
Humans and agents should collaborate in persistent artifacts that expose the work in context. The right artifact depends on the industry and task. For legal drafting, a document is a natural workspace. In Lauritzen’s example, the user highlights clause three and the agent changes only that clause. The scope of the interaction is attached to the relevant part of the document, addressing the ambiguity that made the opening revision so frustrating.
The document also supports comments, tags for agents and human collaborators, and handoffs of particular portions to specialist agents. These interactions preserve where the instruction applies instead of forcing the user to describe that location repeatedly in chat.
For the employment-contract report, Legora’s alternative is a tabular review, a familiar primitive for its users. The agent sets up the review, examines the contracts and flags selected items that need a human’s take. The user can quickly locate the problems, supply judgment in place and see what work the agent has already done. After reviewing those items, the user starts the remaining agent work. The table supports both control over specific decisions and inspection of the broader result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep chat as input, not the whole workspace
Lauritzen points to PostHog and Linear as examples of interfaces converging around chat. He describes their changes as recent launches; the exact two-week window is approximate. Chat boxes remain useful because they accept flexible instructions. The problem is making that same input mechanism the main mode of collaboration throughout a complex task.
Language is a broadly useful interface, and voice can make it even easier to give instructions. But an agent does not have to answer only in the form in which it was addressed.
Shortly before the talk, Lauritzen had been describing Legora’s organizational chart to a potential candidate. In that conversation, he had to explain the structure verbally. What he wanted was an org chart the candidate could see, interact with and use. An agent can produce such a representation as part of the interaction. There is no reason to make it inherit the limits of a spoken conversation when a document, table or interactive chart gives the user a more direct way to understand and shape the work.
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
Jason Wei explains why reliable, inexpensive verification can accelerate AI training and iterative problem solving.
Further reading
A practical introduction to packaging procedural knowledge in skills and loading instructions progressively.
- Introducing Linear AgentArticle
Linear's launch announcement shows agents operating through workspace chat, comments, skills and automations.
Updates since the talk
Current guidance for configuring tool approvals, access restrictions and permission modes.
Read the complete timestamped transcript
- 0:00
[upbeat music] How is everyone doing?
- 0:17
Still good? Woo. Great. It's, uh, 5:00 PM on a Friday. There's just me and two more people behind you and Friday beer, so I'll try to be a little bit quick here.
- 0:27
I'm here to talk to you guys today about vertical AI and, and complex agents, and why I think they need more than just the chat. If you've ever worked with a long-running complex agent, you've probably tried something like this.
- 0:41
Sorry that it's all white. I can see the flashback in your guys' face. [laughing] Um, you tell it to research something, draft a contract, make no mistakes, and, um, it starts thinking, it starts reading, launches a bunch of sub-agents, does web search, writes files, launches more sub-agents, does more reading, writes more files.
- 1:00
Keeps going, takes forever. After thirty minutes, it gives you your contract. You take a look. Clause three doesn't look right. What-- Did you make a mistake here? Could you, you know, look at another document?
- 1:15
You're absolutely right. [laughing] Then you see this, compaction. That's when you know you can give up. It's gonna forget everything. It's in the, the, the context rod state. Anyway, it continues, it keeps on going, and, uh, you get a new contract.
- 1:31
Does it look-- Was it only clause three that was changed? Probably not. And so you end up in this state.
- 1:38
Not the greatest experience. My name's Jacob. I'm the CTO of Legora. We are a collaborative AI workspace for law firms, so we're a vertical AI company. We have more than a thousand customers, more than fifty markets.
- 1:51
We've raised a bunch of money. Uh, we're growing extremely fast. Um, I'm being told maybe the fastest in history. Um, we are also hiring engineers in London, so in case anyone's interested and wants to be on this growth journey, please talk to me after my talk.
- 2:08
Um, our goal and the goal of most vertical AI companies is to make agents complete more and more complex work end-to-end.
- 2:18
That's-- Sort of doing that has changed a lot in the past six to twelve months because there are new economics of production. So it used to be if you wanted to complete end-to-end work, that you would be focused on doing the work, right?
- 2:33
That would be sort of the main thing is actually just getting it done. But today, things look a little bit different, 'cause right now, planning work and reviewing work is the new bottleneck.
- 2:46
So doing the actual work is extremely cheap. It's very easy to do. But now you have to spend time planning, you have to get the non-functional requirements, you have to get the specs, and you have to spend a lot of time reviewing the work.
- 2:58
And if anyone's reviewed big PRs on GitHub, it really sucks. It's extremely painful. Um, maybe if you're super AI-pilled, you just get your AI agents to review their own work, no humans involved.
- 3:10
Maybe it works, maybe it doesn't. And when we think about completing complex work, both the planning stage, the doing stage, and the reviewing stage, the verifier's rule is a good way to think about work.
- 3:24
So verifier's rule is, uh, a term that was coined by Jason, which states that if it's-- a task is solvable and it's easy to verify, then it's gonna get solved by AI.
- 3:35
He was primarily talking about foundational models, so sort of if you can make something very easy to verify, then you can do RL environments, you can post-train, it's gonna solve it.
- 3:45
I think it also goes for agents. You know, if you can make a task verifiable, you can just run an agent in a loop and tell it, "Hey, you did this wrong.
- 3:52
Please fix it," and it'll eventually get there.
- 3:56
Different industries are in different places in this spectrum. Um, it's a little bit more complex than just this because verticals have tasks that are at different places on the spectrum.
- 4:07
So if you take legal, we can check definitions in a contract. Super easy to verify, super easy to get done. Writing a contract is very easy to solve, but actually extremely difficult to verify.
- 4:18
'Cause if you think about it, when you write a contract, the only time you can actually verify if, you know, the language you use works is if it goes to court and a judge basically verifies it, tells you if it's good or not.
- 4:28
So that's actually quite complex. Litigation strategy is also basically impossible to verify. If you don't know what litigation is, it's when you sue someone or someone sues you. I know we're in Europe now, but the Americans really love doing this all the time.
- 4:43
Um, but essentially, if you ask five lawyers what should be the right strategy for this litigation case, they're gonna give you different answers. And so there's no objective truth, which means it's basically impossible to verify, and it's really difficult for AI to solve.
- 4:58
Similarly on coding, some parts are really easy. Building a successful consumer app, very difficult to verify.
- 5:05
So when we think about this, um, we think about how to involve humans where it really matters and let agents do the work that we can let them do.
- 5:14
There's two things that are important, um, to think about with agent-human collaboration. Control is the first one. Control is how effectively can a human instill their knowledge into the work that the agent is doing?
- 5:27
So how effectively can I steer it? Control is a matter of how much do I need to review. So if I have very low control, I'm gonna look at every single agent trace and see exactly what it did.
- 5:37
If I have very-- uh, sorry, low trust. If I have very high trust, I won't look at it at all.
- 5:45
Depending on where the task falls in sort of the, the chart, different things are important.
- 5:51
How to increase trust. So if you wanna increase trust, there's a few different things you can do. Firstly, you can bring a task down in the spectrum. So here's an example from coding.
- 6:01
If you wanna implement a feature, well, you can give it browser access, you can do test-driven development, and then suddenly it's actually a verifiable task, and it's gonna do much better.
- 6:10
There are similar things you can do in finance, and in legal, um, you can do something similar as well. We don't have-- Let's take the contract example in legal.
- 6:19
You can't really verify it, but you can look for a proxy for verification. So for contracts, what you can do is you can take a look at previous contracts.
- 6:26
These are our golden contracts. We know they work well. Let's set up a test. Is it the new contract? Is it similar to the old one? That's sort of a proxy for verification that's gonna allow your agent to do a much better job.
- 6:38
You can also decompose tasks. So here's the example with writing a contract. I can turn that from one task into a bunch of other tasks, and I can leave picking risk profile, picking the precedent documents, the negotiation stance, I can leave that to the human, but I can try to get other stuff down where it's easy to
- 6:55
verify. So apply formatting, make it look like all my other contracts. Apply checking definition, which is essentially linting. Are all definitions used? Are all the definitions that are used defined?
- 7:06
This kind of stuff you can build, and then the agent can basically rip much better.
- 7:13
You can also add guardrails. And guardrails is essentially the way to gain trust by limiting what the agent can do. So instead of being able to do all of this, you're just gonna say, "You can only do these.
- 7:22
You can only edit these three files. You can only read these from this directory. You can only search these websites." By limiting what it can do, you basically get more trust 'cause you know that it won't do all these weird things.
- 7:35
An example of this, you probably all know this one, Claude Code. If there's very low trust, it's gonna basically tell you every single time it wants to do anything, which makes it extremely useless.
- 7:44
Uh, and on the high trust end of the spectrum, you just YOLO mode it, let it rip, and hope that it doesn't delete your prod database.
- 7:53
Then there's control. So how do we increase control? Well, if you think about complex agent work, you can kind of think about it as a tree of work, as a DAG, essentially.
- 8:05
So here's an example where I wanted to write a report on a, a bunch of employment contracts. So the agent's gonna say, "Okay, let me research the organization first.
- 8:14
Then I want to review the contracts, and I'm gonna review for a few different things for each of the contracts. And then I'm gonna draft a report at the end."
- 8:23
This is extremely low control because essentially, I can only impose my judgment at the root level. So it's gonna do all of this work, and then it's gonna get back to me, and then I can try to talk to it again, and this was basically the example I gave at the beginning.
- 8:36
So very low control. Then there's planning. Planning essentially allows you to steer the agent up front and align on the approach. And so with planning here, it might say, "Okay, you should absolutely take these steps.
- 8:49
These are correct. These are the clauses you should be looking for. This is what you want to review." So this is a good step. It gives you a bit more control.
- 8:56
It's easier to impose what you want it to do.
- 8:58
The problem is planning, you basically have to do all the work to just know what to do. I'm sure people have tried this in Claude Code. You basically have to go through the entire thing.
- 9:07
It's really inefficient. It takes a long time and asks you a bunch of questions. And in the end, it's basically impossible for it to really know if y- it has all the information it needs.
- 9:15
Let's say for one of these contracts, there's a special clause. It wouldn't know that in the planning step. You can't really tell it what to do when it sees that because it hasn't done all the work.
- 9:27
Essentially, you could compare planning to working with a coworker that, uh, comes up to you, tells you about the approach, you align with them, and then you never ever hear from them again until they deliver the final document.
- 9:39
It's not a super nice way to collaborate. This is a good thing we have right now, but, um, I don't think planning is gonna stay around.
- 9:49
Then we have skills. Skills are really, really, really good. They are really good because skills allow you to encode human judgment into essentially the nodes of work that happen here.
- 10:00
So I can say, "Whenever you review confidentiality, you should do it in this way." And the really good thing about this is it allows for contingencies. So here at one of the termination, reviewing termination clauses, there's a special EU law, but I have that in the skill, so that means whatever happens when it actually does the work,
- 10:18
it knows how to handle that special case. You can't really do this with planning.
- 10:23
There's also progressive discovery, which again, is really awesome. Whatever happens, it, it knows it'll pick it up. The problem is, um, you don't have skills for everything.
- 10:34
The next step is then, uh, to use elicitation, which means ask the user, ask the, the human. So you might have skills as well, but then instead of you giving it all the info, it's gonna come to you.
- 10:46
It's gonna say, "Hey, here's the thing I don't know how to handle. What do you want me to do?"
- 10:53
This, uh, makes a lot of sense, first of all. Um, what you don't want is you don't want the agent to be blocked. So ideally, if you implement this, what you do is you tell the agent, "If you're unsure about something, make a decision, unblock yourself, but write this to a decision log."
- 11:08
So then the human can review the decision log afterwards and reverse decisions if it needs to.
- 11:14
Now, the right UX for this, if you imagine this work, this tree being ten times bigger, a hundred times bigger, um, you don't want this in a chat. You don't wanna open up a chat, and then it's infinitely long.
- 11:24
You have to answer fifty questions. You wouldn't know what to answer. You wouldn't really be able to do it because you don't have the right context. So not chat.
- 11:32
Chat is one-dimensional. It's a very low bandwidth interface, and it tries to collapse this work tree into a single sort of linear thing. So what's a better interface? Well,
- 11:43
I think humans and agents should collaborate in high bandwidth artifacts. I think they need to work in things that are maybe typically persistent, um, and they will look different industry to industry, vertical to vertical, depending on what task you're solving.
- 11:57
So an example from us is, um, a document. That's like a durable interface where it makes sense to collaborate. That's how you'd collaborate with your coworkers. You can highlight clause three, and it will only change clause three.
- 12:10
You can add comments. You can tag your agents. You can tag your collaborators. You can hand off parts of the document to special agents. Another example is our tabular review, which is essentially I ask it to do, um, the contract review that I talked about, and it's gonna say, "Okay, let me spin up a tabular review," which
- 12:28
is like a known prince- primitive that our users know. And it looks like this, and then it's gonna say, "I'm gonna review all the contracts, and I'm gonna just flag a few items for you that I want your take on."
- 12:39
And then I can go in there, and I can see very quickly where the problems are. So it's high control. I-- it's very effective for me to instill judgment, and I can also very quickly get an idea for what the agent has actually done.
- 12:49
So reviewing is easy, and then once I've done that, I can just kick off the rest of the agent.
- 12:57
Right now, what we're seeing a lot is the convergence of UI. Basically, um, this is post hoc and linear, uh, within the last two weeks, shipping this new UI.
- 13:07
Um, to be clear, chat boxes as input is great. I think it allow-- it's extremely flexible. It allows you to do a lot of stuff, but you don't want chat to be your main mode of collaboration with a complex agent.
- 13:21
The good thing about this is language is essentially the universal interface. It's what people use to communicate. You can do everything with voice. Um, but agents aren't humans. [coughs]
- 13:37
Just a few minutes ago, I was, um, talking to a potential, uh, candidate for Legora, and I was describing our org chart. And, um, I was limited because [chuckles] I can only use language.
- 13:49
I wish that I could just draw up an org chart, and they could interact with it, and they could use it. But I can't because I'm a human. Uh, I am limited by language, but agents are not humans, and so we should not constrain them to human language.
- 14:02
Thank you. [applause] [outro jingle]