Agents need more than a chat

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.

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.

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.

The practical unit of analysis is the task, rather than the label “legal” or “coding.”

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.

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:

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.

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.

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.

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:

1. When uncertain, make a provisional decision.
2. Record that decision in the log and continue working.
3. 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.

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.

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.