
Jacob Lauritzen, CTO of Legora, told Basil Chatha at Latent Space this week how you build an agent for lawyers when you cannot read a single trace of what it does. The answer is an org chart, and it is the most interesting FDE story of the year, because it cuts the seat this series is about in two.
The short version
As Latent Space reports the November 2 interview, Legora cannot read customer traces because the uploads are confidential and much of the data belongs to the firms' clients. So the field work is split: about 100 legal engineers, former big-law lawyers, configure the product for firms and write no code; forward deployed engineers, the first hired about nine months ago, write code and integrations, feed learnings back to product, and never touch client data. The eval lives with neither. A six-person team of three engineers and three lawyers builds simulated environments, including a 10,000-file due-diligence data room scored on whether the report catches the right red flags, and production failures are sorted into roughly 10 to 20 known failure modes with cheap checks behind flags. My rule is that the FDE writes the eval from the customer's real cases. Legora cannot, by design. What the split buys is the org at 100 without the breaks the Palantir post names, a 20-line handback, and the keys line filled on day one. What it costs is the row: the go-live pass rate at the firm is produced by someone who ships no code, on cases the engineer will never read, and the only number that crosses the wall is the rate. For any FDE seat behind a data wall: the field owns the rows and the rate, the FDE owns the list and the room, and the handback is the list plus the rate, never the rows.
What Legora built
The numbers first, as the article reports them. ARR passed $100M in April, less than 18 months after launch, with the show notes putting it above $200M at the Series E, $550M at an $8.8B valuation announced in October. More than 1,800 customers. Engineering headcount grew from about 20 to about 100. The Tabular Review product handles up to a million cells and starts a user at 10 rows for testing.
Now the constraint. Legora cannot read a single trace of what its agent does for a lawyer, because the data belongs to the law firm's clients. Everything below follows from that sentence.
The field is two roles. Legal engineers are former big-law lawyers who configure the product for a firm without writing code, a pool of about 100 people. Forward deployed engineers write code: integrations with a firm's CRM or document system, and the learnings that go back into the core product. The first one was hired about nine months before the interview, in New York. FDEs do not touch client data. Large engaged clients get legal engineers and sometimes an FDE, and Lauritzen expects a rotating group of FDEs within a year.
The eval is a third place. A team of three engineers and three lawyers builds simulated environments that mirror the work, with a 10,000-file data room for due diligence as the example, scored on whether the report catches the right red flags, and tracked as a heat map by practice area and task, because a new model often improves some tasks and regresses on others. Synthetic examples come from paraphrasing or anonymizing real cases, the safest route preferred. In production, failures are sorted into roughly 10 to 20 known failure modes with cheap model-based checks behind feature flags. One release raised citation reliability from about 70% to 99% without targeted work on that problem, which is the kind of thing a heat map catches and a demo does not.
The seat, cut in two
In The FDE Writes the Eval: Almost Right Has a Number I argued that the eval is the deployment artifact: one versioned set of the customer's real cases with agreed-correct answers, a target set against the human baseline, and a pass rule a machine can check, written by the FDE before building, with the customer's experts supplying the labels. It is the statement of work, the spine of the handback, and what the renewal is priced against.
Legora cannot do any of that as written. The person who can see the customer's cases cannot ship code. The person who ships code cannot see the cases. The row set that my rule puts in the FDE's hands does not exist on Legora's side of the wall at all; what exists is a synthetic room built centrally by six people, and a per-firm pass rate that only the legal engineer can produce.
That is a split of the FDE seat, and it is the honest design under the constraint. The question for the series is what it buys and what it costs, and both are specific.
What it buys: the org at 100 without the breaks
Palantir Can't Satiate Demand: What Breaks in the FDE Org at 100(coming Nov 4) names five things that break between the tenth FDE and the hundredth. Legora is at about 100 in the field already, and the split sidesteps three of the five.
The handback stops being read, because one product manager can read ten packets a year and nobody can read two hundred. Legora's handback is not a packet. It is a failure-mode list, 10 to 20 entries, each with a cheap check behind a flag. Product can read that every week, and a new entry is a diff, not a document.
The engineers end up on islands, because each deployment's customer layer lives in one head. Here the customer layer lives with the legal engineer who configured it and stayed, and the FDE's work is integrations that the next FDE can read in code.
And the day-60 drop from Month Two: The FDE Leaves, the Workflow Has to Stay, where attention falls from one of three customers to one of twelve accounts held by someone who cannot read the configuration, does not happen, because the person who can read the configuration did not leave. The keys line on my month-two page, the named person at the customer who can change the customer layer without calling you, is filled on day one. The legal engineer is that person, and ships no code, which is exactly what the keys line asks for.
What it costs: the row
The cost is the artifact my rule is built on. Behind the wall, the go-live pass rate at a firm has to be produced by the legal engineer, on the firm's cases, which the FDE will never read. The synthetic room gives the FDE a number for the product. It does not give anyone a number for this customer, and the renewal is priced against this customer.
So the only thing that can cross the wall is the rate, not the row. That changes three lines of the series.
The statement of work is still a row set passing, but the row set is held and versioned on the customer's side, by the legal engineer, and the FDE signs for the checks, not the rows.
The handback carries the failure-mode list and the per-firm rate. It never carries the evidence. When product asks why a firm's rate dropped, the answer comes back as a failure mode, not a case, and the heat map is what makes that answer useful.
The renewal is priced against the rate the field reports, which puts a number a lawyer produced on a contract an engineer built. That is fine as long as the row set is versioned and the customer can re-run it without Legora, which was already the independence test at month two.
The rule for a seat behind a data wall
Legora's industry is not the only one with this wall. Health, finance, defense, and anyone with a data processing agreement that lists few vendors ends up here. The rule, for any of them:
The field owns the rows and the go-live pass rate. Whoever sits with the customer and can see the cases, a legal engineer, a clinical lead, a customer's own analyst, holds the row set and reports the rate.
The FDE owns the failure-mode list and the synthetic room, and ships the checks behind flags.
The handback is the list plus the rate. The rows never travel.
Under AI Product Management the claim is that AI collapsed the cost of the parts PMs were trained for and left the parts nobody trained for. Reading a failure-mode list every week and deciding which of 20 entries moves the roadmap is one of the parts nobody trained for, and Legora's product team gets to do it because the field kept the rows.
This week, if your FDE cannot see the customer's data: write down who can, and whether that person can produce a pass rate on a versioned row set without you. If the answer is nobody, the eval does not exist, and the renewal is priced against a demo. The series is at The FDE Transition.
Related answer: Who writes the eval when the FDE cannot see the customer's data?
Sources: Basil Chatha with Jacob Lauritzen, "Building AI for Lawyers - Jacob Lauritzen, CTO of Legora," Latent Space, November 2, 2026, article and transcript read in full; the podcast audio was not listened to, and where the transcript does not label the speaker a figure is attributed to the article rather than to Lauritzen. Falk Gottlob, "The FDE Writes the Eval: Almost Right Has a Number" (October 27, 2026), "Month Two: The FDE Leaves, the Workflow Has to Stay," and "Palantir Can't Satiate Demand: What Breaks in the FDE Org at 100(coming Nov 4)."
Frequently asked
How does Legora run forward deployed engineering?+
As Latent Space reports Jacob Lauritzen's November 2, 2026 interview: legal engineers, former big-law lawyers, configure the product for firms without writing code, in a pool of about 100. Legora hired its first forward deployed engineer about nine months before the interview, in New York. FDEs write code, build integrations with a firm's CRM or document system, feed learnings back to the core product, and do not touch client data. Large engaged clients get legal engineers and sometimes an FDE, and Lauritzen expects a rotating group of FDEs within a year.
How does Legora evaluate an agent it cannot observe?+
Per the same interview, Legora cannot read customer traces because uploads are confidential and much of the data belongs to the firms' clients. An evals team of three engineers and three lawyers builds simulated environments that mirror customer work, such as a 10,000-file data room for due diligence scored on whether the report catches the right red flags, tracked as a heat map by practice area and task. Synthetic examples come from paraphrasing or anonymizing real cases. In production, failures are sorted into roughly 10 to 20 known failure modes with cheap model-based checks behind feature flags, and one release raised citation reliability from about 70% to 99% without targeted work on it.
What does the split cost?+
The row. My rule in The FDE Writes the Eval is that the eval is one versioned set of the customer's real cases with agreed-correct answers, written by the FDE with the customer's experts supplying labels, and that it is the statement of work, the spine of the handback, and the renewal's price basis. Behind Legora's wall the FDE never sees a row, so the go-live pass rate at the firm has to be produced by the legal engineer on cases the FDE will not read, and the only number that crosses the wall is the rate. The handback carries a failure-mode list and a rate, never the evidence.
What does the split buy?+
The org at 100 without the five breaks in Palantir Can't Satiate Demand. One product manager can read ten handback packets a year and nobody can read two hundred; Legora's handback is 10 to 20 failure modes with checks behind flags, which product can read every week. The keys line from Month Two, the named person at the customer who can change the customer layer without calling the FDE, is filled on day one because the legal engineer is that person. And the day-60 attention drop from one of three customers to one of twelve accounts does not happen, because the legal engineer did not leave.
What is the rule for an FDE seat behind a data wall?+
The field owns the rows and the go-live pass rate: whoever sits with the customer and can see the cases, whether a legal engineer, a clinical lead, or a customer analyst, holds the row set and reports the rate. The FDE owns the failure-mode list and the synthetic room, and ships the checks. The handback is the list plus the rate, and the rows never travel. Price the renewal against the rate the field reports, with the row set versioned on the customer's side.

Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn