Evaluation on private operational data
Task-level suites built from synthetic and de-identified records that mirror a client's real distribution, scored per step, not just end to end.
We build production agents for healthcare and other regulated enterprises, and the systems that make them safe to run: typed tools, durable execution, gated actions and an audit trail for every step.
Each system is an agent, the connectors it is allowed to touch, the gate it must pass, and the eval suite that decides whether a change ships.
Ranks the day's clinical work by risk, drafts the follow-ups, and routes each one to the clinician who owns it for approval.
| Domain | Clinical operations |
|---|---|
| Status | Production |
| Trigger | Schedule and change events from the systems of record |
| Reads | Schedules, orders, documentation and staffing, scoped per role |
| Writes | Drafts only. Every outbound action passes the approval gate |
| Gate | Role-scoped approval, bound to the exact payload |
| Models | Routed per step through the gateway; structured outputs |
| Evals | Ranking and drafting suites, run in CI on every change |
Tracks every credential, training and audit date as state, assembles evidence continuously, and surfaces risk before it becomes a finding.
| Domain | Regulatory compliance |
|---|---|
| Status | Production |
| Trigger | Daily evaluation plus change events on people and documents |
| Reads | Credentials, trainings, audit calendars and policy library |
| Writes | Staged evidence and drafted notices, gated before commit |
| Gate | Role-scoped approval, bound to the exact payload |
| Models | Retrieval over the client's own policies, cited by section |
| Evals | Deadline, retrieval and citation suites, run in CI |
Every deployment is built on the same spine. The model is one component. Most of the engineering is everything around it.
// agents/compliance-manager.ts (illustrative)
export const complianceManager = agent({
id: "compliance-manager",
trigger: [cron("0 6 * * *"), on("credential.updated")],
models: route({ reason: "frontier", extract: "fast" }),
tools: [credentials.list, trainings.status, policies.search,
notices.draft, binder.stage],
scope: { phi: "deny", write: ["binder.staging"] },
output: Findings, // zod schema, validated
gates: [approve({ role: "compliance_lead",
on: ["notices.send", "binder.commit"],
bind: "payload_sha256" })],
evals: suite("compliance/*", { blockOn: "regression" }),
audit: "append-only",
});Not guidelines. Each one is enforced in code, in CI, or both, and a change that breaks one does not merge.
Every connector is scoped to the fields one job needs. No agent holds a credential broader than its task.
Tool inputs and model outputs are validated against schemas at every boundary. Invalid output is a failed step, never a guess.
Every side-effecting call carries an idempotency key. Runs are resumable state machines; a retry cannot double-send.
Actions are classed by consequence. Anything that leaves the system needs a role-scoped approval bound to the exact payload.
Inputs, tool calls, model calls, outputs and approvals are written to an append-only audit log, reviewable per run.
Prompt, model and tool changes run the eval suites in CI. A regression blocks the merge like a failing unit test.
Open problems we work on because production agents in regulated settings depend on them.
Task-level suites built from synthetic and de-identified records that mirror a client's real distribution, scored per step, not just end to end.
Durable orchestration for multi-step agents: checkpointing, partial-failure recovery, and behavioral regression testing across model versions.
Consequence classing, approval design and audit schemas for environments where an error carries clinical or legal weight.
Per-step routing across frontier models from every lab behind one gateway, so a model change is configuration with an eval run, not a rewrite.
Built for healthcare and other regulated industries. Every system is designed against a written threat model, every control is enforced in code, in CI or in contract, and every control maps to the framework a client's auditor will ask about.
| §164.312(a)(1) | Access control |
|---|---|
| §164.312(b) | Audit controls |
| §164.312(c)(1) | Integrity |
| §164.312(d) | Person or entity authentication |
| §164.312(e)(1) | Transmission security |
The stack and the discipline, so an engineer can read this page and know what to expect.
We work with a few enterprise companies at a time. If you have a project and want to know whether an opening comes up, write to us. You will get a straight answer either way.