What an AI assistant should do inside a law firm's software
The short answer
Inside practice management software the valuable work is not answering questions, it is making the stream of small updates that follow every court day: set the next date, record the hearing outcome, create a task, update an invoice. An assistant earns its place by making those changes when asked. Before a firm trusts it, it must act with the signed-in person's own access, show the real case and date before it changes anything, and leave a history that names who did it.
Spend a morning beside somebody running a litigation practice and count the screens. The next date for a matter came out of court, so it goes on the case. A hearing got adjourned, so the outcome is recorded and a new one scheduled. A junior needs a task. A client changed their phone number. An invoice went out, so its status changes. None of it is hard, and all of it is the reason the software feels slow: each one is a search, a screen, a form and a save.
That is the work an assistant inside the product should take on. Not explaining where the hearings tab is, but doing the thing the lawyer just said out loud: set the next date on the Sharma matter to the 14th.
The day is made of small updates, not questions
A live integration into a practice management product for litigation chambers settled at twenty nine actions, and the list is a fair picture of the job. Find a client, add one, update their contact details. Find a case, list them by status, open one, change its status, set its next date. See upcoming hearings, schedule one, record what happened, cancel one. Create tasks, move them along, delete and restore them. Search, raise and update invoices. Add notes. Track non-litigation matters. Look up courts and case types. And search the activity history, which matters more in a firm than almost anywhere else.
Read that list again and notice how little of it is a question. It is a stream of updates to records that already exist, and the updates come in bursts: after a day in court, somebody has six of them to make, and today they make them one screen at a time.
What it has to get right before a firm lets it touch anything
It acts as the person asking. Firms already decide who can see which matters and who can raise an invoice. An assistant running with an admin key throws that away. One running with the signed-in person's own access keeps it, because the product makes the same decision it would make for any other request from them. A clerk who cannot see a matter cannot get the assistant to see it either.
Every change stops for a yes, with the real details on screen. Before the next date is set, the lawyer sees which case, which court and which date. Before an invoice is marked paid, they see the client and the amount. A wrong date on a matter is how a hearing gets missed, so the confirmation is not politeness, it is the whole point.
Deleting is recoverable where the product allows it. The integration above has both a delete and a restore for tasks, and that pairing is worth copying: a person who says "delete the old drafting task" and meant the other one can undo it by asking, rather than filing a ticket.
Every action names a person. "Who changed the next date on this matter" has to have an answer, and the answer cannot be "the AI". When the assistant acts as the signed-in lawyer, the history already says who, the same way it would if they had clicked.
The failure to test for: two matters that look alike
Firms have clients with several matters, and parties who appear in more than one. "Set the next date on the Sharma case" is ambiguous the moment there are two. The behaviour you want is a question back, naming both. The behaviour you must rule out is a confident guess, because a date on the wrong matter looks exactly like a date on the right one until the day it matters.
That is testable before anyone relies on it. Put two similar matters in a test account, ask for the ambiguous change, and check it asks. Then ask for a change the person is not allowed to make, and check the product refuses it the same way it would if they had tried by hand.
Where it pays off first
After court. The end of a hearing day is the moment with the most updates and the least patience for forms: outcomes, next dates, tasks for the team, a note for the file. Saying it in one go and confirming each change is where lawyers feel the difference on the first day, and it is the easiest case to show a firm when you are selling the feature.
If you are deciding how to add this to your own product, the comparison of the ways to do it covers building it yourself as well, and the security page answers the question a firm will ask first: what stops it changing something it should not.
Common questions
What would lawyers ask an AI assistant to do in practice management software?
Mostly updates to matters that already exist: set a case's next date, record a hearing outcome and schedule the next one, create or close a task, change a client's contact details, raise an invoice or mark it paid, add a note. A live integration for litigation chambers covered this in twenty nine actions.
Can an AI assistant see matters a user is not allowed to see?
Not if it runs with the signed-in person's own access. Then the product makes the same decision it makes for any request from that person, so a clerk who cannot open a matter cannot get the assistant to open it either. An assistant using an admin key is the one to avoid.
What if it updates the wrong case?
Every change should stop on a confirmation showing the real case, court and date before anything is saved, and an ambiguous request, like a client with two matters, should get a question back rather than a guess. Both are worth testing in a test account before anyone relies on it.
Does it keep a record of what it changed?
It should, and the record should name the lawyer who asked, not the assistant. When it acts as the signed-in person, the product's own history already shows who changed what, the same as if they had clicked.
Keep reading
- How to let users take actions with AI in your app
Tools instead of retrieval, the user's own permissions instead of a service account, and why the hard part is reporting failure honestly.
- The best ways to add an AI assistant to a SaaS product in 2026
Documentation chatbot, build your own, or embedded action assistant: the one question that decides between them.
- Your agent works. That was never the hard part.
The demo takes a weekend and the sign-off takes a quarter. The identity mistake that causes it, and the day our own test suite turned out to be pointing at production.
Verb is this, built. An AI assistant you embed in your SaaS with one script tag: it calls your own API as the signed-in user, confirms before it changes anything, and logs every action. Free to build and test.