The architecture behind a law-firm intake agent that automated 80% of the process and freed 30+ paralegal hours a week — the guardrail that makes it viable in legal, and the two failure modes that show up in every firm deployment. Public excerpt; the full teardown lives in the Builder library.
This is the shape of the deployment behind a claim we cite often: 80% of a firm's client intake automated, 30+ paralegal hours a week returned, four-hour intake completing in minutes. Legal intake is the friendliest possible terrain for an agent — high volume, structured questions, hard rules — with one constraint that shapes the whole build.
Layer 1 — The conversation. An agent that answers every channel, around the clock, and runs the qualifying flow for the firm's practice areas. Design the flow per practice area as a question tree, not a free chat: personal injury qualifies on different facts than family law, and the tree is what makes extraction reliable downstream.
Layer 2 — The guardrail. The constraint that decides viability: the agent must never produce anything resembling legal advice. This is architecture, not prompt vibes — an explicit boundary classifier on every response, a hard rule that legal questions get acknowledged, logged, and routed ("that's exactly the kind of question the attorney will cover — let's get you scheduled"), and the deflection scripted so it advances the intake instead of stalling it.
Layer 3 — Extraction and records. The conversation resolves to structured fields — parties, dates, incident facts, practice-area qualifiers — written to the firm's CRM through its API as a complete matter-ready record. The test: a paralegal reading the record should have zero re-asking to do.
Layer 4 — Scheduling and escalation. Qualified prospects book consultations directly; edge cases route to humans with the transcript and structured record attached. The ratio to tune for is the same as every intake build: overwhelming majority straight through, single digits to staff.
Prospects ask legal questions mid-intake — constantly. Not occasionally: as a rule. The naive handling ("I can't answer that") stalled conversations and lost after-hours leads at the exact moment the system existed to win them. The fix was treating deflection as a designed conversational move — acknowledge, promise the attorney, ask the next question in the same breath. Completion rates on interrupted flows recovered once deflection stopped feeling like a wall.
Adverse-party names arrived too late for conflict checks. The first flow collected the prospect's story before the other side's names — so a conflict surfaced after twenty minutes of detail had been shared with a firm that couldn't take the case. The tree was reordered: parties first, conflict-screen early, story second. Order of questions is a compliance feature in legal, not a UX preference.
The full teardown — the boundary-classifier design, the per-practice-area question trees, the deflection scripts that keep conversion, and the conflict-check sequencing — lives in the Builder library.
Implementation detail, checklists, and the parts we'd rather not have public — for members.
Unlock with Builder