Standing delegations: how to hand work to an AI the way you hand work to an associate

Think about how you actually delegate work in a law firm. You don't sit next to the associate while they do it. You give an instruction once — "whenever opposing counsel serves discovery in this case, get me a summary of what they're asking for" — and then you go do your own work. The associate watches for the trigger, does the work when it happens, and brings you the result. If they're about to do something consequential, they check with you first. And everything they do lands on the record: their time, their tasks, their work product, all reviewable.

That is the standard almost no legal AI meets. What most vendors call an "agent" is a chat session with tools: it works while you watch, disappears when you close the tab, and its output lives in a side panel — untracked, unassigned, and unauditable. That isn't delegation. That's supervising a screen.

Lex Delegations were built to meet the associate standard. A delegation is a standing instruction you give once, in plain language, that runs on your firm's own events, under your approval authority, with every run tracked as real work. Here's how each piece works, and why each one matters.

One sentence becomes a standing instruction

There is no workflow builder. No automation canvas, no boxes and arrows, no trigger-condition-action forms to fill out. You tell Lex what you want in a sentence: "Whenever a document is linked to this matter, summarize it and message me the key points." Lex compiles that sentence into a formal delegation — defined triggers, defined steps, defined limits — and shows you exactly what it understood before anything goes live. You confirm it the way you'd confirm an associate has understood the assignment.

That confirmation step matters more than it might seem. The gap between what you said and what a system heard is where automation goes wrong. A delegation makes that gap visible once, up front, instead of letting you discover it three weeks later when the wrong thing happens on a live matter.

It wakes on your firm's events — not a chat window you babysit

Once confirmed, the delegation waits. It wakes when the firm's own events fire: a document lands on the matter, an email arrives, a deadline approaches, a schedule ticks. It is not polling, and it is not a conversation you have to keep open. The work happens while you're in court.

Suppose you're litigating Hale v. Northstar Logistics and you set up exactly the delegation above. On Tuesday, while you're in a deposition across town, a paralegal links thirty pages of newly produced maintenance records to the matter. The event fires. Lex reads the documents, writes the summary, and the finished work is waiting for you in EdgeMessage when you get out — key points, sources, done. You didn't ask that morning. You asked once, weeks ago.

Tell Lex once. It watches the matter forever — and the work lands on the task ledger, not in a side panel.

Every run is a real task, assigned to Lex

When a delegation wakes up, it doesn't work in the dark. Every run is created as an actual task, assigned to Lex, on the matter — in the same task list as the rest of your team, with status, history, and review. This is the difference between AI work you can supervise and AI work you have to take on faith.

Ask yourself how you supervise an associate's work today. You look at their tasks. You see what's open, what's done, what's stuck. You review the output against the assignment. A delegation run gives you exactly that: AI work becomes trackable and reportable the same way an associate's work is. If a partner asks what the AI did on a matter last month, the answer is a task list, not a shrug.

The instruction can never quietly change

Here is a property most automation doesn't have and legal work can't live without: delegation definitions are immutable and versioned. When you activate a delegation, its definition is frozen. If you edit it later, that edit creates version two — version one is still there, unchanged, forever. History never mutates.

And every run records exactly which version of the instruction it executed. So when you review a summary Lex produced in March, you can see the precise instruction that was in force in March — not the instruction as it reads today after two revisions. That is audit-grade recordkeeping: the same discipline your DMS applies to document versions, applied to the instructions your AI runs under. If a question ever arises about why the AI did what it did, the answer is on the record, not reconstructed from memory.

Back to Hale v. Northstar Logistics: suppose that after a month you sharpen the instruction — you want summaries to call out anything touching the maintenance schedule specifically. That edit creates version two. Every summary produced before the change is permanently tied to version one; every summary after is tied to version two. When you're reviewing the work six months from now, there is no ambiguity about which instruction produced which output. Compare that with any system where editing an automation simply overwrites it, and the old behavior becomes unrecoverable the moment you click save.

Nothing consequential happens without you

Delegations carry approval circuits on consequential steps. Sending an email, filing work product, touching a deadline — these pause the run and ask. Finished work arrives as a reviewed deliverable in EdgeMessage, never as a surprise already sent. Lex proposes; you approve. The delegation can do all the reading, analysis, and drafting on its own, but the moment a step would change the world outside the firm, it stops at your desk.

There's a second, structural layer under the approval gates: each delegation runs with a frozen capability surface — only the tools its definition names, default-deny. A summarization delegation cannot send email, no matter what the model decides mid-run. This isn't a policy the model is asked to follow; it's a set of tools the model was never given. Two different protections, and you want both:

• Approval circuits govern the steps a delegation is supposed to take — they pause and ask before anything consequential happens.
• The frozen capability surface governs everything else — steps the delegation was never meant to take are structurally impossible, because the tools aren't there.

Bounded runs, and a kill switch

Anyone who has supervised junior work knows the failure mode where effort continues but progress doesn't. Delegations are bounded against exactly that: iteration limits, budget ceilings, and progress checks on every run. A run that stops making progress stops running. It doesn't loop, and it doesn't spend.

And all of it is visible in one place. The Agent Control Center shows every delegation, every version, every run, and every delivery — with pause and retire controls, and a kill switch that stops everything. If something looks wrong at 4:45 on a Friday, you don't file a support ticket. You press the button.

What to delegate first

The delegations that pay off fastest are the ones matching how you already assign recurring work. The triggers are the firm's real events — a document lands, an email arrives, a deadline approaches, a schedule ticks — so the natural candidates are the standing instructions you'd give a junior lawyer on any active matter:

• "Whenever a document is linked to this matter, summarize it and message me the key points" — the canonical first delegation, and the one that pays for itself the first time a production lands while you're out.
• "Whenever opposing counsel files anything, verify every authority they cite and brief me on the ones that matter" — standing research, paired with Lex Research's citation verification.
• Deadline-driven instructions that wake as a date approaches, so preparation starts on the calendar's schedule instead of yours.

Notice what these have in common: each is work you already want done every time, where the cost today isn't the doing but the remembering — and the finished product in each case arrives in EdgeMessage as a deliverable to review, exactly the way an associate's draft arrives in your inbox.

Why this is the right shape for legal work

Put the pieces together and you get something that maps one-to-one onto how a firm already runs. The plain-language instruction is the assignment. The confirmation is the associate repeating it back. Event-driven wake-ups are the associate watching the file. The task on the ledger is the work being on the record. Immutable versions are the assignment memo in the file, unaltered. Approval circuits are "check with me before it goes out." The bounded run is the budget on the project. The Control Center is the supervising partner's view of everything in flight.

None of that is exotic. It's the ordinary machinery of professional accountability — the machinery that makes it safe to hand work to someone else in the first place. What's unusual is applying it to AI, because most AI products were built as chat tools first and asked to do work later. Delegations were built the other way around: the accountability structure came first, and the intelligence works inside it.

That's the test worth applying to anything calling itself an agent: when it works, is the work assigned, tracked, versioned, approval-gated, and reviewable — or does it vanish when the tab closes? A law firm wouldn't accept the second answer from a person. There's no reason to accept it from software.