Chase Robbins
Building Kirby, our internal AI teammate, and the culture that made it possible
What does it mean to be an AI-native startup?
"AI-native" gets used loosely, so let me be specific about what it means for us at Kubera.
We specifically didn’t want to bolt a chatbot onto our product and call it a day. Instead, we're working to weave AI into how our company operates: how our engineers ship, how our client services team loads and audits contracts, how we recruit, and how our leadership makes decisions.
We are a team of about ten building software that turns hundreds of thousands of pages of dense payer contracts into structured, queryable data, and offers a number of complex applications built atop that data. Being AI-native is how ten people do the work of a much larger company, and how we stay close to the cutting edge of a field that is moving incredibly fast.
A few core core beliefs that shape our internal AI strategy:
Everyone should be able to build, not just engineers. If only engineers can implement AI into workflows, you will end up with minimal AI adoption outside of the engineering team. The primary reason for this is that the highest leverage AI utilization is often in the hyper-specific, painful workflows that require significant domain specific knowledge to understand.
Bring the best tools together, then build our own. We use the best external tools available, but our real edge comes from building AI that is deeply connected to our own data, our own codebase, and our own workflows.
Our internal goals
When we set out, we had a few concrete goals for internal AI adoption:
Raise the AI floor for the whole team, not just the ceiling for engineers. Get every single person building or automating something real, regardless of technical background.
Cut the manual, repeatable work that eats operational time: recurring reports, contract processing, reconciliation, and follow-ups.
Make our own data the center of gravity. An AI teammate that can safely read our production database and codebase is far more useful than a generic chatbot that knows nothing about us.
Do it without compromising on security or compliance. We handle sensitive healthcare data. Anything we build has to be HIPAA-compliant by design.
How we actually did it:
The Monthly Lunch and Learn. We started with a company-wide AI Lunch and Learn: short, practical demos of AI actually inside our workflows, not theoretical slides. Engineers showed how they use cloud coding agents and code review automation. Our leadership showed off connectors that plug AI into the tools we already live in: Linear, Slack, Drive, Calendar. And, importantly, our traditionally less-technical teammates presented too. Many of our presentations came from non-engineering contributors who were encouraged to share how they’ve adopted AI into their workflows or how they were using Claude code or agent builders. This mattered more than any polished engineering demo because it made the whole idea feel achievable, and raised the bar of expectations of what’s possible today.
We followed up with a company hackathon and gave everyone a simple assignment: between now and the end of the day, build one or two things. It did not need to be polished. The point was to go figure it out, read the guides, run experiments, and break stuff. For less technical folks, that meant experimenting with vibe coding and no-code tools. For engineers, it meant going deeper on agents. We blocked off an entire day and broke our company into mixed teams of 2-4 and had engineering support floating amongst the teams to offer technical expertise.
One of the things that came out of it, a contract codification agent that automatically adds billing codes to rate schedules, went on to become real product capability. That is the flywheel we wanted: a culture of AI experimentation leads to product, and ultimately maximum value for our customers.
Meet Kirby
Out of that culture came Kirby, our internal AI teammate.
Kirby is the assistant we built for ourselves. What makes Kirby different from a generic AI tool is what it is connected to:
Our production data, with safe, read-only, tenant-aware access, so anyone can ask a question in plain English and get a real answer instead of writing SQL.
Our codebase, so it can explain how features actually work.
The tools we work in every day: Slack, Linear, Gmail, Calendar, meeting notes, and more.
Automations, so recurring work can just run on a schedule instead of relying on someone to remember.
Crucially, Kirby is HIPAA-compliant, which means the team can use it for real operational work involving sensitive data, rather than reaching for external tools that cannot touch it.
It has become genuinely woven into how we work. Our operations team now uses Kirby to process complex contracts directly against our own data instead of outside tools, because the accuracy is better when the AI actually knows our platform. We even track an internal usage leaderboard, which has turned "who is getting the most out of Kirby" into a bit of a team sport.
Kirby has routinely filed bug reports and feature requests about itself. It hits an error, it can diagnose the problem and open a ticket for our engineers to fix it. Additionally, if a user is trying to accomplish something that Kirby requires more tools to do, Kirby will file a ticket requesting a bespoke tool for this use case. As a result of these self reported requests, have built integrations into sales tools, second brains, meeting recorders, web search, and more.
The end state isn’t a better chatbot, but an AI-teammate that is self improving and becomes higher leverage as we build and share more context and integrations. Today, Kirby loads and cleans much of our claims data, and one team member even made him their “Kubera Boyfriend,” who texts good morning with a daily digest of all to dos and important information to catch up on. We’ll check back in next year around whether he gets promoted to autonomous claims handler and/or fiancé.