The loop, in TypeScript

The loop is already being rewritten

Capability 02 — the framework refactor in One loop, many Lawrences — is a from-scratch rewrite of the loop. ChatAgent.generate_stream() is ~780 lines welded to an HTTP request, and the plan tears it down to BaseAgent + hooks. So the rewrite cost is committed; the only open question is which language to rewrite it in.

Rewriting the loop in TypeScript rather than Python is a marginal delta on work that is already committed — and it unlocks a structural win.

Two things make TypeScript the high-leverage version of that same work:

• lawrence-api is already TypeScript. It owns the thread model and consumes the ai-stream wire format the loop emits. Today every wire-format change is a two-language, two-repo edit across a Python emitter and a TS consumer. A TS loop collapses that seam into one language with shared types — a structural win only this path unlocks.
• The Vercel AI SDK gives the loop's four hard requirements as first-class primitives. A multi-step agentic loop with stopWhen; zod tools; tool execute as an async generator that yields progress (the direct analogue of our BaseToolExecutionDelta); and gateway/provider routing. We are not building a loop framework in TS — we are adopting one.

This doc takes the decision already made — not Eve, no fully-managed infra, only the agent runtime moves, lawrence-engine and ingestion stay Python — and works out exactly what that costs, tool by tool, plus where the Vercel primitives (Sandbox, Workflow, AI Gateway) actually fit once you check where the data lands.

The dependency gravity is the real story

What each shared library a tool depends on becomes in TypeScript. The two biggest are transport — client stubs to lawrence-api and the services — so they're deleted, not reimplemented:

The matter-data tools reuse @lawhive/content-framework + the service clients, which already exist in TS — so they're a straight port, not a rewrite of the data layer.

The migration's real cost is the loop itself plus the genuinely-new TS pieces: the ai-stream wire contract, the citation parser, and legal-sources' AKN/XML. The runtime calls services the way lawrence-api already does, so content-retrieval and kms-utils don't carry over — there is no Python data layer.

The pattern: stage working copies of matter files into a sandbox, let the agent run code that transforms or assembles them in one pass, return the result. (Court bundling is the first driver; the capability is general.) Vercel Sandbox is the obvious primitive — except for where it runs.

The design is runtime-independent: the agent passes file refs, never bytes or credentials; lawrence-api stages a decrypted, curated subset and holds the keys; a vetted library does the deterministic work; output returns through a preview-then-confirm step; egress is locked and the sandbox is non-persistent. Only the microVM swaps.

So the runtime is AWS Bedrock AgentCore in eu-west-2, inside Lawhive's own AWS account — the same boundary where lawrence-engine and ingestion already live. (Confirm current eu-west-2 availability before committing.) Since v3 serves both US and UK traffic, route the compute by the matter's residency — UK matters to eu-west-2, US matters to us-east-1 — under one multi-region AgentCore API; the runtime-independent design makes that a routing config, not two builds.

Code execution is the most expensive way to get a result — it earns its place only when the work is genuinely open-ended.

It is demand-sequenced and last on the capability ladder. Where a fixed in-region engine call serves the need, prefer that; stand up the sandbox when a capability genuinely needs agent-written code — in eu-west-2, not iad1.

So is Workflow the same orchestration-only model as Inngest? No. With Inngest you run the execution and the cloud orchestrates; with managed Workflow, Vercel runs your step code on its own Functions. The only way to keep compute on our servers under the Workflow umbrella is the self-hosted Workflow SDK (Postgres World) — which also means owning the Postgres durable backend, i.e. fully self-hosting, with no edge over self-hosting Inngest. Either way the TS runtime enqueues and awaits Inngest functions via the Inngest TS SDK, so keeping Inngest is fully compatible with the TS loop.

The honest residency picture, now that we've confirmed we're on Inngest Cloud: durable step state already lands in the US today, and in the managed tier of both products that's unavoidable. So "keep Inngest" wins not because it's fully EU, but because it keeps execution on our servers, adds zero migration, and doesn't also move compute to the US the way managed Workflow would. Two levers narrow the exposure without leaving Inngest: keep the agent's LLM/tool loop in one coarse step — or outside durable steps entirely, using Inngest only to trigger/background — so PII-bearing loop internals are never checkpointed to Inngest Cloud (the same lever that controls cost); and if a hard EU-residency line is required, self-host Inngest (single binary, Postgres + Redis, eu-west-2), which removes the US state entirely. Workflow would only win if Vercel both ships EU persistence with a contractual guarantee and eliminates the per-step replay overhead. Neither is true today.

What v7 changes here (June 2026). When this was written, the self-hosted Workflow SDK (Postgres World) had "no edge over self-hosting Inngest." v7 gives it one: WorkflowAgent (@ai-sdk/workflow) is built to run on that runtime, so backing it with @workflow/world-postgres (own Postgres + an ECS Fargate worker; graphile-worker; Postgres NOTIFY/LISTEN; zero Vercel callout) yields durable runs, restart-surviving approvals and stream persistence in eu-west-2 — the pass-2 durable-streams capability, native and in-region. There is no viable Inngest "World" adapter (the interface mismatch makes building one a bad bet), so the call is cleanly either/or: WorkflowAgent + Postgres World vs keep Inngest and compose ToolLoopAgent inside a step.run (reuses today's pattern, but we re-implement approvals / replay / stream-persistence ourselves). Left open pending a spike; either way Inngest stays for non-agent background jobs.

The first agent on the TS runtime isn't Lawrence — it's a matter-intake agent. An admin finishes an intake call, drops in the documents and a couple of notes, and the agent opens a matter pre-populated with a title and summary, custom fields, key dates and tasks, in OPENING status for the admin to confirm. It's the deliberate opposite of Lawrence: firm-scoped (it creates the matter, so no matterId goes in), admin-principal, a handful of write tools, and a structured output instead of free-form chat.

That's exactly why it's the right trial — it exercises the whole generalised-agent envelope at once (scope, principal, a reduced tools() set, structured output), and the only new infrastructure it forces is a single matter:// create tool; key dates, tasks, notes and custom fields the platform already exposes. Bounded blast radius, real value, off the chat path.

Intake is the proof; the platform is the point. We learn the slug / principal / scope envelope on a job nobody enjoys doing by hand, then reuse it for the rest of "many Lawrences."

The full trial — the agent spec, the v3 matter-model grounding, and the one capability to build — is in the matter-intake trial companion.

Frameworks we benchmarked

Before committing to a thin in-house framework on the AI SDK, we wrote up the two strongest off-the-shelf harnesses against this exact proposal. Neither changes the recommendation — one is worth adopting later, the other worth borrowing from.

Mastra's Agent Harness (full evaluation) — built on the same Vercel AI SDK we're porting to, so its harness (sessions, observational memory, approvals, sub-agents, modes) drops into lawrence-api as a library: our own Postgres via pg.Pool, an Inngest-backed runner for durable runs, no separate runtime and no leaving our base. It's the one framework worth adopting for the deferred pass-2 layer if we choose not to build those primitives ourselves. Verdict: viable pass-2 adopt — revisit when we reach sessions and memory.

Flue (full evaluation) — the Astro team's headless, durable-first harness (Apache-2.0) is the mirror image: a clean design, but built on Pi / pi-ai rather than the AI SDK. Adopting it means re-platforming off our base, embedding into Hono instead of Express, and betting legal PII on a one-week-old beta — and its remote() sandboxes reintroduce the US-pinning we rejected for Vercel Sandbox. State, at least, is self-hostable on our own Postgres in eu-west-2. Verdict: don't adopt — but borrow its Durable Streams design (append-only event log, resume/reconnect, pluggable Postgres store) as the blueprint for our deferred durable-sessions work.

What v7 does to this (June 2026). AI SDK v7 now ships the headline pass-2 primitives natively — durable/resumable runs (WorkflowAgent, self-hostable via @workflow/world-postgres) and tool approvals (HITL) — on our own base. That partly supersedes both verdicts: the case for adopting Mastra in pass-2 shrinks (the SDK now gives us sessions / approvals / durable runs directly), and Flue's "borrow Durable Streams" is largely redundant (the SDK has it). Both stay useful as references, not dependencies.

What stays Python — forever

lawrence-engine (CCO, material-case-change, proactive) and ingestion are out of scope and stay Python — they aren't agent loops, and they're genuinely separate services. That's it. There is no Python data layer to keep on the agent side: matter data lives in lawrence-api (TS) and the domain services, and content-retrieval — the Python client lib that reached them — is deleted, because the TS tools call those services directly via the shared framework. The tools decrypt nothing, so nothing crypto-sensitive crosses a language boundary — because nothing crosses at all. Inngest stays polyglot; the TS loop enqueues its Python functions via the TS SDK.

Open questions

• Inngest Cloud step-state residency. Confirmed: we're on Inngest Cloud (orchestration, US) with execution on our own servers — so durable step state already lands in the US. Decide the line: coarse-step the loop to keep PII out of checkpoints, or self-host Inngest for hard EU residency.
• Per-matter region routing. Since v3 serves both US and UK traffic, code execution over case files should route by matter residency — confirm the jurisdiction signal exists on the matter and where that routing decision lives.
• AgentCore eu-west-2 specifics — current availability, runtime image, and S3 file-flow limits; verify before committing cap-06 (code execution).
• AI Gateway data-path residency — do UK/EU prompts transit the US before routing? If unverifiable, default to a self-hosted in-region proxy via createOpenAICompatible.
• Loop step granularity in Inngest — pull real loop-iteration counts from Langfuse before fixing the step model (one coarse step vs step-per-iteration drives both cost and resilience).
• Citation config lifecycle — is it read-only per call, or mutated across steps? Decides the shape of the TS loop wrapper.
• Durable-runs backend (v7) — WorkflowAgent + self-hosted @workflow/world-postgres (eu-west-2) vs keeping Inngest and composing ToolLoopAgent in a step.run. Spike the Postgres World on ECS before committing; managed Vercel Workflows stays iad1-only and is out.
• v7 build-time gates — v7 is ESM-only but lawrence-api ships a CJS bundle (bun build --format=cjs, no "type":"module"); confirm the bundle still boots with ai@7. The root pnpm.overrides["ai"] pin forces lawrence-api + legal-os in lockstep — scope it so the api can migrate first. Node is already 24.