Spring brings Life (Sciences)

To our regular blog readers: sorry for missing the April update. A lot has happened since. Turns out KIRHA’s OVNI doesn’t do spring cleaning. It does spring delivering.

Every marketplace founder must solve the infamous chicken-and-egg problem. Ours clicked in life sciences and healthcare. Which brings us to today: health.kirha.com, AI agents powered by kirha.com.

Why focus on this vertical? Our user base gave us strong signals, and we saw a dense cluster of use cases dependent on both public and private external data, all set within a landscape of strict regulation demanding auditable AI context and certified runtimes. The insight: deliver value with the agents first, and the data providers will come. Cureety is onboarding now. CRO and Pharma we can’t disclose yet are following suit.

This is how we ended up at Santexpo, the flagship event of the French healthcare ecosystem.

Business & Ecosystem

We onboarded Vidal, the iconic drug dictionary, to power our Clinical Decision Support (CDS) agent. Medical knowledge now doubles every 73 days. KIRHA embeds it in every decision: real-time, source-grounded search inside clinician-facing products. Every answer backed by the latest guidelines, trials, and labels, resolved in the native grammar of each source.

Professionals don’t trust, they verify.

In the case of Cureety, we needed Vidal to make sure the drugs recommended by the system were AMM-compliant and available in France.

Funny that their booths were side by side at Santexpo. We should have been right in between. Life Sciences and healthtech AI rely on dozens of external data provider integrations.

That’s exactly what KIRHA is: the auditable routing layer in between.

Vidal will also power other agents like Pharma Regulatory and Pharma Vigilance. One provider onboarded, multiple agents powered. That’s the flywheel.

From clinical decision support to clinical trials

We’re building coding agents for Pharma and CRO to speed up trial data processing, suggesting SDTM mappings from raw trial data and generating transformation code in SAS, Python or R, ready to submit to the FDA. This used to take weeks of work from data managers and biostatisticians. Our agent does it in a day.

On the infrastructure side, we signed an agreement with Google Cloud for Health Data Hosting. The regulatory reality is the same on both sides of the Atlantic: under French HDS rules, under HIPAA in the US, you cannot simply upload patient data to an AI and hope for the best. Every API call touching patient data must go through a certified, auditable environment. That is why we built a configurable agent runtime that lets our customers pin their data to the right certified infrastructure for their geography and use case.

Tech & Product

agent orchestrator

The agent orchestrator is the software that connects all the dots. It ties together KIRHA’s open-source routing models, curated data provider network, modular certified infrastructure, and a file system with native versioning into a single runtime purpose-built for regulated industries.

It is our first service written in Rust, and we will keep writing Rust for future services. Coding agents have removed the complexity barrier of the language’s heavy syntax. They leverage the Language Server Protocol (LSP), which surfaces precise, human-readable errors that agents use to self-correct and write better code. On the security side, we get memory safety and eliminate the npm package vulnerabilities that have become a near-daily occurrence.

For agents handling regulated clinical data, security is not optional.

The philosophy is simple: provide the building blocks for polymorphic agents that adapt to any use case under the constraints of regulated industries. The orchestrator handles the compliance surface. The agent handles the intelligence, fully programmable in plain English by customers who dictate output format, code generation, document production, and more.

harness sandbox

Have you ever heard of Daytona, Blaxel, Modal, E2B, and the dozen other startups racing to solve the agent runtime problem? We know them firsthand: we won a prize at the Daytona HackSprint in SF back in January, while shipping our first Life Sciences data sources.

They’re all answering the same question: where does the agent actually run? Not the AI model but the harness, with its file system, its long-running shell, its dozen retries against a flaky API. The answer is a sandboxed container hooked up to streaming, secrets, and storage. It’s a real product category, and they’re building it well.

We built our own.

The reasoning is the same one that put us on certified infrastructure: regulated clinical data does not leave our perimeter. Security matter. We cannot hand customer files, intermediate reasoning, or generated artifacts to a third-party sandbox, no matter how polished the SOC2 report. The compliance surface the orchestrator protects ends the moment a container boots on someone else’s hardware.

So the agents-framework is our answer to the runtime problem, owned end-to-end. Written in Go (the lingua franca of the cloud-native ecosystem, with first-party SDKs for Docker and Kubernetes) it manages the full task → agent → workspace lifecycle for any containerized agent.

Claude Code, Open Code, Hermes, pi, aider: the framework doesn’t care. It supplies the plumbing: WebSocket streaming, per-task secret isolation, multi-mount workspaces with kernel-enforced read-only sub-paths, pluggable storage providers, restart recovery, idle TTL sweepers, a persisted event log with a persist_output: false switch for PHI workloads. The agent image defines the behavior.

That last switch is the tell. A third-party sandbox cannot offer you “events live only on the WebSocket and a capped in-memory ring buffer, never touching disk.” We can, because we wrote it and we keep writing it, because every layer we control is a layer our customers don’t have to take on faith.

kirha.com : an autonomous data infrastructure

While all our team’s efforts are concentrated on building agents for Life Sciences and healthcare, Kirha’s data provider network keeps growing quietly in the background. More than 1,000 users have registered to access premium, auditable context on a usage-based model, and the platform is increasingly running itself.

Every query made through the platform generates a trace on Langfuse, the observability software we use. Our internal monitoring agent analyzes those traces and spawns coding agents to improve the network. Each node is an MCP server exposing a data provider API. coding agents submit PRs on GitHub to our internal MCP monorepo, fixing bugs and proposing new integrations autonomously.

The infrastructure debugs and extends itself.

New data providers are deployed in minutes from any API spec. Our Terms of Service handle the legal layer for every integration. No new contract each time. That’s the platform model.

The one thing it can’t do is knock on a provider’s door to get an API key. Then we just have to use Polsia to reach out and convince them to onboard on KIRHA. Just kidding. I’m a strong believer in the autonomous company, but we will never automate our outreach to other humans. It’s neither efficient nor ethical.

Closing thought

KIRHA is on its way to closing its first $1M in revenue with health.kirha.com, providing agents to Life Sciences and healthcare. In parallel, kirha.com improves itself with every query. When we build agents, we prioritize the ones that need the most external data, because every new use case expands the graph and strengthens the network.

The long-term vision has not changed. A data marketplace operated by a global network of data providers, where any agent can access the right context, instantly, at the right price.

We are just getting started.