Watch a lawyer produce a contract amendment and try to mark the moment the drafting starts. They read the request. They pull up the master agreement, the schedules, the amendments already made against it. They check whether the extension being asked for collides with a termination-for-convenience clause, whether the service levels still line up, whether the products named in the request are actually the ones named in the agreement. Forty minutes in, they haven't typed a word of the new document.
We book all of that time as drafting. Almost none of it is. Ask a journalist how long an article took and they'll count the phone calls, not the typing. Routine contracts work the same way. The wording was solved by templates decades ago. What fills the lawyer's hour is reading what already exists and checking it against what is being asked. Drafting, for many of the contracts an in-house team produces, is mostly review.
I think this matters more than it first appears, because the entire legal tech market is organised as if the two were different things.
Two categories that were never really two
Open any legal AI vendor comparison and you'll find the same taxonomy. Drafting tools generate documents. Review tools analyse them. They're sold as separate modules, evaluated in separate proofs of concept, sometimes bought from separate vendors against separate budget lines. And the taxonomy feels reasonable enough. Generating a document and analysing one sound like different jobs.
Look at the work rather than the software, though, and the split was never there. No lawyer drafts an amendment without first reviewing the agreement it amends. The two activities are one continuous motion: read what exists, check it against what is wanted, produce the document that closes the gap. The split exists because early tools could only do one half at a time, and the market organised itself around the limitation rather than the work.
I'm in the midst of several deployments where that split is visibly dissolving. The most direct way I can show it is through a document we write for every one of them.
Every job description says the same thing
When we deploy an agent, we write it a job description, the same way a team would for a human hire. Scope of work, inputs, outputs, success criteria, competencies, what stays with the lawyer. Having written a number of these for different legal teams now, I've noticed the same thing each time. The drafting section is mostly a description of reading the underlying document.
For example, one team needs contract amendments drafted. Before the agent touches a template, its job description requires it to work out which agreement governs, validate the requested changes against the existing defined terms, reconcile product names that appear differently across documents, and check whether the requested extension collides with a termination clause somewhere in the schedules. The draft is the final line of a sequence that is, in every other respect, a review.
Another team needs escalation forms produced for agreements negotiated on the counterparty's paper. The deliverable is a drafted document. The substance of the job is reading the counterparty's redlines and comments, identifying each deviation from the team's playbook position, and mapping it to a risk category and the relevant guidance. The form at the end is the review, written down in the format the approvers need. The job description files all of this under drafting, and it's right to, because that is what the drafting actually consists of.
Try to draw the line in any of these where review ends and drafting begins. There isn't one. The jobs are only possible because the system does both in a single motion, the way a lawyer always has.
The line that blurs, and the line that sharpens
What I find most interesting is that while one line dissolves, another gets sharper.
However different the teams and the documents, the job descriptions converge on the same boundary rules. Surface information gaps rather than inventing inputs. Where the instruction is vague on commercial terms, ask. Flag the conflicts; don't resolve them. Where a match is ambiguous, present the candidates rather than picking one. And in every job description, the same closing note in one form or another: the risk call, the recommendation, and the final decision remain with the lawyer.
Each of those rules was set by the legal team that owns the agent, and each is a piece of judgment made explicit, often for the first time, because until now it lived in the heads of the people doing the work. The boundary between drafting and review turns out to be the wrong place to organise a legal function. The boundary that matters is between execution and judgment. The striking thing about these design sessions is watching a team locate it precisely, clause type by clause type, for workflows they'd previously only ever described as "someone senior has a look."
What this means for how teams buy
If the work doesn't divide into drafting and review, evaluating tools by those categories is measuring the wrong thing. A drafting tool that can't review the underlying agreement automates the typing, which was never the cost. The question worth asking a vendor is whether the system can run the whole motion: read what exists, check it against what is wanted, produce the draft, and hand it to a human with the judgment calls clearly flagged.
Where I am less sure
The clarification piece is the hardest part of this to do well, and I'd be wary of anyone who claims it's solved. Knowing that information is missing is easier than conducting the back-and-forth a human would. Well-designed agents ask narrowly and escalate early rather than attempting to negotiate a thread the way a person would.
And the human review at the end is not a transitional arrangement waiting to be engineered away. It is the design. The category that remains is judgment, applied by a lawyer at the point where it matters, on work that arrives with everything else already done.
