The interface is no longer the point

Most of the time, you don’t actually care about the tool, I certainly don't.

You care about what it holds. Tasks, deadlines, documents, relationships, status. The interface has just been the only way to get at it.

That assumption is starting to break.

The interface stops being where work happens

Once systems can be read from and written to reliably, the interface stops being the centre of gravity. It becomes one option among many rather than the place work happens.

Instead of navigating a tool, you declare an outcome:

"Push the filing deadline back two days and notify the team"

"Show me everything at risk this week across all open matters"

That change is more fundamental than it looks, as you’re no longer operating software step by step, instead you’re defining what should happen, and something else, an orchestration layer or agent, is responsible for executing it across systems.

At that point, most software stops behaving like a destination and starts behaving like infrastructure.

An example

Take a fairly typical mid-market cross-border matter.

Documents sit across two internal systems and a client portal
Approvals happen over email
Tasks are tracked in a project tool or spreadsheet
Deadlines are maintained separately, often manually

Now ask a simple question: what’s currently at risk, and why?

Today, that means checking multiple systems, interpreting inconsistent statuses, reconstructing context from emails, and forming a view manually. The answer exists, but only after effort.

In an infrastructure model, you expect a coherent answer immediately. That expectation only holds if the systems underneath can support it.

Legal isn’t unique, but it’s exposed

Fragmentation isn’t new in legal. What changes is the tolerance for it.

Once you expect systems to be queried and acted on as a whole, fragmentation stops being an inconvenience and becomes a structural problem.

You’re no longer working around systems, you’re depending on them collectively, which means trusting that a task update in one system, a deadline in another, and an approval buried in email can be interpreted as a single, coherent state.

That’s where most setups start to strain.

This raises the bar for applications

This isn’t a move away from applications. It’s a move towards better ones.

When you stop relying on the interface, you also lose the ability to correct things manually as you go. You’re trusting that the system behaves predictably when accessed programmatically, which raises the standard for how that system is designed.

Go back to the same question: what’s at risk this week?

That depends on things most systems treat loosely:

Deadlines need to be consistently defined
Dependencies need to be explicit
Statuses need to reflect reality rather than habit

If those things aren’t true, the answer won’t just be incomplete. It will be wrong in a way that looks credible because the UI used to absorb that inconsistency.

Now the system itself has to carry it.

Where structure breaks down

It’s easier than ever to build something that looks like a working product. A UI, basic workflows, and some form of persistence can be put together quickly, and that speed is genuinely valuable when you’re exploring ideas or validating a workflow.

The problem starts when that early structure becomes the system people rely on.

Because what isn’t being built at the same pace is the data architecture.

Good structure forces decisions early:

What exactly is a task?
How does it relate to a matter, a document, a person?
What states can it move through, and what do those states actually mean?
What happens when something changes?

Fast built systems tend to defer those decisions. You end up with loosely defined objects, optional fields carrying too much meaning, and relationships that exist in practice but not in the schema.

That’s manageable while a human is navigating the system and filling in the gaps, but breaks when something else depends on it.

AI doesn’t compensate for that, it will make it more obvious.

A person can work around inconsistencies, but a system acting on your behalf treats structure as truth.

That’s how you end up with incorrect actions taken with confidence.

Adoption starts to change shape

Adoption has traditionally meant getting people into a system, training them, and changing behaviour over time.

If interaction shifts to declaring outcomes, that model changes. The interaction layer adapts to the person rather than the other way around, and the underlying systems are integrated into that flow instead of replacing it.

Multiple systems still exist, however they're just no longer competing to be where work happens.

The risk moves, it doesn’t disappear

This is where the model becomes more complex rather than less.

If systems are being updated and actions are being triggered on your behalf, governance can’t sit purely in UI constraints or static policy documents. Most governance frameworks in legal assume a human is directly interacting with a system, reviewing, deciding, and acting.

That assumption breaks here.

Now you need to tie actions back to intent:

What was requested
What was executed
What constraints applied at the time

All of that needs to be visible and traceable.

The challenge is that most organisations don’t yet have a way to enforce those controls at the point actions happen, across multiple systems, in real time.

This isn’t just a gap in policy. It’s an architectural one.

A simple test

Take any system you rely on and ignore the interface.

Can you understand the data model without it?
Can you safely read from and write to it?
Can you trace what’s happening over time?

If not, it’s still a tool you operate.

If yes, it’s starting to behave like infrastructure and that also makes it a very different kind of procurement decision.

We’ve spent the last decade optimising how people interact with software, however what matters now is how software behaves without them.

The systems that hold up will be the ones designed with structure, state, and control in mind from the start.

Everything else will work, until something depends on it...and something will.