Why We Put Engineers in the Field

Every product we've shipped since 2022 started with one of our engineers sitting next to a lawyer working on a live matter.

Precedent search came first, in 2022. Drafting followed in 2023, review and markup in 2024, our AI Agent in 2025, and Ontonomi, our legal ontology platform, this year. Each time, an engineer watched a lawyer do something by hand because the firm had no other way to do it, and we built a solution into the product.

We put engineers in the field because you can't see those moments from a distance. A lawyer can describe a problem in a meeting. Sit beside them, and you see the problems they've stopped noticing: the spreadsheet someone maintains, the old email they always search for, the colleague who remembers why a provision changed. The next product usually starts there.

Plenty of companies now have forward-deployed engineers. I think the useful question is what those engineers produce and where that work ends up. So here's how it works for us.

The Job Is Finding the Gap

People hear "forward-deployed engineer" and picture a team that gets customers into production. For us, going live is quick. We connect a firm in an hour, index its documents overnight, and lawyers are using the product the next day, with nobody on site.

Our engineers aren't in the field to implement the product. They're there to find what we should build next. That's what separates the role from the two it's often confused with: implementation and solutions engineering. Both take the product as given. A forward-deployed engineer is there to change it.

Our engineers sit with a practice group on real work, identify the gap (the work the firm can't do today), and build the product capability to close it, testing it against the firm's own data. It has to hold up in actual use, which means incomplete records, conflicting versions, exceptions that matter, and a lawyer who needs an answer they can defend. Then it becomes part of the product, alongside everything we've built with the firms before it.

During my time at Palantir, we had a blunt way of putting this: eat the customer's pain and turn it into a product. The firm with the problem gets it solved. From there, the benefits compound: every firm that uses the product afterward helps make the software better for the firms already using it.

Our forward-deployed engineers are part of the product organization. The engineer who sits with a lawyer is the same one who ships the change.

How It Compounds

When we take on a new domain, we put serious engineering behind it, and that investment is ours to make. Our engineers work inside a practice, learning the work and testing against real matters. The firm we're working with typically has a working version by week two and is in production in about a month.

Nothing we build this way is a one-off. From day one, every solution is developed as part of the broader product, building on everything we've created and refined over the past five years. A firm joining us today benefits immediately from that collective work: every practice we've modeled and every improvement informed by real client matters. The work we do with each new firm adds to that foundation, but represents only a fraction of the value it receives.

It's also the best product research I know of. We build something, put it in a lawyer's hands, and see whether it helps. On live matters, we hear quickly when it doesn't, and the fix goes to every firm.

That's the flywheel. Each firm we work with makes the product better. A better product takes us into more practices, and more practices give us more to learn from. Each time around, the product improves for every firm that uses it, regardless of when it joined.

Why the Ontology Needs It

Underneath everything we build is our proprietary intelligence layer: a legal ontology that models documents, clauses, parties, deals, positions, and outcomes as related objects. The relationships are computed once, so the system already knows a clause's deal, counterparty, version history, and outcome when a lawyer asks.

The graph itself is the straightforward part. What takes time is learning which objects and relationships matter to a given practice. Funds lawyers work with LPAs, side letters, MFN elections, and comment memos. M&A lawyers care about a different set, and credit lawyers about another. Nobody can write that schema from outside the firm, and even from inside, you get it wrong the first few times.

The answer to a real question also tends to sit in more than one system. When an LP asks what another LP received and whether it's MFN-exempt, the pieces are spread across the document management system, the CRM, and years of document versions and emails. You learn where each piece lives by sitting next to the lawyer who's been answering that question by hand.

At one firm, our first pass at reading fund comment memos was accurate about 60 percent of the time. Our engineer was sitting with the associates and noticed that they read each comment together with the firm's response, treating them as one unit. We'd been extracting the comments on their own. We changed the model to treat each comment and response as a pair, worked through the remaining misses with the associates who wrote the memos, and improved accuracy to about 90 percent.

Accuracy improves this way in every practice. When a lawyer corrects a result, and an engineer is sitting right there, the engineer can trace the source and test a fix while the context is still fresh. The same correction filed as a ticket a quarter later is much harder to act on.

What Transfers, and What Never Does

Every firm has its own templates, house style, clients, and negotiating history. But the underlying work has more in common than you might think. That's why a credit ontology developed in the field can work at the next firm with relatively small adjustments. The schema gets sharper with every firm that uses it. When our engineers sit with a new firm, the model is already in the product, so their time goes toward finding the next gap.

Two things carry over. The first is software: parsers, connectors, document models, and workflow logic. That includes how to ingest a document management system, break a contract into clauses, and follow a document from term sheet to signature. The second is the practice model: which objects and relationships matter in credit, funds, and M&A. Every client benefits as both mature.

Anything that belongs to a firm stays with that firm: its precedent, negotiated positions, preferred language, counterparty knowledge, and deal history. Each deployment runs on that firm's own institutional knowledge, within its own environment. If firms' knowledge were pooled, nobody would have a reason to buy.

Word is the closest comparison. Every firm drafts in the same editor, and no firm worries that the editor shares its strategy with another firm. When the editor improves, everyone benefits, and what you write in it remains yours. Draftwise works the same way, one layer deeper.

Every firm runs the same technology but gets different answers because those answers come from its own data. A firm with thirty years of credit deals can draft and negotiate using all thirty years of experience. Another firm running the same software sees none of it.

Where This Came From

I learned this working on Skywise at Palantir, the aviation data platform Airbus built with Palantir, alongside the people who ran the fleets. Nobody can define a fleet data model from a conference room.

Take a question like which aircraft are likely to be grounded next month. It sounds like one query. Answering it means connecting maintenance records, flight data, and whatever a planner keeps track of on their own. You only learn what that is by sitting at the next desk.

The question is the same at every operator, but the answer is different at each one. It depends on local things: when maintenance is scheduled, where spare parts are kept, how much hangar capacity is free. These sound like small details, and each one changes the answer. Very little of it is written down, so you have to be there to learn it.

Legal presents a similar problem, and I think it's a harder one because so much of what a firm knows sits in drafts, versions, and email.

We changed one thing at Draftwise. Once a practice is modeled, it becomes part of the software available to every customer. That's why our field team doesn't need to grow with every customer we add.

What It Adds Up To

The ontology took us five years to build. Most of that time was spent in the field, and every deployment made the next one faster. I don't think you can make up that time simply by hiring more engineers.

We hold ourselves to two checks. First, we should be able to point to what became part of the product and what another deployment can reuse. Second, we should be able to show how client data stays within each firm's deployment, under its own permissions and ethical walls, and is used only for that firm.

Forward-deployed engineering is our R&D function. It's how we've shipped a new product category every year, and why the product gets better for every firm each time we add another.