Grounding an agent's answers about its own environment: acknowledgement is not proof of completion

Research
1

Sharing a small firmware change that I think generalizes well beyond our specific use case, for anyone building agents that need to answer questions about their own setup, ownership, or task status.

The problem: an agent asked “what do you own,” “where did this route to,” or “did this actually finish” can produce an answer that sounds confident but isn’t grounded in anything it can actually verify. Without a real reference to check against, a plausible-sounding guess and a correct answer are indistinguishable from the outside, and the agent isn’t being dishonest exactly, it’s just filling a gap with the most plausible-sounding thing available.

The fix (PR #624): a bundled, project-specific self-knowledge reference covering hardware ownership, runtime routing, device-bridge behavior, board configuration, setup, observation, verification, and recovery boundaries. Routing, device settings, and recovery paths are related but not interchangeable, so the reference is scoped per-area rather than one generic description of “how the system works.”

The part I think is genuinely reusable outside this specific firmware: the Skill enforces a hard distinction between acknowledgement and completion. Receiving or accepting a request is a real, loggable event. It is not evidence that anything downstream actually finished. Verified completion needs its own evidence, drawn from whatever observation or verification path actually applies to that task.

A concrete example of the same discipline applied narrowly: during one specific recovery process, the agent can encounter a stale image left over from before something failed. The Skill is explicit that a stale image can’t be used as evidence for what happened or whether recovery succeeded. That rule is scoped to that one recovery path. It’s not generalized into a blanket claim about every image the system ever processes, and I think that scoping is actually the harder and more useful part of the design, it would have been easier to write a broad rule and less useful.

Validation here was structural, not behavioral: lint (zero issues), YAML frontmatter validation, focused skill-loader tests, git diff checks. That confirms the content is formatted and loadable. It does not confirm every future answer will be correct, and the writeup is upfront about that.

Full writeup: https://aidenai.io/blog/aiden-adds-a-self-knowledge-skill-for-clearer-agent-boundaries/

PR: docs: add Aiden self-knowledge skill by web3luhao · Pull Request #624 · AidenAI-IO/aiden-firmware · GitHub

wondering if others here have run into the same “confident but ungrounded self-description” problem, especially in agent systems that operate across multiple subsystems where the honest answer genuinely depends on which subsystem is being asked about. Did you solve it with a similar bundled reference, or something structurally different?

4

This was genuinely useful. We’ve been running into essentially the same problem in a local agent system — especially the difference between “the agent knows a task was accepted” and “the agent can actually prove the intended end state happened.”

We already had pieces of the verification machinery, but your post gave us a cleaner way to think about tying it together. The acknowledgement/completion distinction in particular sent us down a useful rabbit hole.

What we ended up doing with the idea was taking it a little further toward a verification-routing concept. Instead of the agent having one generic idea of “how the system works,” different claims point toward the specific thing that can actually prove them: runtime state, a queue, a scheduler, an artifact, a test result, a project record, etc.

We’re also using lightweight verification records so the agent can quickly see that something was previously verified, when it was verified, and where the underlying evidence lives. If that evidence is stale, missing, or important enough to warrant another look, it can go back to the actual source and verify it again rather than simply trusting the record.

That starts making it useful above the individual-task level too. A larger plan can be broken into verifiable end states, which gives the agent a way to answer something like “how complete is this actually?” based on what has been proven rather than what everybody thinks has probably been finished.

So, thanks for posting this. Your framing gave us a useful springboard for organizing a solution around it and I appreciate it.

5

The verification-routing concept is spot on! Routing specific claims directly to their proof sources avoids so many subtle agent hallucination bugs.

6

The acknowledgement/completion split becomes easier to enforce when completion is modeled as a typed claim with required evidence, rather than a sentence the model may improvise. For each action, I would store the intended effect, verifier, observed state, timestamp, and freshness policy. If the verifier is unavailable, the honest state is unknown, not failed and not complete. The interesting evaluation is whether the agent preserves that distinction when a user pressures it for certainty.