Issues
What degraded during assembly, and where. Under Observe → Issues.
What Issues shows
A payload rarely fails outright — it degrades. An enrichment throws, a field is stripped, a formula can’t evaluate, and the agent still gets an answer with less in it. Each row is a category, an item key, the domain the call came through (blank for direct calls), an occurrence count, a sample message, and when it was last seen. The same issue hit through two domains is two rows — so you can see not just what degraded, but whose payloads it degraded. Trends counts these per domain, week over week.
| Category | What happened | Usually means |
|---|---|---|
fls_strip | A curated field was stripped by field-level security | Fix the permission set, or drop the field |
element_failure | A metric, formula, or enrichment threw | A broken expression, a provider bug, or a source that no longer exists |
config_invalid | A definition couldn’t be resolved | A renamed field or relationship, or an element used where it doesn’t apply |
hard_error | Assembly itself failed | Rare — the sample message names the cause |
The first three categories are entity degradation — a payload that arrived with less in it. Briefs, skills, and catalog reads have no partial state: they serve whole or fail, so they appear here only as hard_error rows, named for the artifact (catalog failures file under (catalog)).
Best practices
- Check Issues after every change. A failing formula or enrichment is silent to the agent — make this the last step of any edit.
- An empty page is the goal. Every row is something to fix or deliberately accept.
fls_stripis common and often correct — the real question is whether the entity should still carry a field its audience can’t see. If not, remove it and reclaim the tokens.element_failuredeserves immediate attention. A section is missing from every payload, and the agent’s answers still look complete.
What’s next
- Debug Logs — when a row here isn’t enough and you need the payload itself.
- Quality and performance