Law firm CIOs used to be asked “which DMS?” Now they’re asked “what’s our AI architecture?”, and it’s a harder question. The stack is being reshaped around AI faster than any previous shift, budgets are being realigned mid-cycle and every vendor conversation carries a new anxiety: are we buying capability or buying lock-in?

We hear the same questions from CIOs across the market. How do we go deeper with AI than the headline tools? How do we gain independence from any one vendor, especially with token-based pricing? What context does our AI actually have? And how do we roll out fast enough without every deployment needing its own governance review?

These sound like five different problems. Underneath, they’re one problem: the stack has an intelligence layer but no transaction layer for it to work in.

Depth is a data problem, not a model problem

“Are these models practice-area deep enough?” is usually the wrong question. Model depth converges; every vendor’s system reads a facility agreement competently. What varies is what the model can reach. AI is only as deep as the context available to it, and practice-area depth on transactions comes from structured deal data: the live CP list, the signing status, the party and deadline relationships.

That data doesn’t live in the AI tool and never will. It lives in the platform where deals run. In architectural terms, the transaction layer sits underneath every AI tool you buy and determines how useful each one can be.

Independence comes from open standards

The vendor-independence question has become acute as token-based pricing spreads. Firms locked into one AI vendor’s ecosystem have no leverage when the pricing model shifts.

MCP (Model Context Protocol) changes that calculation. It’s the open standard the AI ecosystem is converging on for connecting agents to external systems. A transaction layer that speaks MCP serves any capable tool the same way: Harvey today, Legora tomorrow, a firm-built agent next year, all through one connection. No bespoke integration per vendor, no rebuild when you switch.

That flexibility doubles as negotiating position. A firm whose transaction layer is vendor-neutral can swap models without swapping infrastructure. Legatics runs a MCP server today: AI tools can read and act on live matters through it. (Precision matters here, and CIOs are right to probe exactly what any vendor’s connectivity does in practice.)

One connection instead of n integrations

Rollout speed is where infrastructure quietly pays for itself. The point-solution path requires each AI tool to be integrated, security-reviewed and governance-approved separately. Stack complexity grows linearly with every purchase, and each rollout starts from zero.

The infrastructure path inverts this. One MCP connection makes the transaction layer available to every current and future AI tool, and every new tool inherits the same permissions, audit trail and scope controls rather than needing its own framework. The governance review happens once, at the layer, instead of once per vendor.

For a CIO fighting for rollout runway, that decides whether an AI program accelerates or queues.

The budget conversation

AI budget lines are under pressure precisely because they’re hard to defend: experimental spend on tools whose value is hard to measure and whose vendor might not matter in two years.

Infrastructure spend is defensible in a way experimental AI spend isn’t:

• It makes the AI budget you’ve already committed perform better, because every tool gains deal context
• It doesn’t expire when the vendor landscape shifts, because the layer is neutral
• It’s measurable, because AI activity inside a transaction platform is visible, auditable and attributable to real matters
• It pays for itself on the human side alone: faster deals, less admin, better client experience, before any AI value at all

Conclusion

A workable answer to “what’s our AI architecture?” has three parts: an intelligence layer you should expect to churn eventually, a transaction layer that holds context and governance and should not churn, and an open standard connecting them. Get the middle layer right and the rest of the architecture becomes a set of low-stakes, reversible choices.

The final post in this series looks at timing: why the firms assembling this stack in the next 12–18 months will set the terms for the decade after.

Want to pressure-test this against your stack? Book a session with our team; bring your architecture diagram and your hardest questions.