Compliance Agent

Designing an AI agent for disaster response compliance, from agentic AI frameworks to a working prototype.

How do you want to read this?

What I learned and what I'll bring to my team

The HCAI Institute's UX Design for Agentic AI course was an 8-module deep dive into how to design autonomous systems that people actually trust. Before this, I would have assumed that architecture and development have most of the work to do in "building agents": that the design contribution was mostly at the interface layer. The course taught me that the space is rich for human-centered computing interventions at every level, from how the agent relates to its users to how it communicates uncertainty to how trust develops over time.

Agents have relationships, not just interfaces

The most fundamental reframe: you're not designing a tool's interface. You're designing a working relationship. The course teaches a spectrum from Tool (user controls everything) through Assistant, Collaborator, Delegator, up to Autonomous Agent. Most AI products default to "assistant," but the level you design for dictates everything downstream: what the UI shows, when the agent asks vs. acts, how much reasoning it exposes, and how control shifts over time. And a single agent often operates at multiple levels simultaneously. If you design the whole product as one level, you'll over-engineer some parts and under-engineer others.

The Relationship Design Framework - five levels of human-agent collaborationFramework

The framework classifies relationships based on who holds decision authority:

Tool - User has full control, agent has no autonomy. User is the operator.
Assistant - Agent suggests, user decides. User is the decision-maker.
Collaborator - Agent and user work together, taking turns. User is a peer.
Delegator - User sets goals and constraints, agent executes independently. User is a manager.
Autonomous Agent - Agent operates with minimal oversight. User is a sponsor.

The key design implication: the relationship level determines the UI's primary job. A Tool-level interface needs clear commands and outputs. An Assistant needs surfaced recommendations. A Collaborator needs turn-taking cues. A Delegator needs oversight dashboards and exception routing. Designing the wrong UI for the relationship level creates what the course calls a "mismatch": the most common failure pattern in agentic products.

Trust develops in stages: design for the journey, not the destination

Trust isn't a binary switch. It develops in four stages (Observer, Advisor, Partner, Steward), and the UI needs to be different at each one. Early on, users want to see everything the agent is thinking. Later, they want summaries with reasoning available on demand. Designing only for the "trust fully" end state means your agent will never get adopted, because no one starts there.

The course surfaced something I think will be one of the most important design challenges as agentic products mature: the Review Paradox. The more work an agent takes on, the more of its outputs a human needs to review. Yet humans cannot meaningfully, carefully, and critically review the volume of outputs that capable agents produce. In the Compliance Agent's case, a single disaster event generates an assessment covering 50 to 200 properties, each with a risk score, compliance determination, and recommended action. Exhaustively verifying that output means essentially re-doing the work manually. Agentic design is still new, and we're already seeing rubber-stamping behavior: think about how carefully you reviewed the last plan you asked an AI coding tool to generate. Designing for this means building confidence indicators and attention-directing mechanisms that keep human judgment engaged where it matters most, not everywhere equally.

Trust Journey Map - four stages and the UI patterns each demandsFramework

The Trust Architecture models four stages of trust development:

Observer - User watches and verifies everything. UI shows full reasoning by default. Panels open, confidence scores prominent, every data source cited. The agent is proving itself.
Advisor - User trusts analysis but makes all decisions. Reasoning is available but not front-and-center. Recommendations are surfaced; the user evaluates.
Partner - Shared decision-making. Agent handles routine cases autonomously. Routine approvals can be batched. Summary views replace line-by-line review.
Steward - Agent operates independently within boundaries. Periodic governance reviews. The interface shifts to monitoring dashboards and trend analysis.

The Review Paradox requires active design mitigation: (1) confidence indicators that visually weight uncertain items, (2) periodic "trust calibration" reviews surfacing the agent's actual accuracy rate, and (3) always-accessible reasoning chains for spot-checking even routine approvals.

Three layers of trust apply to each delegation task: competency trust (can the agent do this?), boundary trust (will it stay in its lane?), and communication trust (will it explain itself when I need it to?). Failures in each layer look different and require different recovery patterns.

Agents need behavioral specs, not just technical specs

How the agent decides, when it asks vs. acts, what it says when uncertain. These are design choices that need to be articulated before anyone writes code. The course calls this a behavioral specification: the agent's identity, boundaries, disambiguation rules, failure communication patterns, and voice.

One example of why this matters: the course introduces a Disambiguation Spectrum: when an agent encounters ambiguity, it can always ask, ask with a default, act and explain, or act silently. For the Compliance Agent, a property straddling the boundary of a declared disaster area is genuinely ambiguous. Should the agent flag it and wait? Include it with a confidence note? Silently exclude it? That's not a technical decision. It's a design decision based on risk, user context, and what the analyst needs to trust the output. Without a behavioral spec, those calls get made ad hoc by whoever's writing the code.

Behavioral specification elements - what to define before buildingFramework

A complete behavioral specification covers:

Identity - What the agent is (specialist, not general assistant). How it's named and represented visually.
Boundaries - What it can do independently vs. what requires human approval. Made visible through an autonomy settings interface.
Disambiguation rules - For each type of ambiguity, where on the spectrum does it fall? Always ask → Ask with default → Act and explain → Act silently.
Failure communication - Direct, not euphemistic. What happened, why, severity, and recovery options.
Voice and tone - Data-first, recommendation-oriented, calibrated to confidence level. The course argues that domain agents should primarily communicate through structured output (cards, tables, annotations). Chat can play a role, but as a contextual query tool at specific decision points, not as the primary interface.

Anti-patterns to specify explicitly: open-ended chat as the primary interface for domain work, anthropomorphized language, color-only status indicators, and modal dialogs for information delivery.

The handoff is the hardest design problem

When work passes between human and agent (escalation, delegation, mid-task changes), that's where failures happen. The course models this as a Delegation Lifecycle with four critical moments: how intent is communicated, how execution becomes visible, how scope changes mid-stream, and how failures are reported. Three handoff patterns (escalation, delegation, transition) each have different requirements for context transfer and control. Designing these transitions well matters more than designing any individual screen.

Testing the behavioral spec before building anything visual pays dividends. I used Claude Projects to roleplay as the Compliance Agent while I played the analyst, walking through delegation scenarios to pressure-test the disambiguation rules and failure patterns.
That lightweight testing caught surprising experiential gaps I thought were well-specified by the behavioral specification, letting me improve the spec without making it too long and start prototyping on a stable foundation.

Prototyping the agentic experience

For the capstone project, I chose to focus on a real problem domain from the commercial real estate space: one that causes real pain points, is ripe for automation, and is robust enough in scope to deliver value to the end user without challenging their job security. Disaster response compliance for multifamily loan portfolios.

When FEMA issues a disaster declaration, loan compliance analysts must rapidly assess which properties across a portfolio of thousands are potentially impacted: cross-referencing FEMA geographic data against loan records, verifying insurance, coordinating with dozens of servicers, tracking remediation, updating risk ratings. Today this takes weeks of manual work. The Compliance Agent orchestrates this entire lifecycle as a SENSE → DECIDE → ACT → LEARN loop with human oversight at critical decision points.

I created seven integral design artifacts: relationship classification, trust architecture, behavioral specification, delegation arc (scenarios and journey map), design brief, and mock data from publicly available sources on the internet. Then I built a functional prototype to test those ideas in context.

FEMA Alerts: proving the agent is capable before asking for trust

The “FEMA Events” dashboard operates at the Tool level of the relationship framework: the agent has already done the work (monitoring FEMA feeds, matching declared geographies against the portfolio) and the analyst's job is to acknowledge and triage. But "Tool level" doesn't mean "simple to design." The hardest challenge here was providing just enough context for the analyst to feel confident the agent is doing its job well, without burying them in data they don't need to act on yet.

Each declaration row surfaces the proof of competence: severity classification, how many properties matched, total financial exposure, and the current processing phase. If the agent matched 14 properties across 3 counties with $100M in exposure, the analyst can trust the match at a glance. If something looks off (zero matches in a region where they know there are loans), the signal is immediately visible.

The other challenge: making the agent's state legible. At any moment, a declaration might be in one of several states: agent still working, ready for review, or blocked on a human decision. The phase column and status pills distinguish these. Getting it wrong means either unnecessary interruptions (surfacing events before the agent is ready) or dangerous gaps (the agent waiting for input the analyst doesn't realize it needs).

FEMA Events table showing 7 disaster declarations with severity, timeline phase, properties matched, and exposure — FEMA Events - severity-ranked declarations with agent state and portfolio exposure

EM-3621 Tornado Outbreak showing scope confirmation with 4 properties on a map near Norman, Oklahoma — EM-3621 - scope confirmation with Include/Exclude decisions per property. This is the MVP state of the agent: enough to prove the tool is capable and can be trusted before building out more of its capabilities.

Event response: the agent's workflow made visible

The “Event Details” page is one of the most important screens in the experience. It maps the SENSE → DECIDE → ACT → LEARN workflow into a visual progress timeline, with each milestone showing status and timestamp. Below the timeline, the current phase expands to show the agent's work: the Monitoring & Remediation phase, with a status summary and action-required cards for individual properties.

This is the execute-with-visibility pattern from the delegation framework: the agent proceeds autonomously within approved parameters while giving the analyst a real-time view of progress and exceptions. The Delegation Lifecycle's four critical moments are all visible: intent communication (event details confirm scope), execution awareness (the progress timeline), mid-task changes (the “Intervene” button in the top right), and human-in-the-loop checkpoints (agent is paused and awaiting human decisioning).

The Event Response timeline animates the SENSE → DECIDE → ACT → LEARN flow. Each milestone surfaces its status and timestamp as the agent works.

DR-4887 Monitoring and Remediation phase showing 3 overdue properties requiring action, with action cards for Harvest Creek Village, Island View Residences, and Galveston Shores — DR-4887 in the Monitoring & Remediation phase - the agent flags 3 overdue properties with direct, non-euphemistic explanations and recommended actions, giving the analyst clarity about what options are possible at any step in the timeline.

Intervene modal showing completed steps, in-progress work awaiting approval, and action options including Modify Scope, Re-run Assessment, Edit Action Plan, and Dismiss Event — There is financial and reputational risk at stake so the user should be able to pause, stop, re-start, and edit future steps with clarity into what cannot be changed (completed work) and what can be changed (work that is in progress or not started).

Impact assessment: giving analysts the context for confident decisions

This is the DECIDE phase, the primary trust checkpoint, and the screen where the analyst has to answer three questions: How did we get here? What am I approving? What happens next? If the UI fails on any of those, the analyst either rubber-stamps (dangerous) or blocks everything for manual review (defeats the purpose of the agent). Designing this screen was about providing enough flexible surfaces that the analyst can build confidence at their own pace.

The properties table is a supplementary surface, risk-ranked, with servicer, risk score, execution status, insurance compliance, and loan balance. It's a familiar screen that users can fall back to if the timeline is insufficient for confident decision making. Surrounding it are layers of context that the analyst can pull in or collapse depending on what they need. The timeline on the right panel shows servicer engagement details that occur later in the process. Property detail data (loan details, inspection history, condition ratings) is accessible inline, so the analyst isn't navigating away to cross-reference something they know by heart. And progressive disclosure lets each row expand to show the full reasoning chain (confidence scores, compliance logic applied, data quality flags) without overwhelming the default view.

One departure from the original design brief: I added a chat interface with context-aware prompt buttons. The course argues against open-ended chat for domain agents, and I agree, but there are moments where the analyst needs to ask a specific, contextual question ("Why was this property flagged when it has active insurance?"). Pre-populated prompt buttons grounded in the current assessment give the analyst a query tool without the ambiguity of an open text field. The real usability test for this screen is deceptively simple: ask the participant if they understand how we got here, what they're approving, and what happens next. If they can answer all three confidently, the surfaces are working.

DR-4887 properties table showing 11 properties with servicer, risk rating, status, insurance compliance, and UPB columns, with a drawer open showing Greenway Commons detail including risk rating, insurance, Form 1140 status, and communications — DR-4887 properties tab - risk-ranked table with drawer overlay for progressive detail. The analyst sees familiar property data (UPB, rating, insurance) alongside agent-specific context (execution status, Form 1140 tracking) without leaving the workspace.

DR-4887 event response with chat panel showing agent summary of all decisions and actions taken, with context-aware prompt buttons: How did we get here, Contact failures, Overdue forms, Stalled properties — Chat as a contextual tool, not the primary interface - the agent summarizes decisions and actions when asked, and prompt buttons ('How did we get here?', 'Contact failures', 'Stalled properties') scope the conversation to what's useful at this decision point.

How course frameworks map to specific design decisions in the prototypeDecisions

Structured output as the primary surface, chat as a contextual tool (Behavioral Spec) - The agent's core communication is data-rich: status cards, risk tables, inline annotations. But at the DECIDE checkpoint, context-aware prompt buttons give the analyst a way to ask targeted questions without an open-ended conversation. Chat supplements structure; it doesn't replace it.
Three-panel layout with drawer overlay (IA / Progressive Disclosure) - Enterprise lending tools show many entity types simultaneously. The drawer overlays the workspace rather than splitting it, so primary content stays stable and context feels temporary.
Agent as @mentionable participant (Behavioral Spec) - @Compliance Agent appears in timelines alongside human users. Same data structure, same rendering rules.
Progressive autonomy via settings page (Trust Architecture) - Instead of a binary supervised/autonomous switch, each analyst adjusts a dial: "auto-approve routine notifications," "flag properties above $X." The Collaborator-to-Delegator transition is gradual and user-controlled.
Plan-then-execute handoff (Delegation Lifecycle) - In regulated work, the cost of pausing to review is minimal vs. the cost of executing wrong. The agent presents its full assessment before any irreversible action.
Confidence indicators directing attention (Review Paradox) - Low-confidence assessments get flagged. The agent actively draws the analyst's eye to where human judgment matters most.

Autonomy Settings page showing current trust stage (Partner), current capabilities and active boundaries, permanent boundaries that cannot be changed, and all four trust stages from Observer to Steward — Autonomy Settings - the trust architecture made tangible. The analyst sees where the agent is on the Observer → Steward journey, what it can currently do independently, and which boundaries are permanent (risk rating changes, compliance waivers, regulatory deadlines).

Key Learnings page showing 6 cross-event insights categorized by Servicer, Insurance, Risk-Model, Process, and Geographic, with linked events and discovery dates — Key Learnings - the LEARN phase. The agent surfaces patterns across events: stale servicer contacts, insurance gaps, risk model accuracy, process bottlenecks. Each insight links to the events that generated it and suggests a next action.

Takeaways and what's next

Research, plan, and test lightweight before you build

I already practiced this sequence: research the problem, plan the approach, test cheaply before committing to a full build. The course affirmed it and gave it sharper structure for agentic work specifically. Because agentic coding makes the prototype cheap I spent more time getting the research right, defining the problem to be solved, and deciding how to solve it. I used the coded prototype to build confidently to prove the agentic experience works for the user. Lightweight testing with robots and people helped me dial in the details throughout the whole process.

Design for the transitions, and know where the MVP starts

The Compliance Agent operates as a Tool during monitoring, a Collaborator during assessment, a Delegator during execution, and approaches Steward during learning. A single-mode UI would have created friction at every phase boundary. The most important screens in the prototype aren't the ones within a mode. They're the ones where the mode shifts: the alert that triggers triage, the assessment that requires approval, the approved plan that launches autonomous execution.

This also clarified where an MVP would start. You don't need to build the full multi-level experience on day one. The SENSE phase (Tool-level monitoring that surfaces alerts) is a self-contained, lower-risk starting point that delivers immediate value without requiring the organization to trust the agent with decisions yet. Build trust at the Tool level first, then expand. The relationship framework doubles as a roadmap for incremental delivery.

Chat is about affordances and behavior patterns, not a blanket rule

The course argues against chat as the primary interface for domain agents, and I think the reasoning is sound, but the real issue is that chat lacks affordances and controls. An open text field doesn't tell the user what's possible or in scope, and it invites open-ended conversation that may not suit the task. I ended up adding chat at the DECIDE checkpoint, but with context-aware prompt buttons that act as affordances: they tell the analyst what questions are useful here, scope the conversation to the current context, and make the agent's capabilities legible. The takeaway isn't "use chat" or "don't": it's to think carefully about what behavior pattern a surface invites and whether that's the right one for the task.

A good design brief and realistic data make prototyping dramatically faster

The design brief specified the visual language, interaction principles, and screen-by-screen behavior in enough detail that prototyping with Claude Code was largely execution rather than exploration. The mock data (sampled and adapted from publicly available sources like FEMA's OpenFEMA API and FHFA's natural hazard dashboard) made every screen grounded in reality rather than lorem ipsum. Analysts need realistic data to prove out the usability of the agentic experience.

What's next

Presenting this work internally: sharing the frameworks and the prototype with my team and taking this concept, or something evolved from it, to the business. And bringing the course deliverable templates back to my team: relationship classification, trust architecture, behavioral spec, delegation arc, and design brief as reusable frameworks for any agentic design work.

How the project unfolded over 8 weeks

Weeks 1–2

Relationship classification & delegation model. Mapped the compliance workflow against the Relationship Design Framework. Identified multi-level operation.

Week 3

Trust architecture & journey map. Diagnosed trust layers for each delegation task. Designed three Review Paradox mitigations. Produced an interactive Trust Journey Map (Observer → Steward).

Week 4

Behavioral specification. Defined identity, boundaries, disambiguation rules, failure patterns, and voice. Iterated through two versions: v2 added explicit rules for ambiguous scenarios.

Week 5

Delegation arc & data landscape. Mapped full workflow from FEMA declaration to post-event reporting. Researched synthetic and real data systems (publicly available data about commercial lending, open-source weather APIs, OpenFEMA API, Anthropic API).

Week 6

Design brief. Full prototype specification: visual language, WCAG-verified color palette, typography scale, navigation architecture, seven key screens, agent UX patterns, and interaction principles.

Weeks 7–8

Prototype. Built with Next.js, Tailwind, shadcn/ui, and Claude Code. Realistic mock data. Multiple iteration rounds on dashboard, alerts, event response, and impact assessment. Deployed to Vercel.

Course: UX Design for Agentic AI, HCAI Institute (Maven platform), 8 modules, Feb–Mar 2026

Domain research: Publicly available commercial lending data, open-source weather APIs, OpenFEMA API, Anthropic API

Built with: Next.js, Tailwind CSS, shadcn/ui, Recharts, Claude Code (Anthropic)

Let's connect.

Open to conversations, collaborations, and meetups.

Book a call