The Automation Is the Part You See

If you run a firm you have probably been shown something like this before, and it probably did not survive contact with a real file. That is a reasonable reason to stop reading. Here is why you might not.

Most demonstrations of AI in a law firm show you the same thing. A screen where work happens by itself. Emails going out, boxes ticking, a number going up.

That is the easy part. I built the one in our demonstration in a few days. That is not a boast, it is the point. The visible layer is no longer difficult.

The hard part is everything underneath it, and almost nobody shows you that, because it is not visually impressive and because most vendors have not built it. When a firm asks who is accountable when this thing gets something wrong, the honest answer for a lot of tools on the market is nobody in particular.

This piece sets out what sits beneath a running automation in our work, what it does to a firm's numbers, and how to judge one you already have.

A minute and a half, silent, a fictitious firm. Every screen was produced by the system as the work happened. The longer version, three and a half minutes, sits on The Build.

What it does to the firm first

A partner reads this for one reason, so here it is before the machinery.

Hours back. Chasing documents, logging what arrived, checking what is still outstanding and telling the client what happens next is unbilled time. Every fee earner does it, nobody records it, and the firm pays for it out of margin. The system does that work at seven in the morning and again at six in the evening. The people who bill get the hours.

Cost out. The work does not disappear, it moves. From a fee earner's day to a system that runs for a fraction of the cost of the hours it replaces, and runs on Sunday.

Files that turn faster. A file cannot open until everything is in, and it cannot bill until it opens. Every day a document sits unrequested is a day further from the invoice. Chasing on a cadence that never slips shortens the gap between instruction and billing, which is the gap where the firm's cash is tied up.

Fewer things falling through. Every open item is either being chased by the system or it has a named person against it. Never neither. The delays that actually cost firms money are not the ones somebody is working on. They are the ones nobody realised they owned.

That is the business case in four lines. The rest of this piece is about why it holds up when a regulator, an insurer or a client asks how.

For the person who will actually run it

If you are the practice manager rather than the partner, here is what changes in your week.

You stop composing chase emails. You stop diarising follow ups and hoping you remember. You stop being the person who discovers on Thursday that nobody asked for the bank statements. You stop assembling a record of what happened when somebody asks, because it already exists.

You start reading a short list each morning of what the system did, what arrived, and what is waiting on a named person. You start having time for the matters that need judgement rather than the ones that need chasing. And when a client rings, you know exactly where their file is without opening it.

Nothing you use today is replaced. This runs alongside the systems the firm already has.

The six layers

One, the written scope schedule

This is the foundation and it is a document, not software.

It names every task the system performs, every mailbox it reads, every field it writes, and everything adjacent to that work which it does not touch. It is agreed before anything is built and it changes only by agreement.

A firm cannot supervise what it cannot describe. If a partner is asked what the system does and the answer is a shrug and a vendor name, the firm has outsourced something it is still accountable for.

Scope written down is also scope that cannot quietly grow. It protects the firm from a system that gradually starts making decisions nobody agreed it should make, and it protects us from being blamed for work we never took on.

Two, the data processing agreement and hosting

Every automation that touches client correspondence is processing personal data on the firm's behalf. That is the legal basis on which the whole arrangement stands.

So there is a data processing agreement in place before anything runs, naming what is processed, where it sits, who else is in the chain and what happens to it when we part. Every sub-processor is listed. If we add one, the firm is told.

The SRA's warning notice on artificial intelligence, published this August, puts the expectation plainly. Client confidentiality survives the introduction of a new tool, and the contractual, technical and organisational safeguards remain the firm's responsibility whoever built the software. A firm that cannot say where its client data goes has a problem regardless of how well the automation performs.

Three, the tier sheet

This is the one that matters most, and it is the one nobody asks about until something has gone wrong.

The tier sheet states what the system is permitted to decide. Three tiers, set once, with the firm.

Tier one is everything carrying regulatory liability the firm cannot delegate. Risk ratings. Source of funds conclusions. Whether a document is good enough. For these the system does not decide, does not recommend, does not rank, does not score and does not draft the reasoning. It has no field in which to record such a decision, which is a stronger safeguard than a policy telling it not to.

Tier two is work a person signs off. The system prepares it and holds it until a named individual approves it.

Tier three is low consequence action the system takes on its own. Chasing. Logging. Counting what arrived. Sealing the record.

The SRA notice makes the same point from the other side. Professional responsibility cannot be transferred to a tool. A system with no field for the judgement is the practical shape of that principle.

We built the risk assessment screen this way deliberately. The system gathers the inputs, presents them against the criteria the firm wrote, and flags what does not reconcile. The rating stays empty. The rationale stays empty. The matter cannot progress until a named person completes both. The firm's own scale sits on screen beside the empty field, and the system has selected none of it.

Four, named person access and control

Every action in the system has an owner. Not a role, not a team, a person.

Every item on a matter is either being chased by the system or it has a named individual against it who is reviewing it. Never neither.

It also means the system yields. When a person takes something on, the system stops chasing it immediately and permanently. A client who has already sent something to a fee earner does not then receive an automated reminder asking for it again. That single behaviour prevents most of the embarrassment firms fear from automation, and it is the behaviour most tools on the market do not have.

The SRA notice holds supervisors accountable for output they have not checked. Named ownership of every item is how a supervisor knows what there is to check.

Five, the monthly record

Audit logs ship with every case management system on the market. That is not what this is.

An audit log is raw material. Somebody still has to sit down, work out what happened, assemble it into something readable and stand behind it. That assembly, done under time pressure when a regulator or an insurer is asking, is where the real cost sits, and it is never in the budget.

We produce the record. The firm does not assemble it. It sets out what the system touched, in sequence, with timestamps, and the named human decisions inside that scope. Each line is sealed against the line before it, so a row cannot be altered, inserted or removed without every row after it showing the break. Nobody at the firm can quietly edit it, and neither can we.

It is scoped honestly and the scope is printed on it. It records what the system touched. It does not cover the matter file, it does not answer the SRA, and it does not evidence the firm's compliance. It evidences one thing precisely, which is that a named person made every regulatory judgement, at a timestamp, against the firm's own criteria, and that the system never suggested the answer.

The record is the firm's. If we stop working together it stays with them.

Six, the running automation

The part you see.

It reads the client mailbox, matches replies to matters, ticks off what has arrived, chases what has not on a cadence that suits each item, and escalates when its allowance runs out. It counts attachments without opening them. It tells you whether the client details you already hold appear in a document, and it never tells you whether that is good enough.

It runs before the office opens and keeps working after it closes, which is when a good deal of client correspondence actually arrives.

On its own it is a script. On top of the other five it is a control.

If you already have something

A number of firms already run some automation, usually a reminder feature inside the case management system or a bot from a vendor. This piece is not telling you that was wrong.

It is giving you five questions to put to whatever you have.

Is there a written scope, and does it say what the tool does not touch. Is there a data processing agreement naming every sub-processor. Is there anything stating what the tool is and is not permitted to decide, and can it physically record a judgement it should not make. Does every item have a named owner, and does the tool stop when a person takes over. And when somebody asks what happened, is there a record already assembled, or does somebody have to build one.

If the answer to all five is yes, you have a governed automation and you do not need us. If the answer to two or three is no, you have a script with a firm's name on it, and it is worth knowing that before somebody else points it out.

We assess automation as well as building it, and we never assess what we built. If what you already run needs checking by somebody who has no stake in the answer, that is a separate conversation and a separate team.

Why us

Three things, stated plainly.

I spent the years before this delivering technology change inside regulated financial institutions, where the question was never whether a system worked but whether it could be defended afterwards to a regulator, an auditor or a board. That is the discipline these six layers come from. It is not a product feature, it is a habit.

We build and we operate. The system is not handed over with a manual. We run it, we produce the monthly record, and we are the named party in the data processing agreement. If it goes wrong there is a person to ring, and it is me.

And we never make the judgement we automate. That line governs everything in this piece and everything we build. A vendor whose tool makes the judgement has sold the firm a liability behind a clean interface. We have designed ours so that it cannot.

What it takes

We aim for weeks, not months. Built on the systems you already use. Operated by us, not installed and left. The scope schedule, the DPA and the tier sheet are agreed before anything runs, and the first month's record is produced at the end of the first month.

There is no price on this page because the price depends on scope, and scope is the first conversation. Nothing on this site is gated and there is nothing to sign up to.

A note on what this is

Everything described here is how we build. The demonstration alongside this piece uses a fictitious firm and a fictitious matter, disclosed on screen, and every screen in it was produced by the system as the work happened.

If chasing is where your fee earners' unbilled hours go, there are three things you can do next. Each asks a little more of you than the last.

Watch the demonstration. A minute and a half, a fictitious firm, every screen produced by the system.

Have the next piece sent to you. One a month at most, and nothing else.

Or book the walkthrough. Thirty minutes, on your own matters, with no slides, and you will know inside the call whether it fits.

None of those requires the others, and none of them requires a form beyond an email address.

Umer Javed Founder, Agentisk