01Where it lives
No existing LEX project fits. Lawrence 2.0 MDP is launch-polish (Sedona), Skills MDP is product-scoped, the rest are features. This is platform/enablement work — a framework anyone builds agents on — so it deserves its own home.
Agent Platform project (LEX team, lead: Adolfo). Holds the framework + capability-sequence work, distinct from the Lawrence-2.0 product projects. Can roll under the existing “Lawrence 2.0” initiative for now, since full Lawrence-2 TS migration is the headline payoff. The skills-migration ticket also cross-links to Skills MDP.02The tickets
Six tickets, not one-per-PR. The 11-PR stack collapses into one framework-core ticket; observability is its own (last PR) with a deferred follow-up; the spike carries all the docs and decisions; then four upcoming pieces.
Shipped / in review
The umbrella planning + decision record. Description carries all the architecture docs; progress tracked as comments. Keep as the single place the thinking lives.
The keystone: generalised agent API (route by slug, optional matter), defineAgent builder, sealed registry, model-provider registry, run + chat transports, plus the two trial agents and a dev dogfooding switch. The whole stack in one ticket.
Agent runs trace to the dedicated agents Langfuse project via the AI SDK v7 telemetry integration: generation + tool spans, prompt-version link, environment (local/dev/prd), and per-agent metadata. Last PR of the stack.
First pass deliberately uses the default AI SDK instrumentation to keep complexity down — it isn't yet at the level of the Python agent (custom span shaping, trace naming, tags, session/user attribution). Follow-up: post-run trace naming/tags and richer spans toward Python-agent parity.
Upcoming
Today buildVfsTools emits one tool per namespace × verb (vfs_read_documents, vfs_list_documents, …) — the tool surface explodes as namespaces grow. Reshape to one tool per verb taking a namespace argument (read/list/create + resourceId), the way we expose the domain to the agent.
The thread/transport model assumes a matterId. Generalise it so agents can run in non-matter scopes (firm, user, org, jurisdiction) — the prerequisite for non-matter agents and background runs. Independent of the VFS track: only needs the shipped transports, so it can run fully in parallel with the core spine.
The VFS is matter-scoped (matterId from context). Generalise to firm-scoped namespaces and a matter-creation namespace (create a matter, not just read within one). Scope resolves from the now-generalised thread.
Migrate the live tools (search, create, edit, citations…) from the Python agent framework into the TS framework — the unlock for running full Lawrence 2 on the TS platform. Parallelisable per-tool once the new VFS shape lands.
The static skills currently living in the Python repo move to TS defineAgent definitions. Composes the migrated tools.
03Dependency map & what's open to parallelise
Top lane is the core spine I'm driving; bottom lane is open for someone to help with. Left-to-right is dependency order, and green-dotted nodes are independent — startable now (they only need work that's already shipped, so they don't wait on my active track).
04Open questions to settle
| # | Question | Leaning |
|---|---|---|
| 1 | New Agent Platform project, or fold into an existing one? | New project, under the Lawrence 2.0 initiative. |
| 2 | Relabel LEX-646 away from “Spike”, or keep the label for cycle history? | Keep LEX-646; enrich description, log progress as comments. |
| 3 | Do the upcoming four want point estimates / a target cycle now? | Estimate the two “next” ones; leave “later” unsized. |
| 4 | Which open item do we want picked up first? | One of the two independent ones — generalise threads or deferred instrumentation — since neither blocks on my core track. |