Workflow, copilot or CLM
Three things are being sold to legal teams under names that overlap, and the confusion is expensive. It costs a team a licence it does not need, or a year spent expecting one kind of tool to do another kind of job. This page is my attempt to draw the line plainly. I sell one of the three, so read it with that in mind.
A copilot answers
You ask it something, it produces text, and you decide what to do with the text. The best of them are very good, they are getting better quickly, and Harvey, CoCounsel, Lexis+ with Protégé, Legora and vLex Vincent are the names most often in the room. In Türkiye, local names include Jupytr, LegalEngine and SmartHukuk.
A copilot is the right answer when the bottleneck is a lawyer facing a blank page or an unfamiliar area. It is the wrong answer when the bottleneck is that nobody knows who owns the request.
A CLM holds contracts
It stores agreements, moves them through approval and tells you what you signed. Ironclad, DocuSign CLM, Icertis, Agiloft, Sirion, Juro and LinkSquares are the field.
A CLM is the right answer when your problem is contracts as a portfolio: renewals, obligations, and where the signed version is. It is the wrong answer when your problem is the queue of everything that is not a contract.
A workflow carries the file
It is the path a matter takes, drawn as named stages, each with an owner, a clock, a mandate for whatever software touches it, and a record. That is what LEXSAS designs. It is neither an independent information source nor a repository; it can use the assistant and the contract system as tools.
It is the right answer when the problem is not the drafting and not the storage, but the handover: who decided, on what basis, and can you show it later. It is the wrong answer when what you need is a database or a better draft, and I will say so on the scoping call.
The comparison
| Aspect | Copilot or assistant | Contract lifecycle system | Designed workflow (LEXSAS) |
|---|---|---|---|
| What it is | A tool that answers and drafts on request | A system of record for agreements | The path a matter takes, drawn as named stages |
| Unit and scope of work | One person per session; a prompt or task about anything the user can ask | The contract process | A matter and the team handling it, from arrival to close; one defined type of work, then the next |
| What it holds and produces | A session and, increasingly, a workspace; an answer or draft | Contracts, their metadata, approvals and deadlines | The named file, output, written mandate and run record |
| The agent’s mandate | The product’s available settings and the user’s choices in that session | The role and authority matrix and the approval chain over the contract | The agent’s written mandate, agreed before the run: what it may read, keep and do, each separately |
| Human approval | Whoever chooses to use the output decides what to do with it | The contract’s signature and approval process, by whoever the approval chain names | A mandatory stage with a named lawyer as reviewer, identified before the pilot starts |
| The record | The output and, depending on the product, session history and logs | The contract’s history, versions and approval trail | Every run: what ran, on which sources and model, under which mandate version, what was decided, when, and who signed |
| When the model changes | The provider changes the model; users often learn afterwards | Outside this category’s scope | Every model change, prompt edit and connector upgrade passes an owned change gate; it cannot go live before the gold set passes |
| Where it runs | The provider’s environment, in a region offered by the product | The provider’s environment | Designed for the company’s environment or a region it chooses, confirmed for each engagement |
| What the client keeps on exit | It depends on the product: the content remains, the workflow does not | The contract data | The definition, mandate, guide, gold set and records |
| The Türkiye side | It depends on the product | Generally outside this category’s scope | UYAP, UETS, KEP and e-signature are part of the workflow |
| Buying and pricing | Usually bought as a licence per user | Bought as a system; priced by contract volume or user | Designed with the team and left with the team; scoped as one workflow and one measure |
| Where LEXSAS sits | Beside it. The workflow can call it, and the gate sits after it | On top of it. The workflow uses it as the contract’s home | This is what LEXSAS designs |
| What it is not built for | Owning the team’s queue, or keeping the matter’s decision record | The matters that are not contracts, though some can be set up for general legal intake | Drafting better than a good assistant, or storing contracts better than a CLM |
Every claim in that table is one I can defend about the workflows I design. The claims about copilots and contract systems describe what those categories are for, not a test of any particular product. LEXSAS resells none of them and claims no certified connector to any of them.
Why a team ends up with all three
In practice most in-house teams already have a copilot and a contract system, and what they are missing is the path between them. The assistant produces a draft, the contract system stores the signed version, and nobody can say who decided the thing in the middle.
A designed workflow is the part that carries the file from one to the other, and it is the part that is still hand-built almost everywhere.
The Türkiye row is often misread. A copilot’s lack of UYAP support is not a defect; that is not what a copilot is for. The problem is a team keeping the UYAP notice, KEP correspondence and assistant’s draft in three places, joined only by one person’s memory.
The honest failure mode
A workflow is a designed thing, which means it has to be maintained. Every model change, prompt edit and connector upgrade has to pass a gate, and someone has to own that.
Teams who want a licence and no upkeep should buy a licence. I say this before a pilot rather than after it, and I have watched enough enthusiasm run out at the maintenance stage to keep saying it.
Three questions, briefly
A tool that answers a question or produces a draft for one person. It is usually licensed per user, and the person in that session decides what the output becomes. Three people on the same team can use the same assistant three different ways; that is not a flaw, it is the definition of the category.
A system that holds contracts and their approval, signature and renewal history. The question it answers is narrow and clear: which version, where, renewing on which date. Work that is not a contract usually stays outside it, even where a product can be set up for general legal intake, so it is not the way to measure a compliance queue.
The path a piece of work takes, drawn as named stages, each with an owner, a clock, a written mandate for the agent and a record. That is what LEXSAS designs. The assistant and the contract system are tools on that path, not the path itself.
If you have an assistant, the workflow uses it as a tool; if you have a contract system, the workflow sits on top of it. If you have neither, the workflow still runs, and everything it produces can be exported. Next: the eight workflows, or the operating standard if you want the method before the menu. The words used here are defined in the glossary. Get in touch