M4 makes background agents a platform capability: event-triggered, user-less runs on the TS agent framework, under a first-class agent principal, with a durable status and process trail — plus the smallest review primitive that turns their output into something a lawyer can find, review and act on.
The spine is three calls: one generic proposal entity for anything an agent produces, propose-first for internal writes, and a new global review home. Autonomy is gated at one place — egress — in three rings: reads are free, internal writes land as drafts or proposals, and anything leaving the platform needs per-item human approval.
Status: scope confirmed 5 July 2026, pre-planning. The run-durability substrate and the review-home information architecture are the open planning calls. M4 depends on M2's generalised threads and write verbs — it does not start until those land.
01Why this milestone
Every product-side plan already assumes background agents. The 2027 vision has Lawrence proactively reviewing new information on each case as it comes in and working around the clock; the Tasks & Key Dates plan assumes Lawrence completes an assigned task without a chat prompt; the end-to-end work-delivery proposal assumes an event-driven loop that keeps a matter plan current. The Agent Platform's M4 milestone is where that capability is supposed to live — and today it exists in Linear with no description and no issues.
The platform cannot do any of it yet. The gaps are structural, not incidental:
- every agent run requires a live Clerk-authenticated request — there is no run without a user on the other end;
- framework chat turns are never persisted server-side, and
AIThreadstill requires amatterIdand auserId; - there is no principal for a run no user initiated —
SYSTEM_IDENTITY, assumed by earlier design docs, does not exist in any repo; - the in-flight durable-streams work explicitly accepts that a generation dies with its instance.
The review side is just as unbuilt. Emails and documents have real draft states; tasks, key dates, notes and client messages have none, and no entity anywhere carries an agent-authorship marker. Background output with nowhere to land is wasted compute and invisible risk — so M4 is a substrate and the minimum review surface, together.
02The three-ring autonomy model
Autonomy in M4 is not a global dial. It is gated at one place — egress — in three rings. Enforcement is deterministic: the send tools are simply not in a background run's surface, so egress is a property of the toolset, never a model decision.
The outer ring is the Vision's "nothing leaves the Platform without my sign-off" invariant — and it is also the regulatory line. Ayinde v LB Haringey [2025] EWHC 1383 requires per-item human verification before AI output is relied on, and CalBar's 2026 agentic-AI guidance bans autonomous external transmission. Internal work product sits outside those hard rules — which is exactly what keeps background agents viable.
03The four confirmed decisions
Condensed from the confirmed Key Decisions. These are the calls that shape everything downstream, and the ones most worth reacting to now.
M4 carries the background-run substrate and the smallest review capability that makes its output visible and actionable — no more. The substrate alone would strand outputs as email and document drafts, with no answer for tasks, key dates or notes; the full inbox product would front-load contested UX.
The review primitive is designed from scratch: prior proactive experiments are stale and are not inherited. The richer inbox experience is a named fast-follow.
A single first-class proposal references any target entity type and carries the proposed
payload, its provenance (the producing run), and a lifecycle —
pending / approved / rejected / expired. Approval
materialises the target; nothing touches the entity's own model until then.
Chosen over per-entity status fields, which would mean a schema change and a bespoke UX per type. One primitive scales to new entity types and feeds one review query.
Every background write to an entity without a draft state lands as a proposal; nothing internal commits without a human verb. Graduating specific types to commit-direct — the Vision's texture for internal state — is a later policy change on the same primitive, made once trust and undo exist.
Not a v1 redesign: the primitive is built so the graduation is a policy flip, not a rebuild.
v1 review lives on a new first-class page in the triage-queue style: pending proposals and drafts across matters, urgency-ordered (simple heuristics in v1), groupable by matter, deep-linking into each entity with the review verbs inline.
It is designed to absorb the owner-less alerts queue rather than sit beside it — the alerts backend has no owner and its resolve semantics map onto proposal verbs — and to grow toward the Vision's login dashboard. The per-matter view is a filter on the same surface, not a second build.
04What exists, what's missing
The trigger substrate is largely there; almost everything the run itself needs is not. This is the honest gap between today's code and an unattended run that produces reviewable work.
| Capability | Where it stands today | What M4 must build |
|---|---|---|
| Triggers | email received, message received and file uploaded already fire
as typed, matter-resolved Inngest events — with no consumer. Task and key-date events
don't exist; intake rides the existing Tally webhook event. |
An event→run gate (flag, throttle, per-matter serialisation, coalescing, dedup) and engineering-declared trigger→agent bindings, with per-firm and global kill switches. |
| Agent principal | None. No SYSTEM_IDENTITY in any repo; the framework requires a live Clerk request.
INTERNAL_PRE_AUTH service tokens exist but are unscoped and never expire. |
A first-class agent identity, optionally on-behalf-of a human, recorded on the run and on everything it produces — not user impersonation. |
| Run & thread persistence | Framework chat turns are never persisted server-side; AIThread requires
matterId and userId. |
Server-side run and thread persistence, non-user scoping (matter / firm / user / org), and a durable process trail reachable from every output. |
| Write verbs | The framework VFS is read / list only. |
Server-fulfilled create / edit (delivered by M2/M3);
revising existing emails and notes stays out until those edit paths move server-side. |
| Crash durability | The durable-streams stack solves stream transport only and accepts, by design, that a generation dies with its instance. | Idempotent retry-from-trigger and first-class, queryable run status — so a run survives deploys, crashes and restarts. |
05Durability: idempotent retry, not checkpoint resume
v1 durability is deliberately modest, and that is the point.
A background run that dies is re-run from its triggering event, and idempotency stops it duplicating outputs it already produced. Mid-run checkpoint resume is not assumed. Streams stay the live-observability channel, not the durability mechanism — which keeps M4 off the critical path of the durable-streams stack's unresolved second half.
Run status is first-class and queryable per matter and across matters, and awaiting-human is a
durable state, not an in-memory pause:
Failure is visible: a failed run surfaces with its partial trail, retries are bounded, and nothing fails silently. The gate is also the cost ceiling — an ungated fan-out (twenty bulk uploads becoming twenty runs instead of one coalesced run) is a launch blocker, not a tuning task.
06Deferred to planning
The scope questions are resolved. What remains are planning-time decisions — each an open question with a known shape rather than an unknown.
- Q5Run-durability substrate. Inngest coarse-step as today, self-hosted Inngest, or a DevKit + world-postgres worker — and where background runs execute (API task vs a dedicated worker).
- Q6Merge order with durable streams. Does the stream stack land first as M4's base, or does the run substrate own durability with the stream store as a read projection?
- Q7Agent-principal mechanics. Token scoping, expiry, revocation, and the shape of the on-behalf-of grant.
- Q8Gate specifics per trigger. Windows, quotas and coalescing keys, sized from the volume data.
- Q9Which events to mint first. Task created / completed, intake-form submitted, key-date cron — and in which services.
- Q10Review-home IA, with design. Route, nav placement, name, how Tasks & Key Dates M2's review view converges onto it, and the alerts-absorption sequencing.
07What M4 is not
The substrate and the minimum review surface — not the mature inbox, and never autonomous egress. Named explicitly so scope doesn't creep in planning.
- Autonomous egress in any form — never; auto-send would invert the egress-gate decision
- Inbox maturity beyond the v1 review home (digests, richer ranking, per-user views) later
- Migrating existing alert types onto the proposal model follow-on
- Matter Graph / Work Item substrate — compatible with, not built here
- Machine pre-review (a critic agent filtering before human attention) later
- Per-user autonomy configuration and risk-tier dials later
- Key-date cron and full domain-event coverage beyond what v1 flows need
- User-configurable trigger→agent bindings later
- Server-side email / note edit fulfilment LEX-533
- Rebuilding lawrence-engine's MCC/CCO proactive pipeline — M4 consumes its signals; its future is the M3 story