Tasks & Key Dates M2 — making the task list agentic

Overview

Lawrence can already complete individual tasks end to end — but only when a user asks it to, in chat. This milestone closes that gap in two directions, without redesigning the task list:

• Pull — a lawyer looking at their task list can hand a task straight to Lawrence, watch it work in a live thread, and later review both the finished work and the steps it took to get there.
• Push — when a document lands on a matter, Lawrence reads it for dates and actionable items and offers them back as key dates and tasks, attributed to the document they came from.

The point where those two loops meet is the task list itself: one loop keeps it done, the other keeps it true.

flowchart TB
  subgraph pull["Work a task with Lawrence"]
    direction LR
    T[Task in the list] -->|Assign to Lawrence| TH[A thread opens]
    TH --> W[Lawrence works it,
live and step by step]
    W --> S[The task's state
stays current]
    S --> R[Review the output
+ the process, together]
  end
  subgraph push["Keep the list true from documents"]
    direction LR
    D[Document added
to a matter] --> X[Scan for dates
+ actions] --> P[Proposed key dates / tasks,
attributed to the source]
  end
  P -.->|lawyer confirms| T
  classDef d fill:#eef1f6,stroke:#9aa3b2,color:#1f2430;
  classDef hot fill:#fff,stroke:#B5491F,color:#1f2430,stroke-width:2px;
  class T,TH,W,S,R,D,X,P d;
  class T hot;
  

The four PRD requirements map onto the two loops: Pull = assign (§1) → manage state (§2) → review (§3); Push = auto-extract (§4), gated on the agent proposal queue.

Solution shape

Four building blocks, each a numbered section below. The theme throughout: reuse a merged pattern, add the one missing edge.

Two PRD comments already suspect this "necessitates a rethink of the design of tasks" and ask "what happens to assignment". They're right the pressure is real — it concentrates in KD1 (assignee) and KD2 (for-review state). The "what happens to assignment" question grew into its own workstream — Lawrence as a first-class identity, which this plan now depends on; for the for-review state we add the smallest true edge and defer the wider redesign.

1 · Assign a task to Lawrence Frontend

Requirement. Every task exposes an "Assign task to Lawrence" action. Triggering it opens a new thread — mirroring the skill-library trigger — where Lawrence works the task and the lawyer watches in real time. The task stays linked to that thread so the lawyer can move between the list and the working thread.

The thread-creation pattern to mirror already exists and is merged. When a lawyer runs a skill, the app doesn't call a "create thread" endpoint. It mints a client-only provisional_<uuid> thread, opens the panel, and posts a first message with body: { matterId }. The server creates the persisted thread and streams its real id (aithrd_…) back over SSE as a data-thread event; the client then "promotes" the provisional tab to the real id. Assigning a task reuses exactly this thread lifecycle, plus carrying a taskId through the run. What we deliberately don't copy is how the skill fills the prompt — see the note below the diagram.

sequenceDiagram
  actor U as Lawyer
  participant FE as Task list (legal-os)
  participant TR as Lawrence panel
(chat-manager)
  participant API as lawrence-api
/lawrence/chat
  participant AG as Lawrence agent
  U->>FE: Click "Assign to Lawrence" on a task
  FE->>TR: startNewThread() → provisional_… + expand panel
  TR->>API: POST first message
"Execute this task" + { matterId, taskId }
  API->>AG: /generate (request incl. taskId)
  AG->>AG: Read the task first (tasks://)
name, description, context
  AG-->>TR: SSE — thinking, tool calls, edits (live)
  API-->>TR: data-thread → persisted aithrd_…
  TR->>FE: promoteTab + persist task ↔ thread link
  Note over FE,TR: Task row now shows "Working with Lawrence"
and deep-links to the thread
  

Deliberate divergence from the skill trigger. The skill trigger's compileSkillToPrompt inlines the skill's entire markdown body into the first message. We do not copy that here. Lawrence already reads tasks (the tasks:// namespace, see §2), so the trigger injects only an instruction to execute the task plus its taskId — and the agent's first step is to read the live task itself. This keeps a single source of truth (the current task, not a snapshot frozen into the prompt), avoids prompt bloat, and means any edit to the task between click and execution is picked up automatically.

What we build on top

Boundary (PRD open question). Which task types can Lawrence meaningfully complete this milestone? We can ship the action on every task and let Lawrence decline gracefully in-thread, or gate the button to task types we've validated. Recommendation: ship broadly, measure, then gate — captured as Open Q1.

2 · Lawrence manages task state as it works Backend Legal AI

Requirement. On assignment the task's assignee becomes Lawrence (ownership is unambiguous); when the work is done Lawrence marks the task for review; when a task is no longer relevant Lawrence can delete it, behind a human confirmation.

The data model today, and the three edges we add

Tasks live in matter-service. A Task has no status column — its state is derived from nullable timestamps: completedAt means done, deletedAt means soft-deleted (a soft-delete Prisma client intercepts .delete()). "Matter-level vs global" is just whether matterId is set. Assignment is a one-to-one TaskAssignment row carrying assignedIdentityId. A KeyDate is its own model (one key date → many tasks).

erDiagram
  KeyDate ||--o{ Task : "has many"
  Task ||--o| TaskAssignment : "one"
  KeyDate {
    string id "kd_…"
    string matterId "nullable → global"
    datetime dueAt "required"
  }
  Task {
    string id "tsk_…"
    string matterId "nullable → global"
    string name
    datetime dueAt "nullable"
    datetime completedAt "nullable = done"
    datetime deletedAt "nullable = soft-deleted"
    datetime markedForReviewAt "NEW (see KD2)"
    string threadId "NEW link (see KD3)"
  }
  TaskAssignment {
    string id "tskasm_…"
    string assignedIdentityId "human — or Lawrence (identity plan)"
  }
  

Today Lawrence can create and read tasks and key dates, but cannot edit or delete them (mechanism below). M2 opens up the edit + delete surface; three parts are worth calling out:

What the agent can touch — today vs the M2 target

Two key-date wrinkles to decide: deleting a key date can either detach its child tasks or soft-delete them too (the existing shouldDeleteTasks flag on deleteKeyDate); and there is no restoreKeyDate today (only restoreTask) — decide whether the agent needs key-date restore parity.

How the agent writes — and why every write is confirmed

Two things this section pins down: the write path is exposure of mutations that already exist (not new task logic — that's the de-risking point), and every agent-initiated write is gated by a human confirmation before it lands.

Lawrence can already read and create tasks and key dates — tasks:// / keydates:// have create + list adapters. What it cannot do is edit or delete: both adapters' write() throws "read-only via VFS", there is no task/key-date editable surface in the registry, and there is no delete VFS tool at all. Crucially the edit/delete logic already exists in matter-service — rename, schedule, assign, updateCompletedAt, updateKeyDate, delete, restore — but only as user-scoped protectedPerson mutations, with no internal.* variant the agent's service token can reach (only listMatterTasks / get / create are internal today). So the work is exposure, not new logic: (1) add internalPreAuth variants of those mutations; (2) implement the adapters' edit() / delete() (they currently throw); (3) register task/key-date editable surfaces and add a delete tool in the agent's VFS layer (only read / edit / create / stat exist today) — all via the same KMS-signed VFSClient the agent's writes already use.

flowchart LR
  AG["Lawrence agent
proposes a write"] --> HITL{"Confirm?
(ask_user_question)"}
  HITL -->|cancel| STOP["not applied"]
  HITL -->|lawyer confirms| SUR["Task / key-date
editable surface (new)"]
  SUR -->|KMS-signed VFSClient| LAPI["lawrence-api"]
  LAPI --> INT["matter-service
internal.* mutation
(create / edit / delete)"]
  INT --> DB[("matter-service DB")]
  classDef d fill:#eef1f6,stroke:#9aa3b2,color:#1f2430;
  classDef n fill:#fff,stroke:#5a8a64,color:#1f2430,stroke-width:2px;
  classDef bad fill:#fff,stroke:#a83838,color:#1f2430;
  class AG,SUR,LAPI,INT,DB d; class HITL n; class STOP bad;
  

Write-with-confirmation, step by step (create · edit · delete)

3 · Review the work & its process Frontend

Requirement. The lawyer should be able to review what Lawrence completed — not just the final output but the process (the thread and the steps it followed).

What M2 builds — the fastest path to value. No dedicated or aggregated review view. When Lawrence finishes a task it marks it for review (§2), and the agent sidebar signals that it's done; review then happens in the thread — the task ↔ thread link from §1 deep-links to the conversation, where the existing Activity blocks ("Explored · 5 reads · 2 searches") show the process and the produced output is visible inline. This reuses what already exists (the sidebar, the thread, Activity blocks, the task ↔ thread link) with no new surface to build.

flowchart LR
  D["Agent sidebar:
task marked for review"] --> C[Open the task]
  C -->|task ↔ thread link| TH["The linked thread"]
  TH --> A["Activity blocks
the process: reads, searches, edits"]
  TH --> O["The produced output
document / email / note"]
  classDef d fill:#eef1f6,stroke:#9aa3b2,color:#1f2430;
  classDef n fill:#fff,stroke:#5a8a64,color:#1f2430,stroke-width:2px;
  class C,TH,A,O d; class D n;
  

Supported workflow (the M2 scope line). A person triggers a task on a matter → Lawrence works it in a thread → that person, or another participant on the same matter, reviews by reading the thread. Review is matter-scoped and per-thread; there is no firm-wide aggregation and no review of background or cross-matter work yet.

Deferred — the agent proposal queue. A firm-wide, RBAC-scoped surface aggregating everything Lawrence has done (across matters, including background / autonomous work) is a separate workstream: the agent proposal queue. Shipping sidebar-plus-thread review now is the fastest path to value; the queue becomes necessary once background execution exists — when there's no live thread to watch, an aggregated review surface is the only way to catch what the agent did.

4 · Auto-extract tasks & key dates from documents Backend Legal AI

Requirement. When a document is added to a matter, Lawrence scans it for key dates and actionable items and creates the corresponding tasks / key dates automatically, clearly attributable to the source document.

Blocked by the agent proposal queue. Auto-extraction is a background process — it produces proposed tasks/key dates with no live thread for a human to watch. Those proposals need a review/confirm surface, and for background work that surface is the agent proposal queue (which we've planned). So §4 depends on the queue being built first — the same "no live thread → you need the queue" argument as §3. It sequences after the queue, not in M2's first cut.

Most of this pipeline already exists. Ingestion parses an uploaded document and, on completion, publishes a notification that the platform re-emits as the Inngest event app/case/file.ingestionSucceeded. That event already triggers structured extraction in the AI platform, which already has schemas for dates/deadlines (UpcomingCaseEvent — court dates, deadlines, expirations) and for predicted next actions (CaseTask), all produced by the same structured-LLM-with-versioned-prompt pattern. The genuinely missing pieces are a per-document extraction step and, above all, a write-back: the AI platform only ever reads from the platform today.

flowchart TB
  D[Document added] --> ING["ingestion
parse + index"]
  ING -->|completion notification| BR["platform bridges to
app/case/file.ingestionSucceeded"]
  BR --> EX["AI platform:
extract dates + actions
from the new doc's text"]
  EX --> WB["Write-back to lawrence-api
(NEW outbound path)"]
  WB --> PR["Proposed key dates / tasks
attributed to the source doc"]
  PR -->|lawyer confirms| L[On the matter's list]
  classDef d fill:#eef1f6,stroke:#9aa3b2,color:#1f2430;
  classDef n fill:#fff,stroke:#5a8a64,color:#1f2430,stroke-width:2px;
  class D,ING,BR,EX,PR,L d; class WB,PR n;
  

5 · Key design decisions

Only genuine forks — a reasonable reviewer could argue the other way. The Proposed column is my recommendation, not a settled call. Comment on any row.

6 · Open questions

• OQ1 — Task-type boundary. Which task types can Lawrence meaningfully complete this milestone? Ship the action on all tasks and let it decline in-thread, or gate to validated types? (PRD open question.)
• OQ2 — Review surface (resolved for M2; rest deferred). M2 reviews per-thread via the agent sidebar + the linked thread — no aggregated view. The firm-wide "everything Lawrence did" surface (its filters, cross-matter and background scope) is the agent proposal queue's concern, deferred until background execution exists.
• OQ3 — Agent identity (resolved). Settled: a first-class per-firm agent identity, not the flag/sentinel. The full identity + access design (borrow / mint / grant, isolation, autonomous modes) is its own plan — Lawrence as a first-class identity.
• OQ4 — Does M2 start the task redesign? KD2 defers the status-enum migration. If the team believes the redesign is inevitable, is it cheaper to start the enum now rather than add a third timestamp we later unwind?
• OQ5 — Extraction precision bar & de-dup. What precision must extraction hit before we surface it? How do we avoid proposing a key date the matter already has — deduping against both the matter's existing tasks/key dates and the tasks + key dates the case context already holds (CaseTask + UpcomingCaseEvent)?
• OQ6 — Concurrency & ownership. What happens if a lawyer edits or reassigns a task while Lawrence is mid-work in its thread? Who wins, and how do we make that legible?
• OQ7 — Confirmation boundary. Every agent-initiated write is confirmed via ask_user_question. Should the writes that follow the user's own action be implicit — assignee → Lawrence (they clicked "Assign to Lawrence") and mark for review (the done signal) — while only agent-decided changes (rename, reschedule, relink, new task/key-date, delete) prompt a confirm? Proposed: yes, those two are implicit.

7 · Rollout

• Flags. The matter task tab and the Lawrence 2 sidebar are already flag-gated; gate the new "Assign to Lawrence" action and auto-extraction behind their own flags so each can ship and be dogfooded independently.
• Sequence — fastest path to user value (which is also the Linear milestone order). Order by what puts capability in a lawyer's hands soonest: (1) expand the agent's allowable VFS actions — let Lawrence manage task state (mark for review, delete-with-HITL, assignee), the quickest visible capability on top of what exists (VFS milestone); (2) backend identity, which unblocks assignee → Lawrence itself (Backend identity milestone / the identity plan); (3) the execution button — assign from the list + the task ↔ thread link (§1, Execution button milestone). That first cut ships value with review via the sidebar + thread (§3). After it: (4) the agent proposal queue (planned separately) — the deferred prerequisite for both background review and extraction; (5) document extraction (§4), which is gated on the queue because its background-produced proposals need that confirm surface.
• Quality gate for extraction. Version prompts in Langfuse and evaluate precision/recall on a labelled document set before enabling the write-back for a firm; start in propose→confirm so early misses are caught by the lawyer, not committed silently.
• Attribution & audit. Every Lawrence-driven state change (assignee, review, delete, auto-created item) must be attributable — to the thread for interactive work, to the source document for extraction.
• Failure behaviour. Confirm before build: agent write failures should surface an error in-thread (not a silent no-op), and a delete that races a concurrent edit should abort and tell the lawyer rather than clobber.

8 · Execution & review plan

PRs atomic by responsibility, grouped into per-repo stacks (≤7 each). Sizes below are estimates for review, not measured against a prototype — calibrate before committing.

Required dependency — Lawrence must exist as an identity first. The assignee work (Stack A1 / §2) cannot land until the Lawrence as a first-class identity project ships: Lawrence has to be an assignable identity before it can be set as a task's assignee. That project is a prerequisite for M2's execution, not an optional detail.

Stack A — matter-service + identity (backend)

Stack B — Lawrence agent

Stack C — legal-os (frontend)

Stack D — auto-extraction (AI platform + lawrence-api) · blocked by the queue

Gated on the agent proposal queue. Extraction produces background proposals with no live thread, so this stack can't ship until the queue exists to provide their confirm surface — it sequences after the queue, not in M2's first cut.

Glossary

Domain + plan shorthand, so no tribal knowledge is needed.