In early 2026, Clio published a blog post with a title that stopped me: "Anthropic's Legal AI Move: Why Workflows Matter More Than Features." They were drawing a line between AI features — chat, Q&A, summaries — and AI workflows: systems that take a specific input, process it through a specialized pipeline, and return a specific output in a format that's immediately useful. I built three workflows in one overnight session to understand the pattern from the inside.
The feature vs. workflow distinction
A legal AI feature is a chatbot you can ask questions to. A legal AI workflow is something you feed matter activity notes to and get a client-ready email back. The distinction matters because workflows remove a step, and features add one.
With a chat feature, the lawyer still has to: (1) read the context, (2) formulate a question, (3) read the response, (4) decide if it's good, (5) write the actual output. With a workflow, the input goes in and the output comes out in a form that's ready for downstream use. That's the gap I wanted to understand.
So I built three workflows that mirror exactly what Clio's AI team shipped:
- Matter Activity → Client Update: paste activity notes, get a client-ready email in plain English
- Time Entries → Billing Narratives: paste time log entries, get formal billing narratives using legal billing conventions
- Court Document → Calendar Events: paste a court filing, get structured JSON calendar events with priority classification
The interesting engineering: output format, not API calls
The API call for all three workflows is almost identical — a POST to api.anthropic.com/v1/messages with a system prompt and the user's pasted content. The interesting engineering is entirely in the system prompt design and output format specification.
Client Update prompt: The goal is an email a senior lawyer would actually send. Not a summary. Not bullet points. An email. So the system prompt specifies: write in first person, use "I" not "we," explain legal developments in plain English, include a "next steps" section, close with a specific action the client needs to take. The voice matters as much as the content.
Billing Narrative prompt: Legal billing has specific conventions that courts and clients recognize. You don't write "talked to client about contract"; you write "Conferred with client regarding contract terms." The billing language is a formal register that signals professional competence. The system prompt teaches this register explicitly — with examples of appropriate phrasings — because Claude's default billing language sounds too casual.
Deadline Extractor prompt: This one returns structured JSON, not markdown. A deadline in a court filing isn't just a date — it's a date plus a description plus an owner plus a priority. Missed hearings are critical. Response deadlines are high. Filing confirmations are medium. The system prompt specifies an exact JSON schema and priority classification logic. The frontend parses the JSON and renders deadline cards, making the output immediately calendar-integration-ready.
Why Sonnet instead of Haiku
I use Claude Haiku for most of my demos — it's fast, cheap, and good enough for most tasks. LegalFlow uses Sonnet, and the reason is worth explaining.
Legal content has asymmetric error costs. A billing narrative that mischaracterizes the work done isn't just low-quality writing — it's potentially a bar complaint. A missed deadline extraction could mean a sanction or default judgment. The accuracy premium of Sonnet is worth it when the output has real professional consequences.
This is a design decision, not a default. Most of my other apps use Haiku precisely because accuracy isn't life-or-death for those use cases. The right model depends on the stakes, not just the capability requirements.
What I learned about the workflow pattern
After building all three, the core pattern is clear: a workflow is a function where the interesting engineering is in the signature, not the body.
The input signature — what exactly you're asking the user to provide — determines what's possible. If you ask for "notes," you get inconsistent inputs. If you ask for "matter activity log entries in chronological order," you constrain the input format and make the output more reliable.
The output signature — exactly what format the result comes back in — determines whether it's immediately useful. A client update email is useful. A "summary of client communications" is not. A priority-classified JSON event with date, title, owner, and description is integration-ready. A "list of deadlines" is not.
The AI handles the transformation between those two fixed endpoints. But the endpoints themselves are the design work.
What this pattern looks like at enterprise scale
Building these three workflows gave me a clearer mental model of what enterprise legal AI teams are actually doing. It's not building chatbots. It's building pipelines with defined inputs and typed outputs that plug into existing legal workflows: the client communication process, the billing process, the court calendar process.
The AI is the transformation layer, not the interface. The interface is the lawyer's existing tools — their email client, their billing software, their calendar. The workflow drops the right content into those tools in the right format.
That's a very different architectural bet from "put a chat box in every screen." And the engineering challenges are also different: it's not about building a good chat experience, it's about building reliable transformation pipelines with typed, tested, predictable outputs.
I now understand that distinction in a way I didn't before building it. That's what building workflows is for.