The Most Valuable AI Asset at Your Firm Isn't the AI
A medical report lands in a paralegal's inbox at 7 a.m. What happens in the next hour explains more about your AI readiness than any pilot program.
Every few weeks, there’s a new term going around the AI world. Prompt engineering. Context engineering. Agentic workflows. Right now my feed is blowing up with one new term: graph engineering.
The concept of graphs isn’t new. But what caught my attention is that I think this might be a better way to solve a problem we’ve been wrestling with for years. That problem? How do we move from lawyers using AI on one-off tasks to entire law firms using AI across real work while still maintaining control?
My TL;DR: Graph engineering maps work as a series of connected steps, decisions, checks, and approvals. For a law firm, the value isn’t a single uber-powerful agent running a process, but a system that knows what should happen next when something changes.
So what exactly is graph engineering
When we first started using AI, it was all about prompt engineering. Carefully constructing a prompt to get a great output from ChatGPT or Claude. Then we all moved to context engineering, which meant making sure every chat and interaction had the full context and documents needed to drive better insights. Graph engineering is at a higher level - it starts with the concept of how work should move in an organization.
Think of a graph as just a map. Every point on the map is a task, a decision, a check, or an approval. The lines connecting each of these points show what could happen next. Some paths move forward, some split, some stop for a person, and some send the work back a step because a check process failed.
It sounds technical, but it’s not. This is about all of your existing workflows: a new client comes into a firm, or you have to respond to an order from a court. There’s a series of steps you take (like a map or graph) - it probably just isn’t written down.
The reason this is so important is that AI is moving from being an answer engine, like ChatGPT or Perplexity, or a simple agent (monitor my email) to something that can orchestrate an entire series of events (open a file, update a client matter, send a message) with the appropriate permissions.
Let’s make this real: a medical report arrives
Pretend for a moment that you’re a paralegal at a law firm that specializes in workers’ compensation. An AME (Agreed Medical Evaluator) report shows up in your inbox first thing in the morning. Someone on the team has to process it: identify the document, find the correct matter and save it there, pull out the key findings, figure out what changed, check for any deadlines, and notify the right lawyer who is managing the case.
That is a lot of process activities before anyone drafts a letter or a pleading. Some of the activities are clerical, and some may require legal judgment. Some of the processes you need to follow may be buried in a case management system, but often the real process and exceptions are only known by the person who has been doing these types of reports for many years.
Now step back and imagine the whole sequence of events as an operating map. Step 1: classify the report. Step 2: extract the findings. Step 3: compare them with the official record. Conflicts or missing information can send the work down an entirely different path than the standard process. Deadlines create new review tasks. A lawyer on the case has to approve any strategy changes or documents that get produced as a result of this process.
This is graph engineering. You don’t give one giant instruction to your favorite AI model that says “handle this report.” Instead, you define a set of agent roles and processes that work together across this entire piece of work. This is really how good firms operate.
Your firm’s operating knowledge is the real asset
Two different firms can subscribe to Claude or ChatGPT and use the same underlying models. The difference between them isn’t having the account with the most advanced AI model - it’s how the firm actually uses the capabilities that model provides.
Firm A may give everyone a subscription and a set of sample prompts. Firm B maps out what happens after a demand letter arrives, a deposition completes, or when a client goes quiet. It documents where to check different sources, what exceptions look like, and who has to approve things to move forward, and importantly, what their AI system must never do alone.
Firm B is turning their operating experience and expertise into a map that their firm can continually test and improve. The underlying models will continue to improve and change every few months. That operating map belongs to the firm and is what sets them apart.
There is a real “people” issue here too. Your firm’s knowledge and expertise walk out the door every single day (and you hope it comes back tomorrow!). Most firms lose that knowledge and expertise when a lawyer or staff member leaves. It’s often knowledge about the smallest decisions that keep things from going sideways. Graph engineering gives a firm a way to capture and use that knowledge.
What does this mean for AI governance
For many firms, the first governance question is usually “how much autonomy should we give our AI?” To be honest, that’s not the best framing. Autonomy and authority should attach to an action, not your AI systems as a whole. Having Claude read a document is not the same as having Claude open the Chrome browser, log into a portal, and change a deadline. Having ChatGPT draft a client update is not the same as having it send it.
A well-designed graph engineering process forces a firm to examine those differences and create the right distinctions. A good process will let the AI move quickly through low-risk work, require another check when answers matter, and truly stop when the professional judgment belongs to a lawyer. These are the types of design choices that a firm can inspect and test until they are right.
California is moving in this direction. The State Bar’s 2026 guidance now directly addresses agentic AI. It states that greater AI autonomy requires stronger supervisory controls and verification. It is very clear about court filings: lawyers and law firms absolutely must not permit their AI systems to file documents or communicate with a court on their own.
Your firm doesn’t need a complicated technical system to address this. It does need to clearly define boundaries before AI tools touch things. A graph can help make that boundary visible.
Drawing boxes on a page is not the hard part
It’s easy to make this go wrong. A firm can map a bad process and make it run faster, or it can automate an exception that requires judgment and should have gone to a lawyer. It’s also important to keep the graphs current - a graph that isn’t updated will slowly become a very confident description of how you used to do things.
The hard work, honestly, is getting people to say what actually happens in a process. Not what the manual says or what the managing partner thinks - but what actually happens. It’s what the people who are actually doing the work do when the facts don’t fit the “clean” version of the process.
This takes time to do it right. Doing it right will create conversation, tension, and sometimes disagreements. Those disagreements already exist in the firm. Creating the graph shines a light on them and makes them harder to ignore.
I would not start with doing an entire case from end-to-end. A legal matter can go on for years and take hundreds of turns over the duration. If you try to map everything at once, this turns into a six-month committee project with no real end in sight.
Here’s what I would do on Monday morning
Pick a single event or process, not a whole practice area. Document what really happens when you get a new medical report, financial document, demand letter, executed contract, or deposition. Find something with enough recent examples that you can document the process and the exceptions.
Create a map of the work with the people who actually do it. For every step in the process, ask what information is needed, who makes the decisions, what can fail, and what requires escalation (to a more senior person or lawyer). The exceptions really matter because that’s where the process lives.
Test the map against 20 completed examples. The first time, run it in read-only mode. Document where it misses a step, sends the work to the wrong person, or produces an answer that no one trusts. Fix those failures before you give the system permission to change or send anything.
Graph engineering may be another short-lived concept. I don’t know yet. But the operating questions underneath this concept matter: how does work flow through your firm, and where should AI be allowed to touch it?
The models will change and continue to get better. The map of how your firm really works is the part worth keeping.
If you enjoyed this article, please share it with others!
Magnus decided it was a tug-o-war kind of day. I think he brought this rope toy to me a dozen times today. I have a rule - when Magnus brings me a toy - no matter what I’m doing - I stop and play with him.
The maintenance problem cuts deeper than staleness. A documented map becomes the reference everyone points to, so the informal workaround that used to happen quietly now looks like non-compliance, and people stop doing it or stop mentioning it. Which removes the adaptation that was keeping the process working. The 20-example read-only test would catch that if it's rerun periodically rather than once, since the interesting number is how the miss rate moves over a year rather than what it is on day one.