The Reviewer Doesn't Know What the Agent Knows: Closing the Information Asymmetry in HITL
There's a failure mode in HITL that doesn't show up in audit logs and doesn't trigger any alerts. It happens silently, on every approval, in every workflow, in every organization using AI agents with human oversight.
The reviewer doesn't know what the agent knows.
The agent has the full context: every retrieved document, every prior decision in the session, every tool call result, the chain of reasoning that led to the proposed action. The reviewer has whatever the review interface happens to show them — usually a summary, a one-line description, sometimes just the action and a confidence score.
The reviewer makes a decision based on incomplete information. The decision is logged. The audit trail records the human's verdict. But the human was making the decision without the context that would have allowed them to make it well.
This is the information asymmetry at the heart of HITL, and most HITL systems are designed to make it worse, not better.
The Asymmetry in Concrete Terms
Consider a typical approval request:
Action: Send email to customer
To: billing@acme-corp.com
Subject: Invoice #INV-2026-048291 overdue
Body: [50 words generated by the agent]
Confidence: 0.91
The reviewer sees this. They see a billing email, a one-line subject, 50 words of body, and a confidence score. They have 15 seconds. They click approve.
What the reviewer doesn't see:
- The agent's reasoning chain: which retrieved documents influenced the body content, what prior email exchanges were considered, what tone was selected based on the customer's history
- The model state: which model version generated this, what temperature was used, what tools the agent had access to
- The session history: this is the 14th email in a 6-day back-and-forth, the customer previously threatened to leave, the agent has modified the tone three times
- The policy context: this is a tier-2 escalation, the customer's account is in a "save the relationship" stage, the policy manifest says these escalations get a 6-hour SLA
- The alternative: there were three possible phrasings the agent considered, this is the most assertive one, the others were more conciliatory
The reviewer has none of this. The reviewer approves or rejects based on what the UI happens to surface. The decision is recorded as a human judgment. It was actually a guess.
The Three Layers of Information the Reviewer Needs
Layer 1: The Action and Its Direct Context
The reviewer's immediate question: what is the agent proposing to do, and what are the inputs?
- The action type (email, refund, code change, data modification)
- The parameters (who, what, how much, when)
- The relevant inputs the agent used (the source data, the retrieved document, the prior conversation)
- The agent's stated intent in one sentence (what it believed it was accomplishing)
This is what most HITL interfaces show. It's necessary but not sufficient.
Layer 2: The Reasoning and Its Justification
The reviewer's deeper question: why did the agent propose this specific action, and what were the alternatives?
- The chain of reasoning (which steps led to this conclusion)
- The policy rules that were evaluated (and which ones fired)
- The alternatives the agent considered (and why this one was chosen)
- The model's confidence and what it represents (statistical confidence, not factual certainty)
- The risk indicators (irreversibility, blast radius, financial impact, time sensitivity)
This is what most HITL interfaces hide. The reviewer's job is then to evaluate the action without being able to see why the agent did it. The reviewer can't disagree with the reasoning — they can only agree or reject the output.
Layer 3: The Operational Context
The reviewer's strategic question: what is the broader state of this workflow, and how does this action fit?
- The session history (what's happened before, what state the system is in)
- Concurrent actions (what other agents or humans are doing on related resources)
- The customer's full context (not just this interaction but the relationship history)
- The policy version (which manifest was active when the action was generated)
- The model's version and known limitations
This is what HITL interfaces almost never show. The reviewer sees a single action in isolation. The reviewer doesn't know the action is the 14th in a session, the customer previously threatened to leave, and the policy was just updated 6 hours ago.
Why HITL Interfaces Hide the Context
If the reviewer needs all three layers to make a good decision, why don't HITL interfaces show them?
Reason 1: Information Volume
The full context for a non-trivial action can be hundreds of thousands of tokens. A review interface that shows the full reasoning chain, all retrieved documents, the entire session history, and the policy manifest is a review interface nobody uses. The reviewer's attention is finite. The context is enormous.
Reason 2: Trust in the Agent
The team that built the agent trusts the agent. They've tested it, calibrated it, watched it work. They assume the reasoning is sound. Showing the reasoning to the reviewer is treated as redundant — "the agent is reliable, why would we burden the reviewer with the details?"
This is the automation bias at the design layer: the system designer assumes the agent's output is correct, so the human review becomes a procedural checkbox.
Reason 3: Reviewer Cognitive Load
Showing the full context to the reviewer makes the review harder. The reviewer has to read, understand, evaluate. The organization wants fast reviews — faster reviews mean more throughput, more autonomy, more "value" from the agent.
The temptation is to optimize for review speed at the cost of review quality. The result: an approval interface that is fast but produces guesses, not judgments.
Reason 4: Lack of Good Summary Mechanisms
Even when teams want to show the reasoning, they don't have good mechanisms to summarize it. The LLM can produce a chain of thought, but the chain is verbose, redundant, and not structured for review. There's no built-in way to extract "the three things the reviewer needs to know" from "the 50,000 tokens of reasoning that produced this action."
The Design Solution: Progressive Disclosure
The right HITL interface shows the reviewer the right information at the right level of detail — based on the risk of the action and the reviewer's expressed need to dig deeper.
Level 0: At a Glance (Always Visible)
A single line at the top of the review interface:
[Action] Refund €487 to customer #C-48291 (account age 3.2y, no prior refunds)
[Policy] Tier 2 escalation per § 4.2.1 — $400-500 refunds to tenure 3+ y
[Confidence] 0.87 (from review of 4 similar prior cases)
[Risk] Low — refund amount under policy threshold, customer history clean
The reviewer sees in five seconds: what the action is, why the policy says this needs review, what the model thinks, and what the system thinks of the risk. The reviewer can decide at this level alone if the case is routine. Approve, done.
Level 1: One Click Deeper (Default for Risk-Indicating Actions)
If the action has any of: low confidence, ambiguous policy match, unusual customer context, recent agent errors in this action type — the review interface expands to show:
- The top 3-5 factors that influenced the agent's decision
- The alternatives the agent considered (and why they were rejected)
- The 1-2 specific things the reviewer should verify
This is the structured "reviewer's guide" — what the agent thinks the reviewer should pay attention to. The reviewer doesn't read the full reasoning. They read the highlighted relevant pieces.
Level 2: Full Reasoning (On Demand)
A "Show full reasoning" button. The reviewer who wants to dig deeper can — they see the full chain, the full retrieval, the full session history. For 95% of reviews, this level is unnecessary. For the 5% of reviews where the action is non-trivial, ambiguous, or high-risk, this level is essential.
The progressive disclosure pattern means the routine review is fast (5 seconds for the at-a-glance summary). The non-routine review is thorough (60–120 seconds for the full reasoning). The system scales reviewer attention to the risk of the action.
The Three Information Fixes That Pay Off the Most
If progressive disclosure is the architectural pattern, the question is which information gaps are most damaging in practice. Three fixes deliver the highest ROI:
Fix 1: Always Show the Policy That Evaluated
Most HITL interfaces show the action but not the policy rule that fired. The reviewer doesn't know which policy rule determined that this action needs human review. The reviewer can't verify the rule was applied correctly.
Implementation: The review interface always shows the specific policy rule that evaluated the action and classified it as review-required. "Refunds of $400–$500 to tenure 3+ years require senior support review per § 4.2.1." The reviewer sees the rule. The reviewer can disagree with the rule application (and escalate), or confirm the rule was applied and approve.
Fix 2: Always Show What the Agent Considered and Rejected
The agent considered 3–4 phrasings for the email, 2–3 refund amounts, 2–3 possible actions. It chose one. The reviewer sees only the chosen one. The reviewer doesn't know what was rejected, and therefore doesn't know if the agent's choice was reasonable.
Implementation: The review interface always shows the top 2–3 alternatives the agent considered, with a one-line explanation of why each was rejected. The reviewer can override the agent's choice by selecting an alternative. The reviewer can see if the agent's reasoning was sound, not just its output.
Fix 3: Always Show the Counterfactual
The hardest piece of information to surface: what would have happened if the agent had not proposed this action? If the agent is being asked to send a save-the-relationship email, the counterfactual is "customer churns within 30 days." If the agent is being asked to refund, the counterfactual is "customer escalates to social media." The reviewer needs the counterfactual to evaluate the action's value.
Implementation: For high-impact actions, the system should display the predicted counterfactual based on the customer's history and the agent's analysis. "If this email is not sent within 24 hours, the customer is projected to churn (88% confidence based on 14 similar prior cases)." The reviewer can then evaluate: is the action worth the cost? Is the action the right way to address the predicted outcome?
The Information Architecture in Practice
A well-designed HITL review interface, applied to the email example:
[Header — Always Visible]
Action: Send email to customer #C-48291
Tier: 2 escalation (save-the-relationship workflow)
Agent confidence: 0.87
Risk: Low (action is reversible, customer history clean)
[Policy That Evaluated — Always Visible]
Rule: § 4.2.1 — Tier 2 escalations require senior support approval before send
This rule fires because: customer is in save-relationship stage, email is outbound to billing contact, prior email in session was flagged for tone
[Agent's Reasoning — Level 1]
The agent identified 3 primary considerations:
1. Customer previously threatened to leave (3 days ago, in chat transcript #CHT-48291)
2. Invoice #INV-2026-048291 is 7 days overdue (slightly beyond typical 5-day reminder cycle)
3. Customer's most recent support interaction rated the tone as "dismissive" in CSAT survey
[Alternatives Considered — Always Visible]
The agent considered 3 email phrasings:
- Selected: "We'd like to resolve this quickly" — direct, action-oriented
- Alternative A: "We understand your frustration" — empathetic, no specific ask
- Alternative B: "Please find attached invoice and payment options" — formal, transactional
The agent chose Selected because the customer previously responded better to action-oriented outreach.
[Counterfactual — High-Impact Actions Only]
If this email is not sent within 24 hours:
- Predicted outcome: customer churns within 30 days
- Confidence: 88% (based on 14 similar prior cases)
- Cost of inaction: $4,200 annual revenue loss
[Reviewer's Job]
The reviewer can:
- Approve the selected email
- Approve with modifications (open editor)
- Reject (require reason)
- Approve alternative A or B instead
- Escalate to retention specialist
The reviewer has the information to make a real decision in 60–90 seconds. The decision is informed. The decision is recorded. The HITL gate is no longer procedural.
Where Facio Fits
Facio's policy engine exposes the evaluation context to the review interface. The same action manifest that defines the policy rules also surfaces them at the approval point. The reviewer always sees which rule fired and why. The audit trail records the rule version, the agent's reasoning summary, and the reviewer's decision — all in one structured entry.
Placet.io's review interface is designed for progressive disclosure. The at-a-glance view is always visible. The Level 1 reasoning is one click. The full reasoning is on demand. The reviewer adapts their depth to the risk of the action — fast for routine, thorough for non-routine.
The information asymmetry is closed by design. The reviewer doesn't have to guess. The reviewer has the information to make a real decision — and the decision is the kind of decision a human should be making.
Key Takeaways
- The reviewer doesn't know what the agent knows — the agent has the full context, the reviewer has whatever the UI happens to surface
- Three layers of information the reviewer needs: action + direct context, reasoning + alternatives, operational context
- HITL interfaces hide the context for four reasons: information volume, trust in the agent, desire for fast reviews, lack of good summary mechanisms
- Progressive disclosure is the architectural pattern: at-a-glance summary for routine, structured reasoning for non-routine, full context on demand
- Three information fixes pay off most: show the policy rule that evaluated, show the alternatives considered, show the counterfactual
- The reviewer's job is to make a real decision, not to guess — give them the information to do the job
- Facio + Placet.io are designed for progressive disclosure — the at-a-glance summary, the structured reasoning, and the full context are all available at the appropriate depth
Sources: The information asymmetry analysis draws on decision science research (Klein, naturalistic decision making), human factors engineering (Hollnagel, cognitive systems engineering), and the documented patterns of automation bias in supervisory control. The progressive disclosure design pattern reflects established UX research on information density and decision quality in high-stakes review contexts.