One loop, many Lawrences

POST /agents/{slug}/chat routed by slug, slugs registered in code (agents as code). One envelope { threadId?, messages, agentParams } where agentParams is generic and the agent validates it against its own Pydantic schema. matterId stops being mandatory and moves into agentParams for the agents that need it.

• Matter scoping is a global guard today (BaseAgent._clean_tool_parameters force-overrides any LLM-supplied matter_id with the authenticated one). With optional matterId this becomes per-agent-declared, or the first non-matter agent silently loses the boundary.
• The envelope carries the principal (lawyer | admin | client | system), not an assumed lawyer. Lawra and a client-app Lawrence enter through different auth chains.
• Two output dimensions, not one. Transport: SSE stream vs a single JSON response (prompt-suggestions and title-gen are single-shot). Contract: free-form text vs a validated object, via an optional output_schema — the symmetric twin of the agentParams input schema. Folds mode/surface/PostHog residue into slugs and kills the matrix.
• Ships before, and independent of, the framework refactor. Chat is the first slug; the existing route stays as an alias until callers migrate.

BaseAgent owns the base logic (loop, tool calling, streaming) with method hooks for the customisable parts and mixins for the optional ones. Each agent becomes a thin definition. Done by parts as needed, behind the existing route, with a stream-protocol fixture as the tripwire.

• Hooks: system_prompt(), initial_context(), tools(), vfs_config() (which paths/namespaces are enabled). Mixins: compaction, skills. What an agent is allowed to do is governed by which tools it gets, not a policy layer — and VFS writes are drafts by nature (a create on emails:// produces a draft, never a send), so "propose for review" is inherent. A formal action-policy layer only earns its place later, once a tool can take an irreversible or external action.
• Promote the output seam to part one: the loop writes to self.emitter instead of yielding SSE directly. Capabilities 03 and 04 both swap exactly this seam. Cheap now, a re-refactor later.
• Output is a strategy on one loop, not a subclass. An optional output_schema switches the terminal step from "stream free text" to "force a response tool, validate, retry on invalid" (reusing the Create/Edit validateDoc feedback loop); the emitter becomes a collector. Resist StreamingBaseAgent / StructuredOutputBaseAgent siblings — output is one axis, transport (HTTP / background) is another, and subclassing per axis is N×M classes, the same "modes don't scale" disease in a class hierarchy. Capture the type-safety win with typed entrypoints over the shared loop (stream() → AsyncIterator vs run_structured(schema) → T), so structured×background composes for free.
• Insurance before carving the loop: a golden-fixture stream-protocol test plus a compaction round-trip fixture. Loop coverage is near zero and the ai-stream wire format is the contract platform-v3 depends on.
• Citation-subsystem freeze until Citations P2 ships, since both touch the same BaseAgent streaming code.

Fire an agent, reload the tab, re-attach to the running stream. A Redis stream per run, every chunk gets an id, the client reconnects with a last-chunk-id cursor. Pattern A, the same shape as the durable-llm-streams POC. It splits into two halves, and we already have the first.

• Half of this is already prototyped at the lawrence-api layer (platform-v3 PR 11161 / ADR 0047): a Redis Stream as single source of truth, giving client reload, multi-tab, stop, and cross-instance cancel — and it lands independently of the framework refactor, because lawrence-api owns the buffer. (Even today a browser reload doesn't lose the run, since lawrence-api consumes to finalisation; what this layer adds is live re-attach and surviving a lawrence-api restart.)
• The other half needs the agent to own the stream. Once the cap-02 emitter writes to Redis directly (or the run is a background job), the generation survives any process dying and can stream with no client at all — the precondition for background/proactive runs (04). The producer relocates from lawrence-api into the agent; the reader/resume/cancel logic survives almost verbatim, now reading the agent-owned stream.
• So: lock the stream wire shape now (raw AI SDK chunks already align both sides) so the Python writer and TS reader agree and we never double-buffer. Decide Upstash vs self-hosted Redis (prd-us second region); chunk coalescing is a cheap follow-up on per-command billing.

Run the agent as an Inngest function with an event consumer in lawrence-api that creates the thread. Output reuses AIThread/AIMessage with a kind field (user_chat | scheduled | proactive). No new entity.

• Step-per-loop vs step-per-run: answer empirically and early. The framework eval flagged Inngest step-boundary overhead (~200ms+/iteration) as a possible deal-breaker; since durable streams already give resume and observability, step-per-run may be enough. But the tradeoff cuts the other way for resilience: to resume a generation mid-run after an ungraceful kill or a run that outlived the drain window (rather than restart from scratch), the checkpoint boundary has to be inside the loop — so survival argues for step-per-loop, latency argues for step-per-run.
• Don't reach for durable resume just to survive a routine deploy. A graceful drain (stop taking new requests on SIGTERM, let in-flight runs finish within the orchestrator's grace window, then exit) survives an ordinary agent deploy for interactive runs with zero in-loop checkpointing. Durable/resumable runs are for what draining can't cover: runs longer than the grace window, ungraceful kills (crash, OOM, spot reclaim), and background runs with no request to drain.
• Auth is the long pole: the agent acts as the user with no active session, which is a security and compliance question in a legal product. Start that design when 03 starts, not when 04 does.
• The fulfilment gap is narrow. Almost everything a background agent does is already server-fulfilled: all creates (emails, notes, messages, tasks, key dates, documents), plus documents:// edits, filled-form fields, and folder ops. The only client-fulfilled writes are edits to emails:// and notes:// (patch resolvers the browser applies via handleEditToolCall). So a background run can create and act freely; it just can't revise an existing email or note until those two edit paths move server-side — Edit-DSL #8C, gated on server-owned content (notes → content-service in flight; emails need the equivalent).

An agent subscribes to Inngest events (material case change, CCO production, user cron). Target state: Lawrence reacts to a matter update and proactively does something for the lawyer, reporting back in a new thread.

• The machinery already exists engine-side: handle_material_case_change accumulates, thresholds, and returns should_fire_material_change_event with a payload. Capability 05 consumes that event rather than re-deriving it.
• The CCO is already versioned (CaseContextSerializer keeps versions and can fetch the latest before a timestamp), so "diff since the last MCC" is an API exposure, not new storage.
• lawrence-engine already emits app/lawrence-proactive/generate-suggestion-* and next-step events. Decide whether to route those into agent runs or duplicate trigger logic; don't build a second proactive brain.
• The design content is throttle / quota / dedup: a CCO regeneration storm must not fan out into N agent runs. The engine-side threshold already coalesces some of this.

The harder agent abilities. No longer hypothetical — two concrete drivers already exist: the numerical amount calculations the current form-filling pipeline does in code (which agentic form filling has to keep), and court bundle assembly (merge / paginate / index matter PDFs). Still demand-sequenced and last in the order, but the demand is here.

• It's a dependency of fully replacing the form-filling pipeline, not an extra: the legacy pipeline computes amounts in code, so the in-loop version needs the same. Court bundling needs PDF primitives (assemble, paginate, index) over matter files — an HTML explainer is exploring the agentic paths now (court-bundles-agentic-paths).
• It's a spectrum, not one sandbox. The two drivers sit at opposite ends. Form-fill numbers need only a minimal compute sandbox (arithmetic over known inputs, no filesystem or network — e.g. monty): cheap to stand up, tiny blast radius, lands early and de-risks the form-filling replacement. Court bundling needs a fuller sandbox — real filesystem, PDF libraries, memory, and the VFS file bridge (short-lived signed tokens) to read and write the documents.
• So policy gates (no arbitrary code over PII / disclosure docs without an approved policy) matter most for the fuller tier; the minimal tier just takes values in and returns a value. Output (a filled value, an assembled bundle) lands back as a server-fulfilled VFS write.