Why intake makes the best first agent
It isn't picked for being easy — it's picked because it exercises exactly the seams the generalised agent platform has to prove, while staying off Lawrence's critical path.
matterId / generalised-scope work; Lawrence can't do this today.createMatterForAdmin path. Proves the principal axis.tools()," not a fork of Lawrence.output_schema job, not free-form chat) into OPENING status for review — bounded blast radius.The flow
Admin to confirmed matter, with the agent as a contained step in the middle. Nothing lands ACTIVE until the admin signs off.
OPENING. The admin reviews the populated matter and confirms — only then
does it become ACTIVE. Matter-level preview-then-confirm, using a status the model already has.What the admin reviews
The draft the agent hands back — everything proposed, each value attributable, nothing filed until confirm.
The tool surface
Most of what the agent needs already exists as VFS create paths today. One capability has to be built — and it's a tidy first thing to build on the new platform.
Drivable today
Existing VFS create adapters + the existing create-matter input. Reuse, don't build.
createMatter already takes a fields[] array (typed, firm-scoped defs)todayTo build (small)
The agent's headline action, plus a judgement call about matter types.
platform-api createMatter as one tool/adapter — the one genuine gap.buildThe only new infrastructure the trial forces is one matter:// create tool. Everything
else — fields, key dates, tasks, notes, files — the platform already exposes.
The agent, specced
Identity. slug matter-intake · principal admin ·
scope firm (the matterId is the output, not an input) · surface:
the admin app.
Prompt focus. Classify practice area and parties from the uploaded docs and the admin's notes; draft a clear title and summary; extract real key dates (filing deadlines, hearings) and propose the standard tasks for that practice area; map values onto the firm's custom fields. Conservative by construction — skip anything it can't ground in the documents and flag it for the admin rather than guess.
Tools (the whole set). read files://, read parties:// →
create matter:// (title, market, jurisdiction, participants, summary, fields[])
→ create keydates://, create tasks://, create notes://, and
folder-organise files://. No research, drafting, email, or message tools — a fraction of
Lawrence's surface.
Output. A validated matter-draft object (output_schema), materialised as a
matter in OPENING status. The admin confirms → ACTIVE, or edits the draft.
And at volume: batch from a spreadsheet
The same agent, fanned out over rows. An admin drops in an Excel / CSV — one row per matter — and gets back a batch of drafts to confirm.
Single intake is one matter from documents; the batch variant is many matters from structured rows.
The admin uploads a spreadsheet with a row per matter (title, parties, jurisdiction, practice area, a
column per custom field, key dates); the agent maps the columns onto matter fields and creates a draft
matter per row in OPENING — flagging any row it can't ground (a missing required field,
an ambiguous party) rather than guessing. The admin reviews the batch and bulk-confirms: clean rows go
ACTIVE, flagged rows stay drafts.
This is where the agent earns the “not a chatbot” framing — structured input (the sheet) to structured output (N validated drafts), run headless as a background job; no one watches tokens stream for a 200-row import. So batch is the natural second step of the trial: the same agent and tools as single intake, now proving it runs as a durable, fan-out background run (the background-execution rung) rather than an interactive turn.
Single intake proves the envelope interactively; batch proves the same agent runs headless and scales — one more reason intake is the right place to start.
What batch makes you get right
Column → field mapping — the firm's custom-field definitions vary, so the agent proposes a mapping the admin confirms once, then reuses for the file. Idempotency & dedup — re-running the same sheet must not double-create; key on an external ref or a dedup check. Partial success — one bad row can't sink the batch; every run returns a created / skipped / errored report with reasons. None of these are new platform infra; they're the batch wrapper around the same per-matter agent.
The trial, as a sequence
Stand up the runtime shell + the matter:// tool
A minimal TS AI-SDK loop (the platform under test) with exactly this agent's reduced tools. Build the one new capability — matter:// create over platform-api createMatter, including the fields[] array — and reuse the existing keydates/tasks/notes VFS adapters.
Run it firm-scoped, admin-principal
No matterId on the way in; the agent runs in a firm + admin context and produces a matter. This is the part Lawrence can't do — and the part that proves the generalised scope and principal.
Draft → OPENING → review
Wire the structured output to create the matter in OPENING; surface the draft in the admin app for confirm / edit. Measure: time-to-open vs the manual flow, and how much of the draft admins keep unedited.
Bank the platform learnings
What we learn here — the slug/principal/scope envelope, the reduced tools() + vfs_config() hooks, structured output, the in-tier service calls — is exactly the framework the rest of "many Lawrences" reuses. Intake is the proof; the platform is the point.
One honest caveat
v3 has no matter-type concept driving fields, tasks or key dates — matters are jurisdiction- and participant-driven, and custom-field definitions are firm-scoped, not type-scoped. So “custom fields for the matter type” isn't a lookup; the agent decides what a given intake needs. That's a strength of the agentic approach over a rigid form, but it's also where the quality bar lives — and where this trial overlaps the matter-templates thinking. Worth deciding early how prescriptive we want it.