# Natural-language guidance can become a hidden authority layer for a customer agent

Entry: `bt-008`  
Verdict: `REWORK`  
Observation date: `2026-06-17`  
Artifact type: `agent_policy_surface`

## Hard Summary

| Check | Result |
| --- | --- |
| Vulnerability class | instruction_surface_risk, false_autonomy, policy_precedence_ambiguity, customer_facing_learning_loop |
| Failure point | The signal breaks at the boundary where plain-language guidance starts behaving like an execution or policy authority layer without a fully visible precedence, approval, and rollback model. |
| Claimed or implied autonomy | The system presents a high-performing customer agent that can follow policies and improve over time through configurable guidance. |
| Observed autonomy | The public surface shows a behavior-shaping instruction layer, but does not fully expose how guidance changes are prioritized, reviewed, audited, or constrained against unsafe broadening. |

## Source

- https://www.intercom.com/help/en/articles/10210126-provide-fin-ai-agent-with-specific-guidance
- https://fin.ai/

## Failure Map

- `instruction_surface_risk`: The public guidance layer is explicitly behavior-changing: natural-language instructions can modify how the agent speaks, follows policies, and handles conversations. That means the text surface is no longer merely descriptive; it becomes operational.
- `false_autonomy`: A customer agent may appear autonomous at the conversation layer while still depending on hidden human policy authorship, silent guidance edits, and unspoken exception boundaries.
- `policy_precedence_ambiguity`: If multiple policy sources exist - base system rules, help-center content, guidance text, workspace settings, and escalation instructions - then the order of authority matters. Without a visible precedence model, behavior can drift through plain-language edits rather than explicit system changes.
- `customer_facing_learning_loop`: When a vendor also claims that the agent improves over time, the interaction between adaptive behavior and editable guidance becomes a control problem. Improvement can mask policy drift unless changes are observable, reviewable, and reversible.

## Contract Field Findings

These are the intake fields that would need to be explicit before a router should accept the workflow as execution-ready.

- `known_dependencies`: Agent behavior depends on guidance text, policy content, escalation rules, and the surrounding product configuration model.
- `approval_requirements`: Guidance changes that alter customer-facing behavior should have explicit review and authority boundaries.
- `route_continuity`: Safe operation depends on a visible path for conflict resolution, fallback, escalation, and rollback when guidance produces unwanted behavior.
- `evidence_available`: The public help documentation is sufficient to support an instruction-surface diagnostic, but not sufficient to treat the guidance layer as governance-complete.

## Next Allowed Action

Treat guidance as a bounded policy layer: publish instruction precedence, require review for behavior-changing guidance edits, log guidance mutations, and separate descriptive content from action-authorizing text.

## Do Not Do

- Do not treat plain-language guidance as harmless copy when it changes customer-facing behavior.
- Do not describe the system as safely autonomous if policy authorship and exception boundaries remain implicit.
- Do not let adaptive behavior and editable guidance compound without rollback and audit visibility.

## Publication Gates

- `public_source_check`: pass
- `no_confidential_data_check`: pass
- `public_surface_terminology_check`: pass
- `semantic_density_check`: pass
- `source_specific_evidence_check`: pass
- `sentinel_spot_check`: recommended_before_using_as_sales_claim