Order of operations is architecture. The decisions you make about what to build first shape everything you build afterward. JustineAI was built in an order that looks backward from the perspective of the legal-AI market — and the order is the most architecturally consequential decision the platform has made.
Most legal-AI products ship a chatbot first. A general-purpose conversational interface, layered on a frontier model, tuned with a system prompt to behave like a legal assistant. With the chatbot shipped and customers using it, the company then adds workflows as a feature — usually a sequence of buttons that pre-populate prompts to the same chatbot.
That order produces a recognisable kind of product. The workflow is decorative. The chatbot is the substance. The system can be asked to do the next step; it cannot be relied on to do the right steps in the right order without continuous attorney prompting. The ceiling is built into the architecture by the order in which it was constructed.
We did it backwards
We started with the supervisor pattern. The supervisor is the entity that holds the discipline's workflow shape. For personal injury, the workflow is the 9-status PI process — intake, evidence collection, medical records review, ICD-10/CPT coding, settlement-range computation, demand-package construction, and the rest. The supervisor knows this workflow structurally and decomposes any matter across the relevant sub-agents.
Then we built the sub-agents. Each is a discrete-task specialist with a scoped responsibility and a specific Eve-Genesis (Law Edition) training emphasis. The intake sub-agent reasons abductively to construct case theory. The medical-records sub-agent analogises across the case file to extract ICD-10 and CPT codes. The demand-package sub-agent runs the 9-step curation layer. Each sub-agent does one thing well, and they are coordinated by the supervisor.
Then we built the conversational surface. Not as a chatbot bolted on, but as a surface attorneys use to interrogate the supervisor and its sub-agents about the current state of a matter. The chat is a query layer, not the substance of the product.
What the order made possible
Workflow-level reliability that no chatbot product can match. When a matter enters the platform, the supervisor knows what status it is in, what sub-agents need to act, and what the attorney needs to attest. The matter advances through the workflow in the order the discipline demands, not in the order a user happens to ask about.
Refusal at the architectural layer rather than the prompt layer. The sub-agents do not have the standing to produce certain outputs (legal advice, predictions, outbound communication). The refusal is structural; it is not a prompt-engineering patch a user can route around.
Audit trails that survive scrutiny. Every sub-agent action is recorded; the supervisor's sequencing decisions are recorded; the attorney's attestations are recorded. The audit trail is workflow-shaped, not chat-shaped.
What the order cost us
Time and complexity. The chatbot-first companies in market were faster to ship. Their first version was a complete-looking product; ours was not for a long time — we invested in the supervisor and the sub-agents and the Eve-Genesis Law Edition before we shipped the surfaces a managing partner recognises from prior legal-tech evaluations.
The cost was worth it, because the order is the architecture. We could have built the chatbot first and added workflows. We would have ended up with a product the market already has several of. We chose to invent the supervisor pattern first and let the conversational surface follow from what the workflow enabled. The platform that exists today is the artefact of that order.