Building a Reliable, Agent-Driven Legal AI Platform for DocBrief
Wippy
Runtime
Agentic RAG
Pipeline
Multi-Tenant
Architecture
Solutions
Industries
Technologies
About THE Project
DocBrief is a legal AI product built by a Managing Partner at a personal injury firm. The vision was clear: a platform that ingests complex legal case files, extracts structured insights, generates timeline visualizations, produces AI-authored summaries, and answers attorney questions through a RAG chat interface. The founder had built a working prototype using AI-assisted coding tools. It could demonstrate the core workflows. It was not something anyone could rely on in production.
The engineering review was direct. No clear architecture. Database credentials exposed in configuration files. Multiple competing vector database implementations present simultaneously. Temporal workflow configuration not validated for fault tolerance. The system ran. It would not scale, and it would not survive production load.
Spiral Scout’s call was not to patch what existed. The faster path to a working product was a clean rebuild on the Wippy Runtime, an open-source, production-grade, multi-tenant workflow engine that gave the client the infrastructure they would otherwise have needed a team of engineers to build from scratch. Phase 1 delivered a working, multi-tenant, AI-native foundation capable of supporting real users in three weeks. The client owns the DocBrief application codebase, all workflows, insight templates, project types, and all user data outright.
OBJECTIVES
- Rebuild a structurally unsound prototype on a foundation that could actually scale.
- Deliver a multi-tenant backend capable of supporting multiple law firms without a full rewrite six months in.
- Ship five core capability areas: multi-tenancy, document ingestion, AI insights extraction, timeline generation, and RAG chat.
- Establish a foundation the client could extend without always needing an engineering team in the loop.
- Ensure the founder owned all DocBrief-specific IP with no vendor lock-in on core business logic.
Challenges
Solutions
An MVP Built Without an Architecture
The original prototype was built with AI-assisted coding tools. The output was functional enough to demonstrate the product concept. Under the surface, the codebase had multiple competing vector database implementations, database credentials committed directly into configuration files, duplicated API client code across separate files, and no shared data contract between frontend and backend. There was no dependency injection, no consistent error handling, and an abandoned test workflow sitting in the production codebase. The system worked as a demo. It was not recoverable as a foundation.
Clean Rebuild on the Wippy Runtime
Rather than attempt a refactor, the engineering team made the call to rebuild. The Wippy Runtime provided the multi-tenant backbone, workflow orchestration, long-running agent infrastructure, and event system that would have taken months to design and build from scratch. Phase 1 was scoped as a thin, stable layer across five capability areas rather than full feature modules. Ship a system that works end-to-end reliably at a reduced feature set, so the client could validate product-market fit before committing to deeper investment. The rebuilt system ran on a clean codebase with proper separation of concerns, centralized configuration management, and a Temporal implementation reviewed for correctness and fault tolerance.
AI Accuracy Across Interconnected Features
DocBrief’s core value depends on AI accuracy. If the system tells an attorney that a claim occurred at one address and the RAG chat returns a different address for the same document, the product is not usable in professional practice. The risk is not just a single wrong answer. It is that four interconnected features – Insights extraction, RAG chat, Timeline visualization, and AI summaries – each draw from the same source documents but reason over them independently. Without a shared data contract between them, conflicts are not edge cases. They are the default.
Structured Accuracy Architecture Across All Output Layers
We built a shared state model that ties every output layer back to the same source data. The Insights extraction agent, the RAG chat interface, and the Timeline visualization all read from a canonical representation of the ingested documents rather than running separate, uncoordinated inference calls. Conflicts between layers are caught at the data layer, not discovered by an attorney reviewing a deliverable. Medical billing figures, timeline event categorization, and structured insight fields all resolve against the same source of truth. When the system is uncertain, it surfaces that uncertainty rather than producing a confident wrong answer.
Scoping a Founder’s Vision Against a Fixed Timeline
The product vision was expansive: contacts as a global knowledge graph linked across all projects, insight templates that propagate updates in real time, multi-step agent flows with web search and full reasoning logs, a chat interface that eventually queries across all data simultaneously. Each of these features is a meaningful engineering effort. Taken together in a three-week sprint, they would have produced nothing usable.
Deliberate Scope Architecture
Phase 1 was written with an explicit principle: thin, stable layers of each critical capability, not full modules. The proposal named what was excluded as clearly as what was included. Flows, advanced onboarding, document viewer, settings consolidation, and contacts enrichment were explicitly out of scope and documented as such. This gave the DocBrief team a clear shared baseline for what Phase 1 would deliver and what Phase 2 would pick up. When the staging review surfaced additional items, the written scope made the classification straightforward. Phase 2 absorbed the remaining work as defined scope, with a timeline that matched the actual effort.
Strategy
The production judgment call was made at the start: do not spend time rescuing architecture that cannot be rescued. The faster path to a working product was a clean rebuild, not an incremental refactor. Every subsequent decision followed from that.
De-Risk the Engagement Before Committing to a Full Build
Phase 1 was structured as a proof of concept, not a full product commitment. It was designed to answer a single question before either party made a deeper investment: can Wippy give DocBrief the infrastructure it needs, and is Spiral Scout the right long-term technical partner? The deliverable was a working, multi-tenant foundation with five validated capability areas. Not a finished product. A stable, testable system that could support real-user validation.
Tradeoffs Documented, Not Hidden
The Phase 1 scope document named what was excluded as explicitly as it named what was included. When the staging review surfaced additional complexity, the written scope made it possible to resolve what belonged in Phase 1 and what belonged in Phase 2 without a negotiation. What was committed to was delivered. What was out of scope became the defined input for Phase 2. Write down what you committed to, then measure against it.
Build for Client Independence from Day One
The IP structure was designed explicitly to prevent lock-in. The client owns the DocBrief application codebase, every workflow, every insight template, every project type, all user data, and all legal business logic. If the client ever decided to move away from Wippy, the DocBrief-specific logic and all data would be fully exportable. The Wippy Runtime itself is open source. Phase 2 includes a commitment to training the founder to build the majority of future workflows himself using natural language within the Wippy environment, without requiring an engineering retainer for every new feature.
Project Results and Impact – Establishing the Architectural North Star
Phase 1 delivered what it committed to: a working DocBrief v1 running on a stable, scalable backend, ready for real-user testing. This is not a finished product. It is the structural foundation on which a finished product is now being built. The original codebase was not a foundation that could be compound. Every new feature would have required working around structural problems already present. The rebuilt system on Wippy does not have that constraint.
Tangible Outputs:
– Multi-tenant backend architecture supporting multiple law firm organizations from a single deployment.
– Document ingestion pipeline with AI-driven insight extraction across five structured capability areas.
– Temporal workflow orchestration validated for correctness, retry policy coverage, and fault tolerance.
– RAG chat interface with cited, structured responses and document source attribution.
– AI-powered timeline visualization for case event chronology across medical, legal, and financial lanes.
– Phase 2 scope defined and contracted, incorporating all remaining items from the Phase 1 review.
– IP ownership structure documented: DocBrief-specific codebase, workflows, templates, and data owned by the founder outright.
Key Takeaways
- A working demo is not the same as a working architecture. When the gap between the two is large enough, a rebuild is faster than a refactor.
- Scope documents are risk management tools. Writing down what is excluded is as important as writing down what is included. When the staging review surfaced additional complexity, a written scope made the classification a structured exercise, not a negotiation.
- The Wippy Runtime provided multi-tenant infrastructure, workflow orchestration, and AI agent scaffolding that would have taken a team of engineers months to build independently. That compression is the leverage a domain expert founder needs to reach the market.
- Client independence was written into the IP structure and the Phase 2 training commitment before work began, not added as a closing gesture.
Worth thinking about if you are a founder who has built a working prototype and are now trying to decide whether to keep patching it or start the rebuild.
Related projects
-
Agentic Category-Growth Narrative Engine for Intent AI
LinkA Wippy-based agent system that turns four disconnected retail datasets into one connected category growth story
-
Rebuilding a Fragile Legal AI MVP Into a Multi-Tenant, Agent-Driven SaaS Foundation
LinkA solo-built legal AI prototype rebuilt on production-grade, multi-tenant infrastructure in three weeks
-
Agent-Driven Conversion Infrastructure for a Telecom Intelligence Platform
LinkSpiral Scout built a post-decision switching assistant that keeps Navi present at the moment users most often abandon.
-
Agent-Driven AI Data Hub with Grounded Executive Reporting
LinkGrounded AI retrieval, generative reporting, and conversational search for an executive data hub. Trusted answers. Stack owned by their team.
-
Temporal Workflow Architecture Consulting for Enterprise Data Services
LinkArchitecture consulting for a visual workflow editor built on Temporal, enabling cross-department automation at enterprise scale.
-
Market Discovery & System Framing for an AI-Driven Investor Relations Platform
LinkEstablished the architectural and market foundation for an AI-native earnings call product.
SCALABLE AI FOR LEGAL TEAMS
Meet the founders
Tell us your goals
Receive a proposal
Project kickoff
John Griffin
Co-Founder, CEO
Anton “JD” Titov
Co-Founder, CTO
“Anton is an exceptional technologist. I would feel comfortable having him work on any technical challenge.” – Ryland Goldstein, Head of Product, Temporal
