Reference Architecture for Agentic Benefits-Decisioning Systems

A canonical architecture for state and federal benefits-decisioning systems that operate at L2 (assisted) and L3 (agentic) — the layers, the seams between them, and what each is contractually accountable for.

This is the architecture we deploy, in shape if not in branding, on every engagement. The point of publishing it is to make the seams legible. Vendors and integrators love to obscure seams. We don't.

A correct architecture for an agentic benefits system has six layers. They map to six contracts. Each contract has an owner. Each contract is testable.

Layer 1 — System of record (SoR)

The authoritative store of fact-of-claim and case state. Often a legacy COBOL/RPG/mainframe environment, increasingly a modern OLTP system.

Contract. Returns canonical, point-in-time-correct facts for any claim ID and timestamp. Never reasons. Never decides.

Owner. Agency or core-system integrator. Vardr does not propose to replace this layer in Phase 1; we wrap it.

Layer 2 — Policy and rules layer

The codified expression of statute, regulation, and program policy. Should be human-readable, version-controlled, and unit-tested.

Contract. Given a fact-of-claim and a policy version, returns the deterministic eligibility determination. No ML, no probabilities — pure rules.

Owner. Joint between the agency's program-policy office and engineering. Vardr's role is to help extract policy from legacy code into a maintained ruleset.

Layer 3 — Feature and signal layer

Derived signals over claimant, provider, payment, and graph data. Includes both deterministic features (last-payment-date) and learned signals (graph-neural-network embeddings).

Contract. Returns versioned features for any subject at any timestamp, reproducible from versioned data and code.

Owner. Vardr in delivery; agency post-handoff. We will not deliver a feature store the agency cannot operate.

Layer 4 — Model and agent layer

Supervised classifiers, sequence models, GNNs, and bounded agents that consume features and produce decisions, recommendations, or actions.

Contract. Every output is traceable to (a) input features at version, (b) model artifact at version, (c) prompt and tool calls at version (for agents), and (d) policy constraints active at the time of decision.

Owner. Vardr in delivery; agency post-handoff. Model artifacts are delivered to the agency, not held in a vendor's account.

Layer 5 — Decisioning and review layer

The interface the caseworker uses. Surfaces recommendations with citations. Provides escalation, override, and appeal pathways.

Contract. Renders the decision under review with full provenance — facts, policy, features, model output, agent trace. Override and reason-code are persisted as first-class events.

Owner. Joint between Vardr UX and agency program staff. Section 508 conformance is a Phase-1 acceptance criterion.

Layer 6 — Observation and accountability layer

The cross-cutting layer that observes every event in every other layer: data quality, feature drift, model performance, agent action rates, override patterns, appeal outcomes.

Contract. Produces the artifacts the OIG and program-integrity offices need to investigate any decision or class of decisions, including full replayability.

Owner. Vardr in delivery; agency post-handoff. The agency owns this layer — it is not a vendor dashboard you log into.

The non-negotiables

Three properties cut across all six layers and are non-negotiable on Vardr engagements:

Reproducibility. Any decision must be reproducible from versioned data, policy, features, and models. "We can't reproduce that anymore" is a P0 incident.
Replayability. Any agent action must be replayable through the same tool calls, with deterministic outputs given fixed seeds and same-version dependencies.
Policy boundedness. No agent action escapes the policy layer. Constraints are enforced at the action boundary, not at the prompt.

How Vardr engagements use this architecture

Phase 01 (Mapping) produces a populated version of this diagram for your program — what exists, what's missing, what's broken at the seams. Phase 02 (Parity) fills the seams. Phase 03 (Promotion) moves traffic through them. Phase 04 (Operating) makes them auditable.

If you have a current architecture diagram and would like our markup of where the seams are leaking, send it.