CourtHelp: Building a Court Chatbot Platform Before the Standard Existed

The full story

The problem

The Los Angeles Superior Court is the largest trial court in the country. Much of what the public asks it comes down to a handful of needs: where do I go, how do I pay this, what do I do with my jury summons. A well-organized website can answer some of those. Others are transactions, like registering for jury service, postponing it, or finding a hearing and checking in. We had chatbots that handled some of these on their own, and each one worked. But a member of the public shouldn't have to know which bot to talk to.

The idea: one front door

In early 2025 we set out to build a single entry point. CourtHelp would read each question and hand it to the right specialist: a knowledge chatbot that answered from the court's website and PDFs, a jury chatbot that could complete transactions, and more to follow. Internally we called it the "lord of all chatbots."

Version 1: building the plumbing ourselves

At the time, there was no settled standard for connecting an AI assistant to a set of tools. We evaluated open-source multi-agent frameworks and decided our needs were simple enough to build in-house. That meant building every piece of the plumbing:

• Routing. We started with a trained intent classifier. Then we moved to a language model that picked a chatbot based on plain descriptions of what each one did.
• A registry. Each chatbot was a record with a name, an endpoint, and a description, so new bots could be added without rewriting the orchestrator.
• Memory. Every request to the model was stateless. We tracked each conversation by session ID and packed a condensed history of earlier turns into each prompt so the model wouldn't lose the thread.
• Multi-step transactions. Jury registration asks a series of questions in order. We built a "transaction lock," a set of flags that told CourtHelp a user was mid-task so their next reply went back to the jury bot, plus rules for letting them out when they changed the subject.
• Search. We vectorized the court's website and PDFs into a search index. We learned early that content structure mattered as much as the model. PDFs skewed relevance, and clean page metadata and URLs improved answers more than prompt tuning did.
• Guardrails and feedback. Every prompt passed through guardrails, such as no legal advice. Every turn was logged. Thumbs-down responses fed a daily report that the web, communications, and development teams triaged into three buckets: missing content, missing keywords, or a missing capability.

CourtHelp launched alongside the court's new website in July 2025, and a hearings chatbot (find a hearing, set reminders, check in) was built next.

What running it taught us

The design worked, but much of our engineering went into problems that had nothing to do with courts. The transaction lock was the hardest part. Every bot had to follow the same conventions, and a conversation that went sideways was painful to debug. Each new chatbot also meant custom integration work, which made it hard for other teams to build their own.

The shift to MCP

Meanwhile, the Model Context Protocol (MCP) matured into a widely adopted standard for connecting AI applications to tools. When we looked closely, it described almost exactly the architecture we had built by hand: a client that decides which tool to call based on the tool's description, and servers that declare what they can do. So the platform was rebuilt on it.

• CourtHelp became an MCP client, and each chatbot became an MCP server exposing tools with plain-language descriptions. Routing now comes from the protocol itself.
• The transaction lock was replaced by MCP elicitation, which lets a server ask the user follow-up questions through the client and pick up exactly where it left off. A thin wrapper validates answers and hands off-topic messages back to CourtHelp for rerouting.
• Session state moved into the agent framework, and the hand-built history compression was retired.
• New chatbots start from a shared server template and are registered with CourtHelp, so other teams can build their own.
• Every model call goes through one configurable endpoint, so switching from a cloud model to an on-premises one is a configuration change, not a rewrite.

How it works today

Lessons Learned

1. Invest in the architecture, not the framework. The orchestrator-and-specialists design survived intact. Much of the custom plumbing holding it together could be retired once a standard existed.
2. Content quality beats model quality for public-facing questions and answers.
3. Instrument feedback from day one. The daily negative-feedback report drove most of our improvements.
4. Keep the pieces swappable. Because we had, adopting the standard was a migration rather than a restart.