Three engineers, one lawyer, two years, one bar to clear: an attorney at a law firm needs to be able to send our output straight to a client, without opening the document to fix it first. Not "impressive for AI." Not "close enough with review." Sendable, as is.
That bar sounds simple and is genuinely hard to hit. Wiring up an API call takes an afternoon. What took two years, three engineers, and one lawyer was a loop: a probabilistic model proposes, and deterministic code decides whether the proposal is safe to act on. That's mixus: legal AI for venture and corporate work, live in production at real law firms today.
The focus stayed narrow on purpose, four documents that show up on nearly every deal, not a general-purpose legal assistant trying to do everything at once. Narrow is what let us clear that bar on each one instead of stopping at "impressive for AI" on twenty of them:
- Pro forma agent.
- NVCA redline agent.
- Term sheet agent.
- NDA agent.
Claude runs behind an abstraction layer right now. We have swapped models before and will again. No retraining. No rewritten prompts. Nothing above depends on which model sits inside the loop. The harness, and the firm-specific data flowing through it, is what actually compounds. That is the part nobody can buy off the shelf.
Ask a raw model to redline a term sheet and it hands back changes that look plausible. Look closer and they're impossible to trust: a defined term updated in one clause but not the six others that reference it, a tracked change that reads correctly but landed twelve words off from where Word thinks it did. None of that shows up until an attorney opens the document. Run the same request through the loop below and a rule check catches the defined term, a validator catches the offset, and the run fixes itself or stops before a person ever sees it.
One loop, run continuously
mixus is a human-in-the-loop company. Review is one of five stages wired into the loop from the start, not bolted on after the fact. There are two loops running here, and mixing them up is where most agent claims go soft. An inner loop runs inside a single request: think, act, observe. An outer loop decides what happens to that request's output: ship it, patch it, or hand it to a person. Every product we ship, from the redline agent to the spreadsheet agent to drafting, runs the same five-stage outer loop around its own inner loop. Improve either one and every agent that touches it gets the improvement the same day it ships.
Build the harness, put a human reviewer at the point where a mistake would cost something, close the loop with tests, observe everything the agent does, and feed what happened back into the harness. Each section below covers one stage of that loop.
# the outer loop, once per request while not sendable: # inner loop: think, act, observe proposal = agent.run(task, playbook, context) checks = validators.run(proposal) # deterministic gates if checks.passed: return review(proposal) # human checkpoint if checks.patchable: task = patch(task, checks.fails) # fix, retry continue return review(checks.report) # stop, show receipts
The interface is email
Lawyers live in their inbox, not in a dedicated app. Build a great redline agent and it doesn't matter if nobody opens the tab. So the interface for talking to mixus is the one lawyers already use for everything else: email.
Send a document to the right address and a task starts. The agent works the loop above, and the result comes back in the same thread, not a link to go log into somewhere else.
The multiplayer part is what makes this more than a mail merge. CC anyone on the thread and they're in the loop: they can reply with feedback on the task, or reply to someone else's feedback, and each message lands at the end of the same thread the agent is reading. That's the same list-of-messages structure that makes an agent's context work at all; the thread is the context window, and every participant, human or agent, is just another sender writing into it. Nobody needs a seat, a login, or training.
The baseline harness
One shared agent engine runs under every mixus product. Each agent, redline, spreadsheet, drafting, is a thin plugin on top. It layers a system prompt, a set of guardrails, and an output format over the shared engine underneath. The loop itself, think, act, observe, lives in exactly one place. Improve the engine once and every agent inherits the fix the same day, without anyone touching agent-specific code.
The engine writes and runs real code in Python, Bash, and Node, and renders PDFs, inspecting its own output before handing it back. Skip context management and an hours-long run exhausts its window before the document is finished. mixus clears stale tool results once a run passes about 50,000 tokens, while keeping the reasoning that still matters, so length stops being the limit. Skip stall detection and a run loops forever on a disagreement that looks like progress from the inside. Guardrails here cover turn limits, stall detection with no-progress thresholds that still tolerate a legitimate back-and-forth, and forced completion, backed by retry with backoff and per-run token accounting.
Hosted chat products top out around thirty minutes of runtime. Our jobs run for hours, occasionally into a second day for a full NVCA suite across five interlocking documents, on dedicated workers pulling from a durable queue, with every inbound request classified and routed the moment it arrives. Document workers run LibreOffice at the OS level: on batch document editing, that is roughly 144 times faster than round-tripping the same files through a hosted conversion API. Retrieval runs per firm, over a vector store plus object storage, so one firm's documents never bleed into another's context. We have SOC 2 Type II and ISO 42001. We have passed security review at firms with five thousand people.
The playbook flywheel
A law firm's institutional knowledge lives as a set of machine-readable rules the engine executes directly, rather than as free text buried in a prompt. Put the same rules in a prompt instead and the model has to re-derive the hierarchy from natural language on every run, with no guarantee it resolves the same conflict the same way twice. As code, each rule carries an intensity. Required means the clause must exist; the agent adds it if missing. Preferred means the agent pushes for that position but adapts to context. Preferred if addressed is a softer preference: it will not override reasonable language already on the page.
Rules resolve through a strict hierarchy. Explicit instructions from the user come first, then the firm's own playbook, then system defaults for the document type, then the agent's general legal knowledge. The NVCA suite, the stock purchase agreement, the charter, and three rights agreements bundled with it (investor rights, right of first refusal, voting), is the clearest example of why that hierarchy has to be mechanical. Five interlocking documents, thousands of pages of context once a firm's playbook layers on top, and a single defined term can reach across every one of them. Managing that much cross-referenced context correctly is a harness problem before it is a legal one. That's why this hierarchy exists as code, not as a paragraph in a style guide. When a firm's rule contradicts a system default on the same clause, the firm's rule wins. The disagreement gets logged with a rationale, not silently overwritten.
Before any token fires, a deterministic pre-pass applies every known text substitution mechanically, cutting hallucination risk to zero on those decisions. A mandatory gap analysis then pre-checks every required clause into a checklist, so the agent cannot quietly skip a structural addition. Every accept, skip, and counter writes to a decisions store with a rationale attached, turning the redline into an audit trail instead of a black box.
Attorney corrections flow back through a Word plugin and a web reviewer, versioned with a diff view so a firm can see exactly what changed and why. This is the signal that compounds. A competitor starting from zero can copy our code. They cannot copy two years of one firm's corrections.
The redline engine
Producing a native Microsoft Word tracked change from an AI-generated edit is a genuinely hard problem. It's also the one the market actually benchmarks against. Try it the naive way: ask the model for new text and drop it in. It breaks in three predictable ways. Word stores text fragmented across XML runs that rarely line up with a sentence boundary. Position offsets shift the instant one edit lands. Formatting and footnotes corrupt easily the moment two edits touch the same paragraph. A bigger model does not fix any of those three. We built this engine from scratch instead. It is now past ten generations.
The determinism comes from six techniques working together. A document text index pulls dates, amounts, and quoted text out of the raw XML before the model ever runs. It targets real content, not a guess. Batch pre-validation checks every target before any edit touches the document. The run fails fast if too many targets come back invalid. Cross-run replacement maps an AI's target back to the underlying XML nodes no matter how the surrounding text is fragmented. Edits then apply in reverse order, end to start, so an earlier edit's offset shift can never invalidate a target further down the document. A four-tier fuzzy match, exact, then normalized, then a Bitap diff, then n-gram similarity, absorbs OCR noise and typography drift that would break a naive string match. And a multi-pass validation layer checks content accuracy and legal risk, section compliance and format integrity, and visual fidelity, with hard coverage gates and a dedicated table-integrity check.
In the newest generation, one writer drafts each edit, parallel reviewers check it independently, and a single patcher fixes whatever the reviewers reject.
A second validator sits on top of all of it. It sends work back when there's simply too much redline, before any of it reaches a person. The goal on every pass is the maximum substantive change with the minimum number of redlines. An attorney reviewing a hundred documents needs speed to conclusion more than a demonstration of how much the model noticed.
Determinism, proven
The cap table pro forma is where we can actually measure whether "deterministic" is a real property or just a word we like. Feed it any cap table export plus the deal terms, and it produces a multi-sheet financing model.
The pipeline separates judgment from arithmetic across five layers. A chat model generates the instructions. Code-level detection fixes the one parameter that moves the result more than any other: whether the option pool target applies to available or total shares. That decision never reaches the model. A constrained inner agent reads the workbook and fills a strict JSON schema: shareholders, investors, terms. It doesn't improvise a spreadsheet from scratch. A code validation layer enforces integer shares, normalizes percentages, applies the pool-type override, and checks the investor split. Only then does an algebraic closed-form solver compute the result: no goal-seek, no circular references, the same inputs producing the same outputs every single time.
We ran it on a real cap table export, the kind of input a firm already has on hand. The result was checked against a lawyer's own independent hand calculation. That's the real benchmark here. Five consecutive runs produced identical price per share, identical pool increase, and identical fully diluted total, landing within 45 shares of that hand calculation, a rounding-level gap from share-rounding conventions rather than model drift. Every model ships with eight financial identity checks the agent reports on itself. It also ships a live-formula verification sheet a lawyer can open and watch recalculate if any input changes. The model's only job is translating a messy input into a fixed schema. It never touches the math.
Tests, observability, and a loop that proposes its own fixes
Every behavior we care about is pinned by a test case: an input document, an optional gold answer or playbook, and metadata describing what should happen. Cases grade automatically by type. Surgical asks whether the edit was minimal rather than a full rewrite. Exact-match asks whether the agent reproduced a known set of changes. Playbook-audit asks whether the rules were applied correctly. Citation-audit asks whether every redline cites the rule behind it. NVCA-grade runs a full scorecard against the document-type checklist. A regression is any score that drops below its baseline, full stop.
The system proposes its own fixes, and tests decide whether those fixes survive. A closed-loop optimizer proposes a change based on recorded failures. It applies the change in an isolated worktree. It scores the result across separate train and holdout splits, with a guard against faked wins. Then it runs the change through an adversarial critique and a meta-review. Only after all of that does it reach the promotion gates that decide whether it ships. Around that loop sit bisection, perturbation testing, a PII scanner, and a nightly regression alert. Nothing ships without clearing the gates, and nothing degrades without someone finding out the same night.
Every action the agent takes is logged in a structured form built for a legal audit trail. A live action trace shows each step as the agent works. A reviewer can open any run and see exactly what happened, and why. Per-run receipts tie every redline back to a rule and a rationale. Take any of that away and the output is a black box, and a black box does not get sent to a client.
Two things here are still open, not solved. Is there real ground truth to check the cap table pipeline against, beyond a lawyer's hand calculation? Not yet; the check above runs against that calculation, not a machine oracle. Will a rule hierarchy that resolves cleanly today keep resolving cleanly as a firm's playbook grows past what one reviewer can audit by reading it top to bottom? We don't know yet.
Three engineers and one lawyer spent two years building the part that doesn't show up in a demo: the outer loop that catches what the model gets wrong before a client ever sees it. Firms with thousands of attorneys run on it now.