The Legal OS

I serve as fractional general counsel for two companies and outside attorney for numerous other clients. For most of last year, every morning started the same way: open an AI chat and spend the first ten minutes re-teaching it who my clients are, what I was working on yesterday, and how I format my documents. The most powerful technology to hit legal practice in my career, and it couldn’t remember my name from one session to the next.

So I built something different. Since early March I’ve been running my practice on a persistent AI workspace built with Anthropic’s Claude Cowork. Five months in, it’s the operating layer the practice runs on. It knows my clients, my contacts, my open matters, and my preferences, and it carries all of that from one session to the next.

This is the long version: what I built and why, what the security diligence found, and how it works.

Why I built it

The problem with a fractional practice is context-switching. Every client is another set of executives, another contract stack, another ongoing matter, and one lawyer holding all of it. The context lives in my head, my files, and my inbox, and every AI tool I tried treated each conversation as a blank slate. I was spending real time every day re-loading context into a tool whose entire value proposition was saving me time.

Most of the “AI for lawyers” products don’t solve this. They do research, or drafting, or review, each inside its own silo, with no memory of what happened in my practice yesterday. A few tools are starting to build toward a real context layer, but none of them fit the way my practice and workflows actually run. What I needed wasn’t a better legal task tool. I needed the context layer underneath all the tasks: something that already knew my clients, my open matters, and my conventions before I typed a word. Nothing off the shelf fit closely enough, so I built it.

What a legal OS actually is

Most people hear “AI that remembers your clients” and picture a longer chat history. There’s no conversation being scrolled back through. There’s a folder on my own drive, and Claude reads it at the start of every session and writes back to it before the session ends.

The chat tools have built-in memory features now, so why is a folder better? Because chat memory is a black box. It’s a collection of fragments the vendor’s system decided to keep, stored on the vendor’s side, with no way to read the full picture, correct it, or audit what the model is being told about your practice. The file system is the opposite on every count. I can open the memory file and see exactly what Claude knows, fix what’s wrong, watch it change over time, and take the whole thing with me if I ever switch platforms. It’s organized the way a practice is organized, by client and matter rather than by conversation, and it holds what chat memory never will: the matter notes, the research positions, the work product itself. For a lawyer there’s a second reason that settles it. You have a duty to know what a tool does with client information, and “whatever the memory feature decided to store” is not an answer you can give a client.

The folder is boring on purpose. A memory file Claude reads first, holding the standing state of the practice: who my clients are, who their people are, what’s open, and every preference I’ve ever caught myself repeating. Matter notes for each client. Client files for anything that needs to survive as a document. A knowledge base of raw research, and a wiki of the standing positions that research turns into. An admin layer for scheduling, billing, and the instruction sets for repeatable tasks.

├─ MEMORY.md The standing state Claude reads first: who the clients are, who their people are, what is open, and every preference worth repeating.

├─ Client Notes/ One folder per client.

│ └─ <Client>/ Matter notes — history, positions, decisions.

├─ Client Files/ One folder per client.

│ └─ <Client>/ Documents that need to survive as files.

├─ Knowledge Base/ Raw research and source material — the inputs.

├─ Wiki/ Standing positions on recurring questions — they sharpen each time a matter tests them.

└─ Admin/ Scheduling, billing, and the instruction sets for repeatable tasks.

Here’s what that looks like on a workday. Before I’ve finished my coffee, the system has read my calendar and checked my email, and I have a structured briefing telling me what the day actually looks like. It knows “Marcus” is the CEO at one client and “Elena” is the CEO at another. It knows which contracts are in review and tracks deadlines against whatever I told it yesterday I still needed to handle. Documents come out in my formatting conventions and get logged to the right client file. Tasks stay synced across Notion, email, Slack, and Teams without me copying anything between tabs.

The part that compounds is the research loop. Raw research goes into the knowledge base, but standing positions on recurring questions live in a wiki, and those positions get sharper every time a real matter tests them. Research in, position out, applied on a matter, matter feeds back into the position. That loop is the difference between a system that improves with use and one that just accumulates files.

What it does when I’m not looking

The folder and the memory file explain the recall. What earns the “operating system” name is what runs between sessions. Twenty-nine scheduled tasks fire on their own clock, and the four worth showing you are the ones that closed the loops a solo practice usually leaves open.

The morning briefing is built before I sit down. A scheduled task runs it early each weekday: calendar, overnight email across two firms’ inboxes, task list, and anything the system flagged the day before. Twice a day, another task pulls regulatory updates (IAPP, FTC releases, state AG announcements) into the knowledge base, so the research layer feeds itself. And overnight inbounds get classified on arrival: anything that looks like a new matter (new counterparty, contract request, dispute inquiry) shows up in the briefing as an intake card, capped at three so the signal stays clean.

Say the word on an intake card and matter setup starts with a conflicts check. Before any new matter file opens, the system runs a fuzzy-match search against a registry of every client, related entity, adverse party, and counterparty the practice has touched, then pauses for my clearance. Lawyers will recognize what that is. It’s the screening our rules already require, run every single time, no longer depending on my memory of a name I last saw in a contract two years ago.

On the first of each month at 8am, the billing pipeline wakes up. It reads the billing calendar, pulls the prior month’s time entries from the tracker, and presents a rate confirmation before generating anything. I approve, and it produces the prebills. I approve again, and it produces the invoices with drafted delivery emails. Time capture feeds it all year: the system drafts time entries from actual session activity, and nothing posts until I’ve reviewed the entry as written.

The last loop is client communication. When a matter log records an event a client would want to hear about (an agreement executed, a filing completed, a deadline a week out), a client-update email gets drafted and queued automatically. It’s waiting in the next morning’s briefing.

Notice the pattern. Every one of those loops ends at a gate. The conflicts check pauses for clearance. The prebills wait for approval. The drafted emails never send themselves. The system handles the logistics, and I review and decide. That split is deliberate, and it answers half the ethics questions lawyers ask about AI before they’re asked.

Five months of daily use built all of this: well over a hundred contact profiles, seventy-plus matter files for the busiest client alone, ninety-plus custom skills, and the scheduled tasks running the loops above.

The audit trail

Every session leaves a record. The system logs the whole session as the work happens: every prompt I enter, every response, every tool call and its result. When the session ends, it writes the log to my own file system. The work product it produces is filed with the matter it belongs to. The work the AI does is not a black box I take on faith. It is a document I can open and read back, step by step.

That matters for a reason particular to lawyers. Using AI on client work carries a duty to supervise it: to know what the tool did and to stand behind the result as your own. A complete, reviewable record is what makes that duty something you can discharge rather than merely assert. If I need to reconstruct exactly what happened on a matter, what was researched, what was drafted, what was sent and when, the record is there, and it is mine rather than a vendor’s export I have to request. Accurate time capture falls out of the same record: because every session carries a true, timestamped start, the billable hours come from what the log shows instead of what I remember. The governance is the point; the clean invoice is a side effect.

The security review

Now the question every lawyer asks first: what happens to client data. I did the risk assessment before I built anything else, and this month I redid it as a formal vendor risk assessment, the same framework and the same skill I use when a client asks me to vet one of their vendors.

The setup itself, first. The system runs on a commercial Claude Team plan under a stand-alone firm account, separate from any client’s account, with Anthropic’s DPA in place. Inside that: no training on anything I send it, a sandboxed execution environment scoped to the task in front of it, and client files that live in my own file system rather than a vendor’s platform.

The assessment scored that deployment 4.16 out of 5 for a solo or small firm. My firm-specific version came in at 4.14. I ran the same framework on GC AI, the other AI tool in my stack, and it scored 3.46. A score like that isn’t a fail. GC AI’s evidence set is solid (SOC 2, three pen tests, and its DPA all available through its trust center); the score reflects contract terms a small-firm buyer should read closely before signing, including an uncapped customer indemnity I’d want to negotiate on any deal I was papering for a client. That’s the point of scoring your own stack the way you’d score anyone else’s: it tells you where the residual risk sits and what to monitor.

Read the full small-firm vendor risk assessment (PDF).

The most useful thing to come out of the review wasn’t a score. It was a rule.

During the review, three errors got caught, all with the same cause. A DPA effective date came in from a secondary source as January 1, 2026; the actual document says February 24, 2025. A vendor’s deletion timelines (30 and 90 days, depending on the data) and its breach-notice standard (“without undue delay after confirming”) got missed entirely until someone actually read the DPA instead of the FAQ. And when I ran an AI second opinion to red-team the assessment, it confidently “corrected” a sub-processor detail and was itself wrong. The vendor’s actual sub-processor page settled it.

The rule that came out of it: a fact about a governing document comes from the document. Never from a summary, a FAQ, a search snippet, or another AI reading over your shoulder. If you can’t retrieve the document, the fact is unverified, and you say so. Lawyers already know this rule. We apply it to opposing counsel’s characterization of a contract every day. The lesson of the review is that it applies with equal force to your own tooling diligence, and that an AI assistant will cheerfully violate it unless you make the rule explicit.

The ethics layer sits on top of the technical one. ABA Formal Opinion 512 and Florida Bar Ethics Opinion 24-1 frame the analysis for generative AI, and the underlying duties (competence, communication, confidentiality) don’t change because the tool is new. The same week as the review, I built a client disclosure and consent template: a retainer clause, a standalone signed form, and the firm’s data-handling practices stated plainly, including a 30-day deletion practice with a legal-hold exception. If a client asks what happens to their data, the answer shouldn’t be improvised.

Skip the buzzword

Let me step back from the machinery for a second. There’s a lot of chatter right now about “AI-native lawyers.” I’ll be honest: I don’t really know what that means, and most of the time it reads like marketing slop. I’m not claiming a category. All I’ve done is describe a problem I had as a solo lawyer, show what I built to solve it, and use and improve it until it became the backbone of the practice. That’s the whole story.

The part worth telling other lawyers is that I built it without being an engineer. Three years ago I couldn’t have told you what the terminal on my Mac was, how to open it, or what to do if I did. Claude Code, Anthropic’s command-line coding tool, was a mystery. But like most lawyers, I’m good at working through an idea and saying in plain language what I’m trying to accomplish, and it turns out that is most of what building this takes. If you can think, read, and write, you can build. The rest is determination, grit, and a healthy sense of curiosity.

I’ll be equally honest about the limits. This isn’t for everyone, and it isn’t a replacement for the purpose-built legal AI tools on the market. Several of them are very good; I’m partial to GC AI and use it daily. The legal OS doesn’t compete with those tools. It’s the operating system that my own knowledge, my skills, and the other AI tools I use all run on top of.

What it comes down to

Take away the folder structure and the scheduled tasks and what’s left is a division of labor. The system carries the context, drafts the work, and runs the logistics a solo practice usually lets slip. I make every judgment call, and nothing reaches a client without me at the gate before it. That isn’t a safeguard I added to feel better about the technology. It’s the design, and it’s the same standard I hold a client’s AI to when they ask me whether they can use it and how.

That’s the reason any of this is written down. Plenty of firms say they use AI. Fewer can tell you exactly what the tool does, where it stops, where the lawyer takes over, and what becomes of your data when the matter closes. I can, because I built it and ran the diligence on it the way I would for you. The legal work we do runs on this system now, and it will run on a sharper version of it next month.

MBLegalOS and the linked materials are independent projects of the firm. They are not affiliated with, or endorsed by, Anthropic or any client of the firm.