There is a lot of discussion about what AI will replace in legal technology.
The better question is what each part of the stack should be responsible for as AI gets more capable. For document automation, the answer is now clear. It is moving from a standalone productivity tool to the execution layer of the legal technology stack.
The following are words from our Founder and CEO, Steve Hantos:
I should declare my interest up front. I run Tensis, the company behind Smarter Drafter. We build deterministic document automation and we have spent the last two years building for exactly the architecture I am about to describe. Read this knowing that. The argument stands or falls on its own.
For thirty years, document automation has meant taking a precedent, adding logic, collecting data through a questionnaire and producing a document. That capability is still required, but what has changed is what it is worth.
AI is very good at interpreting information, reasoning across sources and working out what should happen next. It is not well suited to being the final control point for producing binding legal documents where consistency, approved language and repeatability matter.
Anyone who has spent five minutes with a language model knows the same question asked twice will not reliably return the same answer, no matter how you tune the guardrails. Although that can be a feature in analysis, it is a defect in execution.
In a recent Legaltech Hub article, Mat Rotenberg makes the case that AI reduces the effort required to produce work while increasing the amount of work that then must be coordinated, checked and trusted. That matches what firms are telling us.
If every lawyer can produce more research, more analysis and more draft content, the bottleneck moves down the chain. Which output is reliable. Which version is authoritative. What has been approved. What happens next.
For legal documents that matters more than most other work product. There is a big difference between generating draft wording to help a lawyer think, and generating the final version of an agreement a client will rely on. The second must be accurate, appropriate and defensible.
This is the part the AI conversation keeps missing.
An automated legal template is an engineered asset. It holds approved clauses, decision paths, calculations, conditions, guidance and drafting logic. It is a record of decisions the firm has already made about how that document should be constructed, captured once and reusable indefinitely.
One of our clients described it better than I can. The experience of the most senior people in the firm can now be used by the most junior.
Firms are not short of drafting capability, AI solved that problem. Firms are short of a reliable way to operationalise what their best lawyers already know. Asking a model to reason through the same drafting rules on every matter throws that asset away and re-derives it, slightly differently, every time.
Capture the rules once, then let AI work inside that structure rather than continually rebuilding it.
The problem with document automation was never whether it works, because it has worked for three decades.
The problem was the cost of engineering and maintaining sophisticated templates. That cost set a threshold. That meant firms often automated only where volume or complexity justified the investment, and everything below the line stayed manual.
It is also why so much legacy automation is still running in law firms today. Not because it is good, but because replacing it costs time and people, and most firms are short of both. That presents a large modernisation opportunity sitting largely untouched across the sector.
AI changes the arithmetic. When agents can help build forms, generate logic, explain existing automation, find errors and assist with QA, the cost of creating and maintaining templates falls sharply. More documents clear the threshold. Migration off legacy platforms stops being a multi-year project.
It also moves the build capability closer to the people holding the knowledge. Knowledge lawyers and practice leads can maintain their own automations instead of queuing behind a technical team.
That is what we built Co-Builder for. AI assists the engineering of the automation, while the automation still runs deterministically. In other words, AI builds it, and determinism runs it.
A lawyer is asked to produce an employment contract for a new client.
An agent reads the matter, pulls the client and party details from the practice management system, checks the DMS for related documents and identifies the correct template. It works out what it cannot answer from the firm's own records: the award classification, whether there is a restraint, the notice period the partner agreed commercially.
It asks the lawyer those three questions and explains why each one matters. It does not ask the forty questions it already has answers for.
Then it calls the approved template through the automation engine. The engine applies the firm's logic and produces the document. Same inputs, same output, every time, in the firm's approved language.
AI handled orchestration and reasoning. The engine handled logic and execution. The lawyer kept judgment and approval.
We believe that this is a far better architecture than asking a language model to recreate the firm's legal position from scratch on every drafting request.
Determinism is not the right tool for everything, and pretending otherwise would be dishonest.
It is the wrong answer for genuinely novel work. If a transaction has no precedent, engineering an automation for a document you will build once is waste. Let the lawyer draft and let AI help them think.
It is the wrong answer for inbound documents. Reviewing the other side's contract, comparing versions, spotting risk and summarising positions is interpretation work. AI belongs there and deterministic tooling has nothing useful to offer.
It is the wrong answer during early exploration, when the lawyer is still working out the shape of the deal rather than producing the instrument.
The case for determinism is narrower than most vendors in my category will admit. It is also stronger than the current AI market allows. It applies at the moment a document stops being a draft and becomes something a client relies on. That moment carries the risk, and it is worth controlling.
Historically, integration meant pushing client and matter data into a questionnaire, so the lawyer did not rekey what the firm already knew, often delivered through bespoke connectors written for specific systems. That produces a tightly coupled application layer where every change becomes a project.
The model replacing it treats document automation as a service that other systems call. The caller might be an AI assistant, a workflow platform, a DMS, a practice management system, or an agent operating across all of them. Open protocols make that possible, and Model Context Protocol has become the practical standard.
The result is a loosely coupled stack where systems can be replaced without rebuilding the integration layer.
This is not a roadmap position for us. The Smarter Drafter MCP server is in production, and Smarter Drafter is listed in Claude's connector directory. An AI assistant can call our automation engine as a tool today.
The outcome here is that the user may never know they are using a document automation platform. They ask for something to be done. The right system is invoked at the right point.
The future legal stack will not be one platform that does everything. That is magical thinking, and it is common in AI conversations right now. Most firms have too much invested in what they already run.
The pendulum between single vendor stack and best of breed is swinging back towards best of breed, because specialised systems are becoming genuinely expert in their niche. The realistic end state is a connected stack of specialists. Some hold data. Some hold knowledge. Some manage workflow. AI connects and orchestrates across them, inside and outside the firewall.
Document automation sits inside that architecture as the mechanism for reliably producing legal documents from approved knowledge and structured decisions.
That is a much bigger role than helping a lawyer draft faster. It makes document automation part of the infrastructure. As AI increases the volume of legal work produced, trusted execution becomes one of the more important parts of the stack.
So here are five things worth doing now, whether or not you ever talk to us.
Work out which documents actually need deterministic execution. The list is usually shorter than firms expect and higher value than they expect. Client-facing instruments, regulated filings, court forms, anything where the same document goes out a hundred times a year.
Audit your legacy automation. What is it running on. Who can maintain it. What happens when that person leaves. Most firms cannot answer the third question.
Check whether your automation platform can be called by something else. If it can only be driven through its own interface, it will not survive in an agentic stack. Ask your vendor about MCP and API access and note how confidently they answer.
Decide deliberately where AI drafting output goes. Pilots have a way of quietly becoming the drafting system of record for client-facing documents. That should be an intentional decision, not a pilot drifting into production.
Put your knowledge lawyers close to the build tooling. The economics have changed enough that they can now own this. If it still sits with IT, you are leaving most of the value behind.
We are running an early adopter program for Co-Builder with a small group of firms working through exactly this. If you want to see how the architecture works in practice, get in touch.