The 30-second version: In #290 I decoded the $320K legal engineer and argued the title is noise: what matters is the capability, six components, and almost nobody holds all six. This issue is the receipts. I scored myself against that framework, found I already held four of the six from twenty-plus years of doing the work, spent the last three years teaching myself the other two, and then proved it the only way that counts: I built an agentic system that captures my own IP and way of working, and I am running it live inside one of the fifty largest firms in the country. Below I walk you through exactly how, in plain words with the technical terms running alongside. And if you are a clicker, not a reader, here are the two doors, open now:

See the build instead of reading about it. I turned the entire build into an interactive walkthrough: every step in plain English, the technical terms running alongside, a key-terms glossary one tap away. Take it at your own pace: brainyacts291.joshkubicki.com

If you are in-house counsel, this is your opening. I think GC teams are better positioned to run this method than any law firm, and I built a site that walks you through exactly why and how, with an invitation at the bottom for a seat at a small working table: gc.transformlegal.com

THE FULL BRIEF

Last issue I decoded the title. This issue I decoded myself.

Quick recap for anyone who missed #290. The "legal engineer" label is being defined by whoever is paying for it: one firm's version is a builder, a startup's version is a translator, and the $320K version at the top of the market is, when you read the compensation structure, substantially a seller. My conclusion was that chasing the title, or the unicorn who supposedly holds it, is the wrong move. The right move is to define the capability your firm actually needs and organize around the work. Six components, three of them judgment about the law and the business, three of them judgment about systems. Almost nobody scores high on all six.

The response to that issue told me the nerve is live. So this issue does the thing I always try to do after an argument lands: show the work. Not a framework this time. A field report on what it looks like when the capability gets exercised, end to end, by one person plus a partner, on real work, inside a real firm.

There is a name arriving for exactly this kind of exercised capability: forward-deployed. Borrowed from software, where it means the engineer who embeds inside the customer's operation and builds around the reality on the ground, and now being staffed across legal AI by vendors hiring engineers first and teaching them the work afterward. In legal, I think that is exactly backwards, which raises the question I want to plant in your head for the rest of this issue: why are we waiting for engineers to learn our profession, instead of our profession learning to engineer?

A few months ago I did something uncomfortable. I took the six-component capability model from #290 and scored myself against it, honestly, the same exercise I told firms to run on their own people.

Four of the six, I found, I already held, and had held for years. Legal and commercial judgment, from two decades of sitting with partners and practice groups. Workflow intelligence, the unglamorous knowledge of how legal work actually happens as opposed to how the org chart says it happens. And translation, which has been my entire career in one word: extracting what experts know but cannot articulate, and carrying it across to people who need it in a different form. Call it 80 to 90 percent of the forward-deployed job, at the strategy level and in the trenches, already banked. Not because I am special. Because that is what experienced legal operators do all day and have never had a market reason to name.

What I did not hold was the other two: technical fluency and evidence discipline. The craft of actually building with AI, and the harder craft of proving the thing you built actually works. That was my missing 10 to 20 percent. So for the past three years I taught myself, and this year I closed the loop the only way that counts: live, at the coal face, building something real.

Two builds, actually, and I chose them deliberately.

First, I ran the experiment on myself. Regular readers know I have been building an analyst desk, the Deep Coverage concept from #283. What I have not fully explained is why I aimed it at me first. I wanted to know whether I could build an agentic system that captures my own IP, my characteristics, my way of working, my accumulated pattern recognition, and productizes it to a meaningful degree. Could I decode my own work the way I have spent a career decoding other people's? Could I operate as a forward-deployed legal engineer where the deployment target was my own head? I have done versions of this decoding my whole prior life. I had just never done it with the goal of making agents run it.

Second, I am doing it inside a real firm, right now. An AmLaw 50 firm, inside one of its practice groups, partner by partner. Real interviews, real profiles, real weekly intelligence, real feedback, including the feedback that stings. This is the part that keeps the whole thing honest. It is easy to be impressed with your own system when you are the only user.

Watch what is happening in each step. The even-numbered muscle here is evidence discipline. The odd-numbered muscle is technical fluency. The material they both work on is the judgment I already had.

One. I wrote down what was in my head. Everything I do with a partner by feel, I forced into writing. The questions I ask and why. The patterns I watch for. What it means when the answers to two different questions quietly contradict each other. This was the slowest, most uncomfortable part of the entire build, like explaining how you ride a bike. I was decoding my own heuristics, turning twenty-five years of "I just know" into instructions a machine could follow. Understand why this is necessary: everything the model read in training was public, and your edge was never public. The machine cannot shadow you the way a junior colleague can. It knows only what you write down. The trade calls this knowledge capture, and the documents it produces become the system prompt: the standing instructions the model reads before it touches any real input.

Two. I defined what good looks like, in writing, before the system did any real work. I can read a page of practice analysis and know in ten seconds whether it is right. That is intuition, built over decades. The machine has none, and it cannot be given any. It does not know what a good read is, and here is the part that should worry you: it writes beautifully whether it is right or wrong. So I invented three fictional partners, archetypes I have seen a hundred times in real life, wrote out their complete interview answers, and then wrote down the specific findings a correct analysis of each one must surface. Then a scorecard, with a passing grade I set in advance. The trade calls the fictional partners golden personas, the scorecard a rubric, and the whole practice evals. In my build: three personas, twelve scoring criteria, a pass bar of 8.0 out of 10 with no criterion below 6, never lowered. This, right here, is what #290 called evidence discipline.

Three. I told the machine how to think, and in what order. Left alone, a model does what a nervous student does: it starts producing polished sentences before it has thought anything through. My instructions forbid that. The system must first work through all the answers and produce a structured diagnosis, where the story holds together, where it quietly does not, what the real bottleneck is, and only after that analysis is complete is it allowed to write a sentence a partner will ever read. Think first, write last. The trade calls this a two-phase pipeline with structured output: the diagnosis is produced as data I can inspect, before any narrative exists.

Four. I brief it, every single time. The machine has no memory. Every session is its first day. So it reads a standing briefing document before it works: what this engagement is, who it serves, what is in motion, and the rules learned the hard way, like every date gets verified against the original source, and nothing longer than one page goes to a partner. Most people using ChatGPT are unknowingly re-explaining their world from scratch in every chat, forever. This one document is the difference between a tool and a colleague. The trade calls this a context file, and the discipline of deciding what the model reads before it works is context engineering.

Five. I made it practice until it passed, every time. I ran the three fictional partners through the full system and graded the output against the scorecard. Where it missed a required finding, I sharpened the instructions and ran it again. And again. The rule was absolute: the system touches no real partner until it passes all three practice cases, every time. Not usually. Every time. Eventually I automated the grading itself and handed the machine a standing order: keep iterating, and do not lower the bar. The trade calls this an eval harness, with a model grading the outputs against the rubric, sometimes called LLM-as-judge. This is the step nearly everyone skips, and it is the entire difference between a demo and a system.

Six. I gave it limits, and I kept my hand on every send. The research side runs on a hard budget: a fixed number of searches per partner, allocated across named sources, no exceptions. Any fact that cannot be verified against an original source gets flagged, never sent. And the biggest rule of all: nothing reaches a real human being until I have read it and hit send myself. The machine drafts. I decide. If you are wondering what I gained if I still review everything: reviewing a strong draft takes minutes. Producing it used to take my week. The trade calls the research workers agents, the instruction files that define their jobs skills, and the review rule human in the loop.

Seven. Once it went live, I started keeping score. Every real interaction gets logged. What each partner acted on, ignored, rewrote in their own words, or flatly rejected, which is the most useful signal of all. That running record makes next month sharper than this month, and over time it becomes the one asset in this whole build that nobody can copy. Anyone can buy the model I use. Nobody can buy the record of how real partners actually responded. The trade calls this the ledger, and over time it becomes a golden dataset: the labeled examples any future automation gets trained against and measured against.

That is the build. For completeness: yes, there is also a web application wrapped around it, the interview a partner clicks through, the database, the results page. I built it without writing a line of code, by describing what I wanted in plain English to an AI coding tool. The trade calls that vibe coding. It took evenings. The seven steps above took months. That ratio should tell you where the real work lives, and notice where it lives: not in the technology. In the judgment the technology was wrapped around.

One more thing, because the conversations behind this issue keep pointing the same direction. I have been talking with a lot of people about this work, but with in-house counsel in particular, something clicked: general counsel and their teams may be positioned to operate this way sooner than anyone at a law firm. The constraints are simply different. No billable hour quietly defending the status quo. One client, whose business you already sit inside. And every hour this kind of system returns to an in-house team is pure capacity, not a revenue problem. To be clear, lawyers are still lawyers. Nobody is turning your team into engineers. The point is the method: embed in the actual workflows, test the system before trusting it, deploy with supervision. Exactly what you watched me do above.

If that is you, I put together a site that walks in-house counsel through forward-deployed legal engineering: gc.transformlegal.com. And if you are a GC or legal department leader who wants to work through this in a room with me and a small group of peers, there is a button at the bottom of that page. Use it.

So here is the question I will leave you with. What is the work you do by feel, the thing people actually pay you for, that you have never once written down? Start there. That document is the beginning of your system, the beginning of you building an agentic workflow and the deepest answer I have to the question I hear most: "I use AI every day, how do I go deeper?"

If you are building something like this, or want to, reply and tell me where you are stuck. The best conversations this newsletter produces start exactly there.

Talk soon again, Josh

P.S. The interactive walkthrough of this build, with a key-terms glossary built in, lives at brainyacts291.joshkubicki.com

Wispr Flow turns your voice into clean, professional text you can send the moment you stop talking. Not rough transcription you have to clean up. Actual polished text — ready for email, Slack, or any app.

Speak the way you think. Go on tangents. Change your mind mid-sentence. Flow strips the filler, fixes the grammar, and gives you text that reads like you spent five minutes writing it.

89% of messages sent with zero edits. Millions of professionals use Flow daily, including teams at OpenAI, Vercel, and Clay. Works on Mac, Windows, and iPhone.

Start flowing free

To read previous editions, click here.

DISCLAIMER: None of this is legal advice. This newsletter is strictly educational and is not legal advice or a solicitation to buy or sell any assets or to make any legal decisions. Please /be careful and do your own research.