# Production-ready self-learning enterprise-agent claims can outrun visible control density

Entry: `bt-017`  
Verdict: `REWORK`  
Observation date: `2026-06-17`  
Artifact type: `product_claim_surface`

## Hard Summary

| Check | Result |
| --- | --- |
| Vulnerability class | production_claim_density_exceeds_visible_control_density, false_autonomy, learning_loop_opacity, audit_boundary_gap |
| Failure point | The signal breaks where the homepage compounds production, accuracy, speed, and self-learning claims faster than it exposes evaluation method, rollback structure, exception taxonomy, and ownership of failure. |
| Claimed or implied autonomy | The system is presented as a production-ready layer of self-learning enterprise agents that can already operate at meaningful scale. |
| Observed autonomy | The public surface supports that a serious product exists, but does not expose enough of the control plane to justify reading the combined claims as governance-complete production autonomy. |

## Source

- https://beam.ai/

## Failure Map

- `production_claim_density_exceeds_visible_control_density`: The public surface bundles production deployment, speed, accuracy, and self-learning into one dense readiness claim, but does not match that density with equally visible evaluation, rollback, and exception-control language.
- `false_autonomy`: A production agent can appear self-sufficient at the marketing layer while still depending on hidden human review, narrow workflow scoping, or undocumented fallback procedures.
- `learning_loop_opacity`: When a system claims continuous improvement and exception handling, the key question is not whether change occurs, but whether behavior changes remain observable, bounded, and reversible. That boundary is not visible on the public claim surface.
- `audit_boundary_gap`: Strong performance numbers such as 10x faster and 98% accuracy require method, scope, and error-severity context. Without that context, the public signal is not audit-grade even if the underlying product may be real.

## Contract Field Findings

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

- `evidence_available`: The homepage is enough to identify a dense public production claim surface, but not enough to validate the underlying evaluation or exception architecture.
- `known_dependencies`: The claim depends on hidden workflow scope, measurement protocol, fallback behavior, and operational approval structure that are not visible on the public surface.
- `approval_requirements`: Adaptive behavior and exception handling need explicit boundaries for when humans, policy owners, or operators must review changes or intervene.
- `route_continuity`: A production claim is only continuous when deployment, exception handling, rollback, and acceptance remain visible as one chain rather than separate implied promises.

## Next Allowed Action

Split the public narrative into separately evidenced claims: what is live, what is measured, how accuracy is defined, which exception classes are handled automatically, and what rollback or human-review boundary governs self-learning updates.

## Do Not Do

- Do not let production, performance, and learning claims travel as one bundle without exposing the measurement and control layer beneath them.
- Do not describe self-learning enterprise agents as production-ready if behavior-change review and rollback remain implicit.
- Do not treat a strong homepage metric as audit-grade proof of route continuity.

## 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