Every legal tech vendor demo in 2026 ends with an AI module, and most of them are impressive for about the first 15 minutes. The problem is that feature-by-feature comparisons of vendor AI offerings are unlikely to predict which tools will hold up over the next three years. The underlying models are changing too fast, the integration surfaces are still maturing, and the workflows that matter most to any given legal department are specific enough that no vendor can anticipate them all in advance. What looks like a competitive advantage today may be table stakes in 18 months, which means the selection criteria that actually matter are those that determine how flexibly a tool can adapt as conditions shift.
The better question for Legal Operations buyers this year is whether the tool gives your team the ability to build the agents you actually need. Not the agents the vendor imagined when they designed their product roadmap, but the ones that solve the problems you encounter on Tuesday afternoon when a reporting deadline accelerates, or whenever a new regulatory requirement lands.
AI researcher, educator, and new addition to the Anthropic team, Dr. Andrej Karpathy, recently argued during a discussion at Sequoia Capital’s AI Ascent event that infrastructure increasingly needs to be designed with agents, not humans, as the primary consumers. That framing maps directly onto legal tech purchasing decisions.
The tools that expose open APIs, accept structured inputs from external orchestrators, and let you define your own agent logic on top of their data are the ones positioned to grow with you. Those that do not will become closed appliances running someone else’s product strategy.
Most Legal Ops buyers are still scoring vendors against the same RFP rubric they used five years ago: user interface quality, out-of-the-box feature coverage, implementation timeline, and cost. Those criteria remain relevant, but they miss the dimension that will matter most over the tool’s useful life. A polished interface solves today’s known workflow. A strong development surface addresses problems that have not materialized yet.
Vendors shipping off-the-shelf AI features are, borrowing Karpathy’s distinction between “vibe coding” and engineering discipline, raising the floor. They make basic automation available to everyone, which is useful, but it is not what separates a Legal Ops function that merely operates from one that compounds its capabilities over time. The teams doing their own builds on open platforms are doing the engineering work that preserves a quality bar above what any generic module can deliver. That is why a tool with an average interface and a strong development surface is a better long-term bet than a tool with a polished interface and a closed back end.
Every vendor has more requested features than they have the capacity to deliver, and the honest ones will tell you that. The question is not whether a particular workflow will eventually appear on their roadmap. The question is whether the tool is open enough for you or a partner to build it once the need is concrete. When evaluating that openness, start with the workflows where agent outputs are verifiable without human judgment. Invoice review against billing guidelines, rate compliance checking, deadline calculation, and data extraction from structured documents are domains where an agent’s output can be measured objectively and corrected programmatically. Less verifiable work, like strategy recommendations or judgment calls about litigation risk, will follow later, but the early wins that justify the platform investment will come from the verifiable tier.
Choosing a tool you can build on is only half the work. The other half is ensuring your team retains ownership of what gets built and why. During the same AI Ascent discussion, Karpathy argued that while execution can be delegated, understanding cannot.
Buildability lives below the interface. It shows up in whether the tool has a documented API that covers the full data model, whether events can trigger external workflows in real time, whether you can push structured data back into the tool without manual intervention, and whether the authentication model supports service accounts that agents can use without a human in the loop. Ask the vendor whether you can build an agent that reads from their system, makes a decision, and writes back, all without a user clicking anything. Ask whether their API rate limits will accommodate the volume an agent produces versus a human operator. Ask whether their data model is stable enough that an integration built today will survive the next two product releases. These are uncomfortable questions for some vendors, and that discomfort is useful information about how the relationship will evolve.
The buildability question lands differently across the Legal Ops stack. Matter management systems need to support agent-driven matter intake, automated field population, and programmatic status updates. E-billing platforms need to allow agent-based invoice review that can approve, reject, or flag line items without a reviewer opening a screen. Contract management tools need to accept agent-generated metadata and surface documents to agents through structured queries rather than only through a search bar designed for people. Document management systems need APIs that let agents file, tag, retrieve, and version documents the way a human would, but at machine speed. For each tool in the stack, ask the vendor the same set of questions, score the answers, and treat the resulting picture as a leading indicator of where the tool will sit in three years.
Choosing a tool you can build on is only half the work. The other half is ensuring your team retains ownership of what gets built and why. In a recent Sequoia AI Ascent discussion on agentic engineering, Karpathy observed that you can outsource your thinking, but you cannot outsource your understanding. If your Legal Ops team delegates both the design and the execution of its agent strategy to a vendor or a systems integrator without retaining the conceptual model of how those agents serve the department’s objectives, you will lose the ability to adapt as circumstances change. The design decisions, the workflow logic, the criteria for what constitutes a good outcome: the Legal Ops team should own them while the build team translates them into implementation. That ownership is what preserves institutional knowledge and keeps the agent portfolio aligned with the department’s actual priorities rather than drifting toward whatever is easiest to build.
A tool you cannot build on becomes a ceiling on your operations the moment conditions change, and conditions in Legal Operations change constantly. New regulations appear, matter volumes shift, reporting requirements evolve, and the work itself transforms as AI capabilities expand month over month.
The first half of the work is selecting the tools with open, agent-ready surfaces that let your team respond to those shifts without waiting for a vendor release cycle. The second half is building the internal muscle to decide what to build, verifying that agent outputs meet the quality bar, and maintaining the understanding that keeps the whole system coherent.
Selecting platforms with open, agent-ready architecture is only the starting point. The harder operational question comes afterward: which workflows should be automated first, where agent authority begins and ends, and who owns the logic governing how those systems operate over time?
The next article in this series examines the implementation process layer that sits on top of the technology itself, including the workflow rules, governance structures, approval logic, and operational design decisions that ultimately determine whether agent-driven Legal Operations systems produce defensible outcomes or simply faster activity.
Ken Callander is Managing Principal of Value Strategies LLC, a consulting practice that advises corporate legal departments on outside counsel pricing strategy. He previously served as Head of Legal Operations at Uber Technologies. He is a Certified Pricing Professional and holds a degree in Physics from Stanford University.
The post Why You Should Choose Legal Ops Tools You Can Build On (Part 1) appeared first on Above the Law.