Evidence-First Agent Reporting

Rocky should not sound confident because it can write polished prose. It should sound confident only when it has evidence. A good report explains what was changed, what was actually run, and what the system returned.

Official Hermes Agent docs: https://hermes-agent.nousresearch.com/docs

What belongs in a report

• The exact pages, files, commands, or systems touched.
• The verification checks that ran successfully.
• The live URLs or artifact paths that were checked.
• Any generated assets and where they were saved.
• Known risks, skipped checks, or blockers.
• A clear no-deploy explanation when validation fails.

What to avoid

• Vague claims such as “tested thoroughly” without naming the test.
• Fabricated output or assumed success from a command that failed.
• Private customer details in a public-facing summary.
• Over-promising future automation that has not been built.
• Hiding partial failure behind optimistic language.

Checklist for Rocky operators

• Did the final answer mention real evidence, not just intent?
• Did every claim map to a command, screenshot, endpoint, file, or source document?
• Were failures described directly?
• Were public URLs verified after deployment?
• Is the remaining manual work specific enough for a person to act on?

Pitfalls

A report can be too long and still not useful. The goal is not to dump logs; the goal is to provide enough receipts that a busy operator can trust the result and know the next step.

Verification steps

• Re-read the final report against the original request.
• Confirm every required deliverable is named.
• Confirm any blocker explains why the job stopped.
• Confirm no secret, token, private path, or customer record appears in the public report.