In the world of AI, keeping up can be exhausting. Every week, a new model release, which unlocks a new feature, which causes new governance problems. Your long-standing vendor releases a new AI feature set which at first glance is indistinguishable from the AI agent you built yourself last week. Budget holders go round in circles trying to make a business case for a product that in 6 months’ time will not only have an entirely different feature set but also be priced on a consumption basis for which there is no costing model.

Everyone thinks they’re falling behind when they’re not - they’re just focussing on the wrong things. Instead of comparing indistinguishable feature sets, model benchmarks and “x just killed y” commentary, firms can stay ahead by building longer-term assets they own and control.

The sole purpose of nearly every release from every vendor is to burn tokens on their platform rather than their competitors’. They will deploy engineers, provide generous year-one pricing and throw up billboards in order to do this. And it’s compelling - all the hard stuff (implementation, risk and compliance, building skills and workflows, training and adoption) is taken care of with one signature. This is unquestionably valuable, and provides a shortcut to parity with peer firms.

But, unless you’re careful, your AI strategy will be indistinguishable from your vendors’ roadmap. You’re wide open to changes in pricing, and you lose control over any firm-specific features you want to build. And what happens when your clients have exactly the same software with the same configuration as you do?

Client-centric deployment

Legal departments want transparency from their law firms. Yes, they want to know how their law firms are using AI to both justify spend and to educate themselves on how they can better leverage AI. Legal departments are growing impatient with half-baked answers to diligence questions and are increasingly taking matters into their own hands (literally and figuratively) by in-housing work, using alternative suppliers and using AI to scrutinise invoices. This unhealthy relationship is not easy to come back from.

Firms who can clearly articulate how their AI investment benefits their customers will fare well over the long term. To get there, they need to understand how to better leverage the information they already hold, know what works and what doesn’t and how technology investments connect to the economics of different matter types.

Building durable assets in the data layer, integrations, skills, and measurement frameworks provides the best means of understanding how delivery should evolve to meet the expectations of the modern GC.

Data

People pay for law firms because they have done the work many times before. They know what’s likely to be accepted, how to navigate tripwires, and how much it’s likely to cost. The opportunity is to move this information out of meat-ware into institutional data, provide the right incentives to automate some/all of the workflow, and to measure what works and what doesn’t.

A huge secondary market has emerged where defunct startups are selling their digital archives to AI labs. This data is so valuable because within the Slack channels, codebases, Jira tickets and internal documents there lies a goldmine of real human reasoning. Brokers are making millions a week selling this data, and some startups’ data is more valuable than the company itself.

There are few repositories richer in human reasoning than a law firm data set. 20 years of data on how disputes are settled, how contracts are agreed and on what terms across multiple sectors and disciplines, and the activity of every lawyer in the firm broken down into six-minute increments. Frontier labs would crawl over hot coals to get at this data.

And yet look at how most law firms are leveraging this information and at best you have a full-text search to find information. A common pain point is people and experience data, which is typically spread across the HR systems, unlabelled Word documents, LinkedIn profiles and last year’s legal directory submissions. Matters are rarely labelled with enough granular detail to be findable without disturbing the practice lead. Often a new system brought in to help has too narrow a focus and simply becomes another incomplete data silo to manage.

The challenge is to turn disconnected data set up for humans clicking, typing and knowing where to look into one ready for agentic access: an end-to-end centralised firm-wide data strategy built from the ground up.

Bring data together properly and the firm can identify which lawyers have handled comparable matters, what they actually did and which experience can be re-used. This can be used by whichever models or platforms you happen to be renting at the time.

For data to work effectively for agentic access, centralising data is only part of the job. What is needed is the context and meaning that makes it useful: business definitions, relationships, metrics, business logic and access rules defined once and reused by every AI system in the business. This is known as the semantic layer.

Meaning changes across departments. For example, an “active client” can mean different things across the org. Finance may see it as someone billed last year, Business Development as one that recently attended a webinar, and a Partner as one they are in active discussions with to take on a new piece of work. A semantic layer captures these different definitions, and the different relationships between data sets so an agent can apply the right meaning, avoid ambiguity and provide reliable results.

  1. Collect datae.g. people data from HR, finance, DMS and experience records
  2. Clean and connectReconcile names and identifiers within a common schema
  3. Define meaningAgree definitions, relationships and metrics
  4. Use across tools and AIEmbedded reporting and agent workflows

Permissions, ownership and quality checks apply throughout

There is a growing ecosystem of platforms that turn a multi-year project into a manageable one that delivers incremental value. If you are willing to invest in a data team you can build it yourself. Microsoft Fabric and Azure Databricks are an increasingly common platform combination. Alternatively, providers such as Entegrata can accelerate implementation with prebuilt connectors, a legal-specific data schema and reporting models, reducing time to value.

Integrations

Agreed standards help entire industries scale. The introduction of MIDI in 1983 brought about the entire dance music industry we know today. USB helped manufacturers build products for a much larger addressable market. Anthropic’s MCP standard is equally significant and allows firms to pull together different products, platforms, data layers and deterministic workflows and features into a working system unique to the firm.

MCP connections are straightforward to set up, but unless designed properly, multiple connections can get expensive and degrade in quality quickly. With too many MCP connections, AI tools spend excessive tokens processing tool descriptions, generating calls and compiling results, compounding with every follow-up question.

  1. User asks a question
  2. Model receives prompt and tool definitionsToo many definitions4 servers × 30 tools = 120 definitions, every turn
  3. Model selects tools and generates callsOverlapping toolsUnclear descriptions, wrong or redundant calls
  4. Application runs calls through MCP servers
  5. Results enter the model's contextUnfiltered resultsOversized results fill the context
  6. Model answers or requests more calls↺ loops back to tool selectionRepeated attemptsSame data searched again, cost compounds

Many setups load every tool definition upfront: names, descriptions and parameters all take up valuable space in the model’s context. Connect four MCP servers with thirty tools each and the model is parsing 120 tool definitions before it even gets to the user’s prompt. Couple this with an expensive frontier model and it’s a token tyre fire.

Poor MCP architecture such as multiple overlapping tools, poor authentication and unclear descriptions can produce oversized results, repeated searches across the same data and security issues.

Enter the MCP gateway. They sit between your AI applications and MCP servers, and provide a single place to authenticate, enforce tool permissions, limit requests by user/group and track token usage. The more advanced tools allow you to provide custom tool descriptions to allow for firm-specific language, remove ambiguity and overlapping tool calls.

This is an increasingly important part of firms’ AI strategy, and no one vendor is going to do this for you. They can only control their own MCP servers and don’t have the field of view to pull things together into a coherent architecture optimised for quality and cost.

Skills

Major AI companies are keen to get in on the action. Claude for Legal, Astra for Law, Gemini Enterprise for Legal and most recently Copilot for Legal all share the same architecture. Each is a collection of legal-specific skills and connectors bundled together to ensure tokens get spent on their platform. Subscribing to one of these makes sense if you’ve already deployed one of the underlying platforms, but if you haven’t, you’re essentially reducing the selection of models available to you for a set of skills you can, and should, be building yourself.

Skills, or playbooks, are a natural language set of instructions that an agent uses to get a task done: where to draw data from, what questions to ask, what connections to use, how to format the output and when to triage to a human. They’re effectively the modern equivalent of a know-how document, and should be considered extremely valuable IP.

There are a growing number of publicly available skills firms can draw inspiration from. Skills in AI giants’ “x for legal” are available publicly on GitHub (look here and here). Variations of “contract review against a playbook” feature in all of them. These skills can flag deviations from preferred and fallback positions, propose redlines and flag issues for escalation. The crux move here isn’t the skill, it’s analysing the positions, thresholds and instructions from prior contracts, and re-using them across matters.

There’s a reason LegalAI vendors have so many qualified lawyers on staff. They have been through a law firm’s training programme, have experienced the messy reality of the legal process, and are well placed to automate it as a result. Legal engineers are hired from law firms to build skills and workflows, and make up about 15% of their total workforce.

In order to differentiate, law firms are building out their own stack in parallel to legal AI vendors. Baker McKenzie deployed a series of specialist harnesses in addition to their other subscriptions that are built and owned solely by them. Latham have invested in their own hardware, and Kirkland partners with Palantir to build out their own platform and ontology. LegalAI tools have been useful to get going, but they’re not the final destination by any means.

Owning the skills infrastructure is one of the highest-value assets a law firm can build. There is a solid argument that there is more value in this than there is in the collection of WIP and final work product contained in the DMS. Up until recently there hasn’t really been a good, reliable way of curating and maintaining these skills, like you would traditional knowledge documents.

There are options, though. Processes can live in a version-controlled repository, with version history, review and approval before changes are released (some experiments hold skills files in the DMS and reference them via MCP). Google released the Open Knowledge Format (OKF), which is particularly well suited for playbook libraries. Dedicated platforms are emerging too. Tessl offers skill versioning, governance and evaluation, while open-source projects such as iFLYTEK’s SkillHub provide a self-hosted registry for publishing, reviewing and distributing skill packages. Anthropic released a guide on managing skills for the enterprise you can see here.

Despite the high-value nature of the task, building a skills infrastructure will never get column inches. Skills and processes are the proprietary knowledge of the firm, and as such, not something you can sell.

Measurement

Firms need to think a lot less about what the industry is doing and a lot more about translating tech investments into additional client value. Law firms by and large do a fairly terrible job of this. A recent Deloitte study found that only 4% of legal clients have seen any measurable benefit from their suppliers’ use of AI at all.

The tension created by the introduction of tech that specifically reduces billable hour revenue remains problematic, and clients are getting increasingly impatient waiting for their suppliers to resolve it. Diligence on law firms’ AI use is increasing in sophistication via a firm questionnaire down to the task level and AI spend management tools strike out invoice line items that they deem should be done by AI.

Firms that have invested time building up a measurement framework are considerably better equipped to guide clients on effective (and just as importantly, ineffective) use of AI. They have the pricing metrics to be able to move to AFAs without shouldering the lion’s share of risk, and can identify adoption trends that would otherwise be hidden from view.

Effective measurement starts with a reliable baseline. Establish margin indicators such as gearing, write-offs, matters per fee earner, and per-phase metrics. Then measure AI usage against client, matter, phase and task. This can be done by a simple opt-in check box on the time recording input recording AI usage. Enrich this with passive collection of usage patterns by collecting the audit logs from each application. Time capture platforms are now collecting AI usage, and governance tools such as Truth Systems’ Charter now capture usage statistics from multiple systems and bring them to life on a centralised dashboard. Compare time saved, verification, and the quality of the output across similar groups, users and tasks.

Once you have the measurement data in place you can use this information to clearly articulate where AI is being used most effectively and on what matters. You see instances of where it actually slows things down, how the shape of the work changes over time, if additional time spent on quality control reduces write-offs. You can then educate your clients, reprice work, add technology disbursements, or lean into a particularly profitable matter type. Without it you’ll be stuck with the increasingly threadbare responses of ‘it’s early days’ and ‘we’re still experimenting’ whilst matters quietly get sent to another panel firm.

Conclusion

You don’t need to continually try and predict the future to make progress. Models and vendors will come and go. Pricing mechanisms will change. Technology will continue to evolve.

Start with one useful workflow, pull data and integrations and test plans together to make it work. Document the process and measure whether it delivers a better result. Build out firm-owned assets of data, integrations and skills with each workflow.

Build durable assets. Rent the rest.