All work
IN PRODUCTION · NDA2026

Multi-agent litigation platform

~40 specialized LLM agents composed into staged synthesis pipelines.

Architecture walkthrough available on request

~60%
reduction in token spend
~40
specialized agents
Live
in production with paying users

The problem

Litigation teams spend enormous associate hours on work product that's high-volume but structurally repetitive. The bottleneck isn't legal judgment — it's the mechanical work between judgments.

The contract is the architecture

Every handoff between stages is a Pydantic-validated schema with explicit status enums and mandatory evidence citations. Agents cannot pass prose to each other — only typed payloads that fail loudly when a field is missing or a citation is absent. This is what makes ~40 agents agree with each other: the validation boundary catches disagreement at the seam rather than letting it compound downstream.

Staged synthesis, not a swarm

The pipeline runs as seven ordered stages via LangGraph rather than as freely-communicating agents. Each stage consumes the previous stage's typed output and emits its own. Ordering is explicit, so a failure is attributable to a stage rather than to an emergent interaction, and any stage can be re-run in isolation against a stored payload.

Provider abstraction and failover

Each stage routes across Claude, Gemini, and OpenAI behind a single interface, with automatic failover when a provider errors or times out. Model choice is a per-stage configuration concern rather than something baked into agent code, which makes it cheap to move a stage to a different model when its evaluation numbers justify it.

Cost engineering

Shared case context is cached with a stable prefix and memoized per session rather than re-read per agent. With ~40 agents touching overlapping context, naive re-reading dominated spend; prefix caching and session memoization cut roughly 60% of token cost without changing any output.