The Road to a Fully Automated Law Firm
Individual AI chats barely save a law firm any time
In many firms working with AI looks like this today. For every matter the lawyer opens a new chat, pastes in the facts, waits for the answer and copies it back into the file. With the next case the same thing starts over. By the evening thirty chats are open and for half of them nobody remembers which file they belong to.
The answers are good. The time saved is not. Anyone who uses a chat as their workplace remains the one setting the pace for every single step. They have to start every matter themselves, carry every intermediate result onwards themselves and file every outcome themselves. The work merely shifts from writing to copying. This is exactly the point where most law firms give up on AI again.
Full automation means the opposite of that. The flows trigger themselves and the lawyer only decides where a decision is genuinely needed. That is a direction and not a state you reach in a day. The road there always follows the same order though. First you break things down, then you build blocks and in the end you chain them together.
Break it down first, automate second
The most common mistake is trying to transfer your own working day one to one into a tool. "This is how I do it in the chat right now, so the automation should do exactly the same." That does not work.
That is why breaking things down comes first. Take a real matter from your firm and write down what actually happens. An email from the opposing side arrives. Someone reads it. Someone looks up the case number. Someone assigns it to the file. Someone decides who is responsible. Someone reads the content in substance. Someone drafts a reply. Someone checks the reply. Someone sends it. Someone files it. Someone records the time.
What felt like a single matter turns into ten steps. Some of them are pure mechanics and some of them are legal work. Only this separation shows what can be automated at all.
Every step becomes its own building block
In the next step each of these points becomes its own building block. A block has a clear trigger, a clear task and a clear result. It knows nothing about the rest of the chain.
For the inbox that looks like this. The first block reads a new message and assigns it to a file and a responsible lawyer. The second block reads the content and creates a draft reply or a counterproposal. The third block takes the lawyer's notes and works them into a new draft. The fourth block sends the approved letter and files it.
This separation has three practical advantages. Each block can be tested on its own, because you simply throw fifty old messages at it and look at the result. Each block can be replaced on its own, for example when a better AI model appears or a template changes. And each block can be reused. Assigning something to a file is needed in the inbox just as much as in the phone log or in the beA, the electronic mailbox every German lawyer is required to use.
The blocks mesh like gears
Each of these blocks is a partial automation on its own and still needs somebody to set it off. The gain only comes from chaining them.
For that the result of one block becomes the trigger of the next. The incoming client letter triggers the file assignment. The finished assignment triggers the draft reply. The approval of the draft triggers the dispatch. The dispatch triggers the time entry.
The triggers themselves are technically unspectacular. An automation platform such as n8n checks a mailbox at fixed intervals, reacts to an incoming call from outside or starts at a fixed time of day. Nobody has to press a button any more for the next step to happen.
The web interface holds the chain together
As soon as several chains run in parallel, the lawyers need one place where everything comes together. That is exactly what we usually build as a dedicated web interface in these projects.
Tasks are at the centre of it. Anything that leaves the firm is not sent automatically but arrives as a task for the responsible lawyer. That applies to every client email, to every counterproposal and to every legal document. The lawyer sees the draft, the occasion and the related file on one screen. They accept, change or reject.
Accepting a task is then a trigger in itself. The click on accept starts the next block. The lawyer works through a list instead of jumping between tabs. If the practice management software has an open interface, such as jur|nodes, these tasks are created right there and the firm does not need a second surface at all.
One matter from the email to the file
A complete example shows what this looks like day to day. Shortly after nine an enquiry from a new client arrives by email.
The mailbox check finds the message and starts the chain. The first block recognises that there is no file for this sender address yet. It creates a new file with the client's master data and attaches the enclosure. The second block determines the responsible lawyer based on the area of law. The third block immediately sends the client a confirmation of receipt including the information on who is taking the case. The fourth block creates a draft reply with the follow-up questions that are usually missing in this area of law. The fifth block turns that into a task for the lawyer.
Around half past eleven the lawyer opens her list. She sees the new file, the facts in three sentences and the finished draft. She deletes two questions, adds a third and clicks accept. With that the chain continues. The email goes out, the draft moves into the file, a follow-up in seven days is created and the time entry is prepared.
Before, this matter would have meant a dozen manual steps. Now it is two minutes of legal review.
Why custom code beats a chat with MCP servers
The obvious objection is that a chat with connected MCP servers could do the same. A language model uses such servers to access the mailbox, the calendar and the practice management software directly. Technically that is true. For recurring flows it is still the worse route.
A chat decides anew on every run which tools it uses in which order. That is a strength precisely when the task looks different every time. On the two hundredth coverage request of the month it is the opposite of helpful. The same matter runs differently each time, costs a lot of tokens on every run and takes considerably longer than necessary. Little of it can be retraced afterwards.
Code that is written once does the same step identically every time. It is faster, cheaper and when something fails the log points to the exact line where it got stuck. So we split the work. The language model takes the steps that need language understanding, meaning summarising, classifying and drafting. Ordinary code does everything else, meaning fetching data, filling fields, checking rules and filing documents.
Where this road costs effort and hits limits
This architecture is more expensive to build than a chat window. Breaking things down, the blocks and the interface are real software development. The first flow therefore only pays off after a few months. From the second and third flow onwards the ratio turns around, because a large part of the blocks already exists.
A chained automation also needs maintenance. When a template or an interface changes, one gear stops and the whole chain behind it stops with it. That calls for monitoring which reports immediately when a block is no longer running. And it calls for a responsible person inside the firm.
There are also matters that cannot be broken down into blocks. A client meeting that sets the strategic direction is one of them, as is the unusual set of facts that has not come up before. These cases should not enter the chain in the first place. They are cleanly recognised as exceptions and go straight to the lawyer.
And full automation never means that nobody looks at anything any more. Deadlines and legal assessments stay with people.
How to start in your own firm
Pick a single matter with a high frequency and break it down completely on paper. This step costs an afternoon and decides whether the whole project succeeds.
After that build only the two or three blocks that replace the most manual work in this matter. Let them run for a few weeks with an approval at every point. Only once you know the actual hit rate do you chain the blocks together and remove the approvals where the results are unambiguous.
Pay attention to where the data sits from the very first block. Client data belongs on a server in Germany or in the EU. How professional secrecy, data processing agreements and the choice of AI provider fit together is described in detail in our post on automation in the law firm.
Would you like to know how far a particular flow in your firm can be broken down? Write to us. We will go through the process with you and your team and tell you honestly which steps are worth it and which are better left to people.
