Why we open-sourced Currai
Agent quality depends on real conversations. The teams learning from those conversations should be able to inspect, adapt, and run the software that interprets them.
A support agent answers a question, calls a tool, and closes the conversation. Every request succeeds. The customer still has to repeat the question to a human.
That is the gap Currai is built to examine: the distance between an agent running successfully and a user getting what they need. Conversations help reveal user intent, recurring failures, and behavior that crosses a product's rules.
But the software interpreting that evidence deserves scrutiny too. If a dashboard says an agent failed, your team needs to understand what that finding means and whether it fits your product.
That is why we want Currai to be open source. Teams should be able to read the code, run their own instance, and adapt the analysis around the work their agents actually do. You can find the project on GitHub.
The measurement should be open to inspection
An agent-quality label can influence what a team fixes next. A repeated question might mean the answer was unclear. It might also mean the user is checking a detail before making an important decision. The conversation matters.
Open code lets engineers inspect how evidence enters the system, how it is stored, and how findings reach the dashboard. That makes it easier to investigate a surprising result instead of treating the dashboard as an authority.
It does not make every classification correct. Model-based analysis still needs review against real examples. Transparency gives teams a way to examine the measurement alongside the behavior being measured.
Teams need room to define quality for themselves
A booking assistant and a coding agent should not share every success criterion. For one, success may require confirming a date and collecting a contact method. For the other, it may require a working change and evidence that the relevant checks passed.
Currai's intent and violation rules let teams describe what matters in their product. Access to the source provides another level of control: developers can inspect the implementation and adapt it when a workflow needs more than a configuration change.
Consider a support team that wants to distinguish a user abandoning a conversation from an agent completing a refund. Those outcomes need different evidence. Being able to examine and extend the software helps the team make that distinction explicit.
Running your own instance should be a practical choice
Agent conversations can contain internal context and customer information. Some teams need to choose the infrastructure that stores this evidence, the people who can access it, and the process for deleting it.
The self-hosted edition gives operators responsibility for those choices. Its application features do not depend on Currai subscriptions, credits, or event quotas. Infrastructure and model-provider costs still apply.
Self-hosting also involves real work. You operate the application, configure its services, and handle updates and retention. The repository's setup instructions describe the required dependencies; running your own instance does not mean that every service runs offline.
The useful choice is whether your team wants to operate the system or use a hosted service. Open source makes operating it an option you can evaluate directly.
Contributions can start with a concrete failure
An unusual tool response, a missing event, or a misleading finding can become a reproducible issue. When the implementation is available, a developer can follow the evidence through the system and propose a fix.
We want that feedback to come from the environments where agents are actually used. A useful contribution might be a clearer setup instruction, a connector fix, or a small change that makes an ambiguous finding easier to review.
If you report a problem, use synthetic or redacted examples. Explain what you expected, what happened, and how someone else can reproduce it without access to customer conversations.
Start with one conversation you understand
Explore the Currai repository, follow its setup instructions, and connect a small test application. Use a conversation whose intended outcome is clear. Then check whether the evidence and findings match what you observed.
That is the standard we care about: analysis your team can question, understand, and improve. For more on the operating decisions involved, read why your team should own its agent analytics.