ArmorHealth 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: one captured plan becomes one trace, and policy checks and tool calls become child spans.

What a trace looks like

Session (agentId: "claims-accuracy-agent")
└── Trace (iap.plan)
    ├── policy_call span
    │   ├── decision: allow | hold | deny
    │   ├── enforcementAction: allow_log | hold | block
    │   ├── matchedRuleId, reason
    │   └── delegationId (when held)
    └── span (tool call)
        ├── toolName: search, read, submit_clean_claim, propose_oon_referral, ...
        ├── toolInput / toolOutput
        └── errorMessage (on failure)

The ADK bundle's three lifecycle callbacks map onto this shape: after_model_callback starts the trace and mints the token, before_tool_callback produces the policy_call span, and after_tool_callback produces the tool-result span. The trace's product attribute defaults to armoriq-sdk, the same value any direct SDK or ADK integration uses unless the client overrides it.

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 denied span with a delegationId. 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 defaults as every SDK producer: traces flush roughly every 5 seconds, 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. The shared SDK recorders do not automatically redact this content; see 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.

Enabling or disabling

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

Next steps