agent failed to notice the backup failed when it parsed completed-with-warnings as success
Fixes agents misreading completed-with-warnings as success: parse product result taxonomies strictly, treat warnings as their own outcome, and surface warning details. Use when an agent marks warning-finished backups as healthy. Not for agent hallucination where nothing ran.
TL;DR
Backup products distinguish success, completed with warnings, and failed for a reason: warnings mean something was skipped or degraded. An agent that collapses warnings into success hides skipped files and partial restores. Teach the agent the product exact status taxonomy, map warnings to a needs-attention outcome with the warning text attached, and alert on warning trends even when no job fully fails.
agent failed to notice the backup failed when it parsed completed-with-warnings as successUse this when
- Agent reports show all healthy while the backup console shows many warning results.
- Skipped files or skipped VMs appear in product logs but never in agent summaries.
- A restore gap is traced to a backup that had warned about skipping the item.
Not for this skill when
- The agent fabricates results without running jobs. Grounding problem.
- The product itself marks skipped critical data as pure success. Vendor behaviour to escalate, not parser tuning.
Steps
- List the product possible job outcomes and the agent current mapping for each. Verify: the mapping table is documented and the warning collapse is visible
- Change the mapping so warnings produce a distinct attention outcome carrying the warning messages. Verify: a warning job in a test produces the new outcome
- Add rules for warning types that must escalate, such as skipped files, skipped VMs, or degraded redundancy. Verify: seeded warning types escalate correctly
- Backfill reporting for recent runs so warning jobs are reclassified in dashboards. Verify: historical warning counts become visible
- Run a verification cycle and confirm the summary separates success, warning and failure counts. Verify: counts reconcile with the product console
Variant phrasings
completed with warnings parsed as success agent
The parsing phrasing.
backup warnings hidden agent reporting fix
The visibility variant.
veeam warning status agent taxonomy
The product wording.
Compatibility: Agents parsing Veeam, Commvault, Acronis and similar product statuses via API enums, email reports and log scraping.
Why it happens
Status taxonomies encode operational judgement: warnings are where slow data loss hides, because a job that skips one file a night eventually skips the file that matters. Agents trained on binary success thinking, and report templates with two buckets, erase that signal. Preserving the third bucket, with its text, is a small change with outsized protective value.
Edge cases / pitfalls
- Warning fatigue is real. Trend reporting beats per-warning alerts for low-severity types.
- Some warnings are benign by local policy, such as skipping page files. Record those as an explicit allowlist, not as parser blindness.
- Restores from warning jobs deserve priority in verification sampling.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_sVPNgP7wTzJMjzY4UIsIFw