ArmorHealth Observability

How member-care, claims, benefit, and risk agent plan captures, policy decisions, and tool results appear in ArmorIQ Observability.

ArmorHealth's health-domain agents are built on Google ADK and integrate through the ArmorIQADK bundle (see Getting Started and the Google ADK guide). That bundle wraps the same TypeScript/Python SDK session used by any other integration, so ArmorHealth activity follows the shared model in the observability overview: each session becomes one OpenTelemetry trace, and policy checks, model calls, and tool calls become spans.

What a trace looks like

Session (agent ID: "claims-accuracy-agent")
└── Trace (armoriq.agent.run)
    ├── armoriq.intent.plan
    ├── armoriq.policy.evaluate
    │   ├── armoriq.policy.decision: allow | hold | deny
    │   ├── armoriq.policy.enforcement_action
    │   └── armoriq.policy.rule_id, armoriq.policy.reason_code
    ├── gen_ai.chat (model call)
    ├── armoriq.approval.wait / armoriq.delegation.wait (when held)
    │   └── armoriq.delegation.id
    └── armoriq.tool (tool call)
        ├── armoriq.tool.name: search, read, submit_clean_claim, ...
        └── error.type (on failure)

The ADK bundle's callbacks map onto this shape: after_model_callback mints the token and records the model call, before_tool_callback produces the policy span, and after_tool_callback produces the tool span. ArmorIQ labels the telemetry with the product of the API key that the agent uses. See Framework support for the tested ADK versions and how the trace ends.

Holds and delegation

Tool calls a bundle template marks hold - propose_oon_referral, submit_clean_claim, schedule_appointment, generate_payment_determination, and similar review-gated actions across the Member Care, Claims Accuracy, and Risk Stratification templates - surface as a policy span with armoriq.policy.decision: hold and a delegation span with an armoriq.delegation.id. Follow it to the plan view to see the approval decision. ADK-based integrations get a longer client-side poll window than direct-client integrations - see Getting Started.

Freshness

Same as every SDK producer: the SDK sends spans in batches and sends the last ones when the session closes, and the dashboard polls every 30 seconds. See Freshness and retention.

Privacy boundary

This is the sharpest edge for ArmorHealth specifically: tool inputs and outputs for these agents can carry PHI - claims data, clinical notes, provider records, member identifiers. By default ArmorIQ stores metadata only, and it never stores tool inputs and outputs unless your organization chooses Enhanced or Debug capture and allows content. It always removes secrets and common identifiers such as SSNs and card numbers, but pattern-based redaction cannot catch everything. See What data is captured and Sensitive content. ArmorHealth's own phiAccess policy controls (minimum-necessary enforcement, SSN/financial redaction, maxRecordsPerQuery) govern what the agent can read and return - they do not retroactively redact what already went into an observability span.

Observability is not a HIPAA-compliance control. Treat the dashboard as containing PHI whenever your ArmorHealth agents' tool inputs or outputs do, and restrict access to organization members with a legitimate need, the same as you would the underlying EHR or claims system.

Enabling or disabling

Observability is on by default for any SDK-backed client with an API key. Pass observability: { enabled: false } when constructing the underlying TypeScript client, or SessionOptions(observability_enabled=False) in Python, to turn it off; disabling telemetry never changes a policy decision.

Next steps

On this page