Status: Accepted
Date: 2026-07-15
Author: parakram shekhawat
The three AI agents (ClaimValidator, DenialAnalyzer, AppealDrafter) each produce outputs that need to be persisted, audited, and displayed in the UI. A decision is needed on where to store these outputs.
Store AI outputs directly on the Claim model as three dedicated fields:
ai_validation_result — JSONField(null=True, blank=True): structured output from ClaimValidatorai_denial_analysis — JSONField(null=True, blank=True): structured output from DenialAnalyzerai_appeal_draft — TextField(blank=True): the full appeal letter text from AppealDrafterAgents write to these fields via the update_claim_ai_result tool (a WRITE-safety tool with memory_policy="exclude" so the write is not stored in the agent’s memory session).
The null state serves as the "agent still running" signal: claim.ai_validation_result is None means the agent hasn’t finished yet.
Separate AuditLog model: Normalized, supports history of multiple runs. Adds a join for every page render. Overkill for three fields that are updated once per lifecycle phase.
File storage: Agent outputs stored as files in object storage. Adds read complexity (fetch file per render), no advantage for text/JSON outputs of this size.
Agent memory / session: Zango stores agent run history in sessions. This is for agent-internal reasoning context, not for surfacing structured outputs in app UI — wrong layer.