The safe intake agent Typed evidence before the clinical workflow.

Most intake conversations in healthcare are a small handful of decisions wearing different costumes. Is this the person they say they are? Is there a covered benefit at the other end? What documents do we still need? And only after those: is anything in this conversation clinically urgent? Intake is the step before triage, and a safe intake agent is built from the same parts as a safe triage agent: typed evidence, a deterministic policy function, and a model that proposes rather than authorizes.

The risk surface looks a little different, though. Intake isn't about clinical red flags. It's about admitting people into a workflow that they aren't entitled to be in, losing PHI that should never have been collected in the first place, and trusting documents the system can't verify.

The intake agent does not decide who gets care. It assembles a packet, and the policy decides what that packet is allowed to do next.

The four layers, again

The architecture mirrors the triage paper directly. Each layer has its own authority, and only one of them can authorize a workflow action.

1. Observation. User chat, uploaded ID, insurance card OCR, captured form fields, eligibility-check responses, and demographic data, all transformed into typed candidate facts with explicit source and source-trust.
2. Inference. The model extracts fields, normalizes addresses, reconciles spellings, scores confidence per field. It does not admit.
3. Control. A deterministic policy function checks completeness, identity match, consent presence, eligibility status, and policy version, then maps the packet to one admitted action.
4. Evaluation. Offline eval against a locked intake set plus adversarial cases: forged IDs, prompt-injected upload text, mismatched eligibility responses, OCR noise.

The threat model is different upstream

Triage faces clinical urgency and overconfidence. Intake faces identity, fraud, and document-borne attacks. The categories don't fully transfer.

1. Identity fraud. Stolen credentials, impersonation, recycled patient packets across organizations.
2. Document forgery. Tampered IDs and insurance cards that pass casual OCR.
3. Eligibility spoofing. Mocked or stale eligibility-check responses, or responses that don't match the captured payer / member ID combination.
4. Prompt injection via uploads. OCR'd text from an uploaded document containing instructions to the model. Treated identically to user chat. That is, evidence, never policy.
5. PHI over-collection. The model asking for, or the form capturing, more PHI than the workflow actually needs. This is a privacy bug masquerading as friendliness.
6. Silent demographic drift. Free-text spelling of names and addresses accumulating across sessions and slowly corrupting downstream identity match.

Evidence, with source-trust that matters

The same EvidenceFact shape applies. What changes is the source taxonomy and the trust ladder.

EvidenceFact = {
  factType,          // identity_first_name | dob | member_id | ...
  value,
  confidence,
  source,            // user_chat | uploaded_id | uploaded_insurance_card
                     // | ocr | payer_eligibility_response | clinician_confirmed
  sourceTrust,       // low | medium | high
  verified,          // did an out-of-band check confirm this?
  timestamp,
  extractionModel,
  policyVersionSeen,
}

Two rules. A document the user uploaded is medium trust until verified out-of-band. A response from a real eligibility API call is high trust, but only against the exact member-ID it was queried with. A model summary of any of the above is not evidence. It's a rendering.

The intake action enum

Finite and explicit, like triage. Anything outside this list requires a person.

enum IntakeAction {
  REQUEST_MISSING_FIELD,
  REQUEST_DOCUMENT_UPLOAD,
  RUN_ELIGIBILITY_CHECK,
  HUMAN_VERIFY_IDENTITY,
  BLOCK_FRAUD_SUSPECT,
  ESCALATE_TO_COMPLIANCE,
  COMPLETE_PACKET_AND_HANDOFF,
}

The model can suggest, for example, that the eligibility response and the captured member-ID look consistent. The policy decides whether COMPLETE_PACKET_AND_HANDOFF is allowed on that basis, or whether the packet needs human verification first.

Abstention has a stricter meaning here

Triage allows the system to abstain when the clinical picture is uncertain. Intake takes a harder line: if identity is uncertain, the system must defer. There is no probabilistic shortcut to admitting a patient packet. The abstention threshold on identity-match is closer to absolute than to confident.

A confident wrong identity is more dangerous than an admitted uncertain one. Intake should abstain whenever the cheapest next check is a human glancing at the packet.

Provenance follows the patient into triage

Every fact that intake captures is handed to triage with its provenance and source-trust intact. The triage agent then inherits that scaffolding. Chest pain reported in chat carriessource = user_chat and triggers the appropriate red-flag and reviewer rules. A confirmed identity carries verified = true, which lets the policy authorize specific downstream actions that would otherwise require human review.

This is what makes intake and triage two halves of one workflow rather than two systems that happen to be wired together. The same EvidenceFact format flows through both. The same policy bundle conventions apply. The same dashboards (ops, safety, eval) hold both.

What the dashboards should show

Intake adds a few signals to the safety dashboard the triage paper proposed, all useful in their own right:

• Identity-match abstention rate. How often the system refuses to admit a packet on identity grounds. A healthy rate is non-zero.
• Document-trust distribution. What share of packets relied on uploaded documents vs. payer-verified evidence. Drift here changes downstream risk.
• Eligibility-mismatch rate. Packets where the eligibility response didn't match the captured member-ID. Mostly bookkeeping, occasionally fraud.
• PHI-collection minimum-necessary check. Per packet, did we collect any field we didn't need under the current policy? Visible to compliance.
• Upload-borne prompt-injection rate. How often OCR'd text contained instruction-like content. Treated as evidence, surfaced for review.

Release gates carry over

The release-gate logic from the triage paper applies almost without modification. A new intake model or policy version doesn't ship without locked-eval pass, adversarial-eval pass, identity-match precision and recall above threshold, eligibility-mismatch behavior within bounds, no PHI over-collection regressions, and compliance sign-off on policy changes that materially shift the data we ask for.

The principle (again)

A safe intake agent doesn't pretend to know the patient better than the systems around it. It captures typed evidence, with provenance and source-trust, and hands a packet to a deterministic policy that decides what is admitted. The model proposes. The policy authorizes. The team can see why.

The same architecture, one step upstream of triage. Same invariants, slightly different threat model, slightly different action enum. Both halves run on the same scaffolding, and theEvidenceFact rows tell you, after the fact, exactly what the system thought it knew and where it got it from.