AI Agents for Healthcare Engineering Teams

A health-tech engineering team ships a routine feature, an insurance eligibility check on the patient portal, and now every pull request that touches it needs a HIPAA-grade review before it can merge. AI agents for healthcare exist precisely because this review cannot be skipped, delegated to "we'll catch it in QA," or handled by a generalist chatbot that has never seen a Business Associate Agreement. The patient's date of birth, social security number, and insurance ID move through three services and a third-party clearinghouse before the eligibility result comes back. If any one of those hops logs the payload in plaintext, caches it without encryption, or skips an audit trail entry, the team has a reportable incident, not a bug. Layer on a legacy HL7 v2 feed from Epic that nobody on the current team wrote, a FHIR R4 API integration with three different hospital systems each with slightly different implementation quirks, and documentation that is twelve months stale, and the real cost shows up as six-week onboarding ramps for every new engineer who has to reverse-engineer the integration before they can safely touch it.

Why ai agents for healthcare need more than ChatGPT and Cursor

Paste a diff into ChatGPT or Claude.ai and ask "is this HIPAA compliant" and you get a plausible-sounding answer shaped entirely by the fifty lines you pasted. It has no visibility into whether that eligibility response gets cached downstream, whether the logging middleware upstream strips PHI before it hits Datadog, or whether the encryption-at-rest policy that covers the primary database also covers the Redis cache the new feature just started writing to. A generalist chatbot answers the question you asked. It does not know to ask whether you asked the right question, and in healthcare software the wrong question is how a SOC 2 auditor ends up writing a finding six months later. For a codebase where PHI can flow through a dozen services, a single-diff view is close to useless as a compliance signal.

Cursor and GitHub Copilot solve a completely different problem well: fast, context-aware autocomplete inside the editor. Ask Copilot to help you write the eligibility check function and it will happily generate a clean implementation. It will not flag that the function logs the full request payload for debugging, because logging a payload is syntactically valid code, not a compliance violation Copilot is scoped to catch. It will not know that your BAA with the clearinghouse requires the cached response to expire in under 24 hours, because that number lives in a contract, not in the codebase. Autocomplete tools are excellent at the sentence level and structurally blind at the policy level, and PHI handling is a policy-level problem wearing code-level clothing.

Warden reviews PHI handling on every PR, Proof and Atlas cover the rest

Warden is the security engineer on the tonone team, and for a healthcare codebase its job is narrower and more constant than a one-time audit: catch PHI exposure, weak encryption, and missing audit trails on every pull request before merge, not once a quarter when a compliance deadline forces a scramble. Warden reads the actual diff and the surrounding system, not just the fifty changed lines, so it can trace whether a new field flows into a log line, an unencrypted cache, or a third-party call that was never covered by the original BAA review.

warden-audit runs the full pass: secrets scanning, dependency CVEs, IAM misconfigurations, auth gaps, injection risk, and public storage exposure, all of which matter more in a HIPAA environment than in a typical SaaS product because the blast radius of a single exposed field is a patient's medical record rather than a marketing email address. Run it against the eligibility check PR and it flags exactly the class of issue a generalist tool cannot see: a debug log statement three files upstream that includes the full request body, a Redis TTL of 7 days on a cache that the BAA requires to expire in 24 hours, and an IAM role for the clearinghouse integration that has broader S3 read access than the integration actually needs.

Tonone's Warden runs a full security audit, secrets, dependencies, IAM, auth, injection, and public storage exposure, on the diff and the surrounding system, not just the changed lines.

Before the integration ships, warden-threat builds the threat model the compliance team will ask for anyway: what assets are exposed (patient demographics, insurance IDs, eligibility results), what the ranked threats are (payload logging, cache over-retention, over-scoped IAM), what mitigations close each one, and which residual risks are being accepted and by whom. warden-harden then turns the findings into an implementable spec, security headers, input validation on every field that reaches the clearinghouse call, rate limiting on the eligibility endpoint so it cannot be used to enumerate patient records, and a secrets management pattern for the clearinghouse API credentials that does not involve an environment variable checked into a Docker image.

Atlas is the knowledge engineer, and it solves the second half of the pain: the HL7 feed from Epic that only one engineer, who left eighteen months ago, ever fully understood. atlas-map reads the actual integration code, not a wiki page nobody updated, and produces a current C4-level map of how ADT messages flow from Epic through the parser, into the patient record service, and out to the three hospital systems consuming the FHIR API. atlas-onboard turns that map into ramp documentation a new engineer can use on day one instead of week six, covering local setup, where the HL7 parsing logic actually lives, and which parts of the integration are safe to touch versus which parts have load-bearing quirks that exist because one hospital system's Epic instance sends a nonstandard segment.

Tonone's Atlas keeps architecture and integration documentation accurate by generating it from the current codebase, not from a wiki page that drifted out of date the week after it was written.

Proof rounds out the picture where testing meets patient data. proof-api builds contract tests against the clearinghouse sandbox so a schema change on their end (a renamed field, a new required parameter) fails a test suite instead of failing silently in production against real patient eligibility checks. proof-e2e covers the full patient portal journey, login, view eligibility, view a scheduled appointment, so a regression in the FHIR integration gets caught before a QA cycle, not during one, and well before the next SOC 2 evidence collection window.

Worked example: the eligibility check PR at Meridian Health

Meridian Health is a 14-engineer Series B health-tech company running a patient portal and provider scheduling product for three hospital systems, syncing roughly 40,000 patient records a night over an HL7 v2 ADT feed from Epic, with a FHIR R4 API layered on top for the newer integrations. The team just built an insurance eligibility check: patient enters or confirms insurance details, the backend calls a third-party clearinghouse, caches the result for the visit session, and displays coverage status. It is a 380-line PR touching four services. Here is roughly what Warden's review of that PR surfaces before it merges.

Warden Audit, Eligibility Check PR (#1284)
Scope: patient-portal/eligibility, clearinghouse-client, shared/cache

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[HIGH]   clearinghouse-client/log.ts:41
         Full clearinghouse request body logged at debug level,
         includes DOB, SSN last-4, insurance member ID.
         Fix: redact PHI fields before log write, add field-level
         allowlist for logging middleware.

[HIGH]   shared/cache/eligibilityCache.ts:18
         Redis TTL set to 7 days. BAA with clearinghouse requires
         cached PHI to expire within 24 hours of the visit.
         Fix: set TTL to 24h, add session-scoped cache key so
         stale entries cannot leak across patients.

[MEDIUM] clearinghouse-client/iam-role.json
         Integration's IAM role has s3:GetObject on the full
         claims-archive bucket. Integration only reads/writes
         one prefix.
         Fix: scope policy to claims-archive/eligibility/* only.

[MEDIUM] patient-portal/eligibility/route.ts:76
         No rate limit on eligibility endpoint. Could be used to
         enumerate valid member IDs against the clearinghouse.
         Fix: add per-session rate limit, route via warden-harden
         spec section 3.

[LOW]    clearinghouse-client/audit.ts
         Audit log entry captures request timestamp and user id
         but not which fields were disclosed. Compliance needs
         field-level disclosure tracking for this integration.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Recommendation: block merge on the two HIGH findings, ship the
MEDIUM findings in the same PR since the diff already touches
those files. Route to warden-harden for the rate limit spec and
to atlas-changelog once merged so the audit trail reflects why
the TTL changed.

Two high-severity findings block the merge, not because a generic linter fired, but because Warden traced actual PHI flow from the request body through a debug log statement and into a cache with the wrong retention window. Both issues would have shipped clean through Copilot's autocomplete and clean through a ChatGPT review of the diff alone, since neither tool has visibility into the BAA's 24-hour retention clause or the log pipeline three files away. Once the fixes land, atlas-changelog records the change with the reasoning (BAA-mandated retention, not an arbitrary config tweak) so the next compliance audit has a written trail instead of a git blame archaeology exercise. proof-api adds a contract test asserting the clearinghouse response schema, so if the vendor renames a field next quarter, a test fails in CI instead of a patient seeing a blank eligibility screen.

Tonone's warden-threat skill produces a threat model, ranked threats, mitigations, and accepted risks, before a PHI-touching integration goes live, not after an auditor asks for one.

Comparison for healthcare engineering teams

Install and try

Tonone is free and MIT-licensed. Install it once and Warden, Atlas, Proof, and the rest of the 100-agent team are available in your Claude Code session. You pay only for the Claude Code token usage during the work itself, there is no separate compliance tooling license to negotiate.