Inspiration
The idea behind Docket — Multi-Counsel Case Analysis came from a simple question: what if an AI didn't just give you one answer, but actually argued with itself before giving you a conclusion?
When working through complex legal problems, a single perspective can miss weaknesses, assumptions, evidence gaps, or alternative interpretations. I wanted to recreate something closer to a real strategy room, where multiple people examine the same case from different angles and someone actively tries to break their arguments.
That led me to build Docket as a multi-participant AI discussion room. The project uses three discussants — Jashan, Gursehaj, and Keshav — alongside Simar, a dedicated critic whose role is to challenge the reasoning rather than simply agree with it. The system is designed around the idea that a theory becomes stronger when it survives serious criticism, not when it is accepted immediately.
What I Learned
Building Docket taught me that creating an AI application is much more than simply connecting an API to a chatbot.
I learned how to:
- Design structured multi-stage AI workflows instead of a single prompt-and-response experience.
- Give different AI participants distinct roles and instructions.
- Maintain a shared conversation transcript across multiple rounds.
- Use one AI participant as a dedicated critic that actively stress-tests other arguments.
- Generate case-specific follow-up questions before beginning the main analysis.
- Control the depth of an AI discussion through selectable Normal, Thorough, and Extreme modes, corresponding to 3, 5, and 8 rounds.
- Handle API failures, rate limits, timeouts, and temporary service errors through retry logic.
- Turn a long AI conversation into multiple structured draft strategies.
- Think carefully about how prompts affect reasoning quality, consistency, and hallucination risk.
One particularly important lesson was that AI orchestration matters as much as the underlying model. The value of Docket comes from the interaction between roles, context, rounds, criticism, and synthesis rather than from asking a model one large question.
How I Built It
I built Docket as a web application with a staged workflow.
The user first enters a case summary. The system then uses the AI to generate five case-specific follow-up questions so that important details such as jurisdiction, documentation, procedural posture, and desired outcome can be clarified before analysis begins.
After that, the user chooses how deeply the system should debate the case:
- Normal — 3 rounds
- Thorough — 5 rounds
- Extreme — 8 rounds
The discussion room then runs each round sequentially. Jashan, Gursehaj, and Keshav analyze the case, while Simar speaks last and critiques what everyone has said. This creates an iterative loop where later responses can react to earlier arguments instead of operating independently.
Each discussant is instructed to consider factors such as:
- strongest legal theory
- weakest link
- procedural posture
- burden of proof
- available and missing evidence
- documentary record
- credibility
- opposing arguments
- precedent or statutory analogies
- remedies
- fallback theories
- settlement leverage
- timeline risks
- public-interest considerations
- questions a skeptical judge would ask
The critic has a separate instruction set focused on finding unsupported assumptions, causal leaps, evidence gaps, procedural weaknesses, incorrect burdens of proof, overconfidence, contradictions, and weaknesses that could be exploited by the opposing side.
Once the discussion finishes, the complete transcript is passed into a synthesis stage. The system then produces three distinct draft strategies, allowing the user to compare different theories instead of being locked into the first answer the AI generated.
The frontend is built as a structured six-stage experience — intake, questions, discussion, synthesis, drafts, and the final working file — rather than presenting the user with a conventional chat interface.
On the backend, I use a serverless API endpoint to communicate with Gemini. The frontend sends the selected model routing key, system instructions, conversation messages, temperature, and token limits to /api/llm. The backend then handles the model request and returns the generated response.
Challenges I Faced
One of the biggest challenges was making the discussion actually behave like a discussion.
Initially, the system could stop early when multiple participants indicated that they had converged. This created a problem because choosing a longer discussion mode did not necessarily mean the application would actually complete the selected number of rounds. I changed the logic so that the room now runs the full number of rounds selected by the user, unless the user explicitly chooses “Stop & Synthesize Now.”
Another challenge was reliability. Longer AI discussions generate many API requests, making temporary rate limits, quotas, timeouts, and server errors more likely. I added retry behavior with short backoff periods for errors such as 429, 502, 503, and 504, as well as quota and timeout-related failures.
I also had to solve the challenge of keeping AI reasoning grounded. Legal analysis is particularly sensitive to fabricated citations or invented facts, so the prompts explicitly instruct the participants to stay within the provided case facts and avoid inventing specific statute numbers when uncertain. Instead, the system can describe the relevant type of provision without pretending to know an exact citation.
Finally, I learned that giving every AI the same generic prompt would not create meaningful disagreement. The participants therefore have different roles: the discussants develop and refine theories, while the critic is specifically instructed to attack those theories. This makes the interaction more adversarial and useful than simply generating four independent answers.
What Makes It Different
Docket is not designed as a traditional chatbot that gives an immediate answer.
It is designed as an AI reasoning environment:
Question → Multiple perspectives → Debate → Criticism → Refinement → Synthesis
The core idea is that the best answer may not be the first answer an AI produces. It may be the argument that remains standing after several rounds of structured disagreement.
The final output is also deliberately treated as a working draft rather than an unquestionable conclusion. The application explicitly frames its strategies as material for review and further refinement, keeping the human user responsible for the final judgment.
That combination of multi-agent orchestration, adversarial criticism, iterative reasoning, and human review is what I wanted Docket to demonstrate.
Log in or sign up for Devpost to join the conversation.