TL;DR
Grounding Awareness (the ability to tell what was proposed from what was agreed) is something personal agents almost entirely lack. The Grounding Layer is a lightweight add-on with no fine-tuning: the agent keeps an agreements ledger and checks it before any important action. Each agreement in the ledger has an author, a status (accepted, unacknowledged, revised, scoped to a condition), a scope and a quote from the conversation.
The core pain: the agent suggested "how about I decline cold sales emails myself", you said nothing and moved on. A month later a sales email arrives, and the agent declines it on its own, as if you'd approved it. The culprit is memory. It keeps what was discussed but loses what you approved. The researchers found two unexpected effects. The more information the agent has, the more often it carries out unapproved actions: it remembers the proposal better, but not that there was no reply. And long-term memory turns the agent's own suggestion into a "fact about the user".
The method is simple: explicitly store the status of each agreement and check consequential actions (sending, paying, changing the calendar) against that status. If the status isn't "accepted" or the condition isn't met, the agent asks instead of acting.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1 (on write): agreement → ledger entry:
what · who proposed it · status · conditions/scope · quote from the conversation
statuses: accepted / unacknowledged / revised / scoped
STEP 2 (before a consequential action): find the ledger entry on this topic
→ check status and scope
STEP 3 (decision): accepted AND condition met → act
otherwise → ask for confirmation
All of this fits into a single system prompt or instructions file.
Example in Practice
Task: You're the founder of a small agency. You have a personal agent with access to your email and calendar, running as a Slack bot or in ChatGPT. A month ago the agent offered: "I can decline cold pitches from ad agencies myself." You answered a different question and never closed the topic. Today MediaSphere writes in, offering to sell you $15,000 worth of advertising.
Prompt (system instruction for the agent):
You are the personal assistant to an agency founder. You keep an AGREEMENTS LEDGER.
Recording rules. Log each agreement like this:
- arrangement: what exactly was proposed or decided
- proposer: who proposed it (user / assistant)
- status: accepted (the user explicitly agreed) | unacknowledged (proposed, no reply) | revised (the user changed the terms) | scoped (agreement only under a condition)
- scope: where and when it applies
- evidence: a quote from the conversation
Your own proposal NEVER becomes a rule by itself. Silence, a change of topic and "okay, later" mean unacknowledged, not accepted.
Action rules. Before any consequential action (sending an email, declining, paying, changing a meeting):
1. Find the ledger entry on this topic.
2. Check status and scope.
3. If status = accepted and the scope condition is met, do it and report back.
4. In every other case, don't do it; ask: "I suggested [what], you didn't confirm. Should I go ahead?"
Current ledger:
- arrangement: decline cold pitches from ad agencies
proposer: assistant | status: unacknowledged | evidence: "[user's reply about something else]"
New incoming: an email from MediaSphere offering $15,000 worth of advertising.
What do you do?
Result: The agent finds the entry with status "unacknowledged" and won't decline on its own. It will say it once suggested this rule but you never confirmed it, and ask whether to decline the email and whether to make that a rule going forward. If you set the status to accepted with the condition "only if the budget is under $5,000", the agent checks the amount. $15,000 is outside the condition, so it asks again.
Why It Works
The weakness. The model is great at remembering what was said. But "there was no reply" is the absence of an event, and the text is silent about it. When memory summarizes the conversation as "the agent and the user decided to decline sales emails", the model reads it as fact. The full conversation doesn't save you either: most errors happened even when the needed data was right there. The model simply didn't use it.
The strength. If the status is written explicitly and right next to the agreement, the model takes it into account. In the experiments, adding the status sharply improved decisions. Reasoning mode amplified the effect even more, but only when the status was already in the text. Without the status, a thinking model didn't help.
How the method uses this. The ledger turns the implicit ("didn't reply") into an explicit field, status: unacknowledged. The pre-action check forces the model to match that field against its decision. The model doesn't guess the mood of the conversation; it reads a ready-made label.
Control levers:
- What counts as a "consequential action" → widen the list (money, outbound emails, deletion) or narrow it so the agent doesn't double-check every little thing.
- Statuses → add expires (an expiry date) if agreements should go stale.
- The scope field → the more specific the conditions ("only up to $5,000", "only emails from agencies"), the more precise the boundary check.
- Reasoning mode → turn it on for consequential decisions. It amplifies the effect of an explicit status.
Prompt Template
You are {agent_role}. You keep an AGREEMENTS LEDGER between you and me.
<Ledger>
Each entry:
- arrangement: {what_was_proposed_or_decided}
- proposer: user | assistant
- status: accepted | unacknowledged | revised | scoped
- scope: {where_and_when_it_applies}
- evidence: {quote_from_the_conversation}
</Ledger>
<Rules>
- Your proposal doesn't become a rule until I explicitly agree.
- Silence, a change of topic, "later" = unacknowledged.
- If I changed the terms, record a new version with status revised and mark the old one as outdated.
- If I agreed "only when…", the status is scoped; record the condition in scope.
- In memory about the user ("the user likes / allowed"), record only what I said myself or explicitly approved.
</Rules>
<ActionCheck>
Before a consequential action ({list_of_actions}):
1. Find the ledger entry.
2. Check status and scope.
3. accepted and the condition is met → act and tell me.
4. Otherwise → don't act; ask: "I suggested {what}, you didn't confirm / the condition isn't met. Go ahead?"
</ActionCheck>
Current ledger:
{entries}
Incoming task: {task}
What to fill in: {agent_role} is who the agent is (assistant, sales manager). {list_of_actions} is whatever's costly to get wrong for you: sending emails, payments, rejections, rescheduling meetings. {entries} are the agreements that have already piled up. If you don't have a ledger yet, start with an empty one. {task} is the new situation.
🚀 Quick start: paste this into a chat:
Here is a Grounding Layer template (an agreements ledger). Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which actions are "consequential" for you, which agreements already exist and what conditions they carry. That's necessary because the method only works when the list of risky actions and the boundaries of conditions are named explicitly. It will take the "entry → status → check" pattern and assemble a ready instruction for your agent.
Limitations
⚠️ Level of detail: in the available excerpt of the paper, the Grounding Layer is only described in broad strokes: a ledger with author, status, scope and quotes, plus action checks. The authors' exact prompt text isn't there. The template above is assembled from the listed fields; it's not a copy of the original.
⚠️ Status doesn't solve everything: an explicit status helps determine whether a proposal was accepted, but doesn't always help determine where it applies. Extra "how to act" instructions improved one thing and hurt another: the agent got better at telling accepted from unaccepted but made more mistakes with condition boundaries.
⚠️ Models differ: for one of the models (Gemini), an explicit status changed almost nothing. Test on your own model.
⚠️ A low ceiling: even with a perfectly supplied status, models got most cases wrong under the strict metric. The ledger reduces risk but doesn't replace human confirmation for irreversible actions.
⚠️ The ledger has to be live: in a chat without memory, you'll have to keep the ledger by hand or ask the agent to update it. If an external system writes the memory (ChatGPT Memory, plugins), you don't control what it records.
How They Studied It
The researchers spotted a gap: every memory benchmark checks whether an agent remembers what the user said and likes. Nobody checked whether it remembers what was agreed. They built 160 scenarios covering 800 test situations. In each, the assistant proposes a standing rule (preferences, delegation, agreements), followed by five dialogue variants: accepted, ignored, never proposed, revised, scoped to a condition. The test event is identical; only the user's reaction changes. That shows whether the agent actually accounts for it. They tested four models and four memory systems (Mem0, A-Mem, MemOS, LangMem), plus two off-the-shelf agents, Hermes and OpenJarvis. The labels were checked by humans, with high inter-annotator agreement.
The results. Systems that do well on standard memory tests failed here: sensitivity to acceptance was around 0.1–0.2, while on familiar benchmarks the same systems scored about 0.75. The full conversation history barely helped. The biggest surprise: adding only the content of the proposals increased false execution: for Qwen with Mem0 it rose from 0.26 to 0.53. Adding the "accepted / not" status raised sensitivity for Qwen from 0.09 to 0.34, and for DeepSeek from 0.07 to 0.41. DeepSeek with reasoning plus status reached 0.73, while reasoning without status gave almost nothing. In real agents, 86–100% of unconfirmed proposals were written to memory as confirmed facts about the user.
The practical insight: the problem isn't missing data, it's the loss of one tiny signal: "did they agree?". It needs to be stored as a separate field and checked before acting.
Adaptations and Extrapolations
💡 Adaptation for an instructions file (CLAUDE.md, AGENTS.md, ChatGPT memory): a recording rule instead of a full ledger. This is my inference from the paper's finding; the paper didn't test this wording.
In long-term memory and in this file, record as a "rule" or "user preference" only what I phrased myself or explicitly approved with words like "yes", "agreed", "do it that way".
If you proposed something and I didn't reply, record it as "proposal, not confirmed" and don't apply it without asking.
Before sending, paying, deleting or changing anyone else's data, check against these records.
🔧 Technique: turn on reasoning for the check → a more reliable match. In the experiments, reasoning mode strongly amplified the effect, but only with an explicit status. For the ActionCheck step, it's worth asking: "First write out, step by step, what you found in the ledger and why the action is or isn't allowed, then decide."
Resources
- Paper title: Knowing the User Is Not Knowing What We Established: Grounding Awareness in Personal Agents
- Authors: Jiajun Chen, Xinyue Chen (Carnegie Mellon University), Yicheng Jiang, Hua Shen (New York University, NYU Shanghai)
- Theoretical basis: grounding theory and common ground in dialogue (Clark & Schaefer, 1989; Clark & Brennan, 1991; Traum, 1991)
- Memory systems tested: Mem0, A-Mem, MemOS, LangMem; agents Hermes-Agent and OpenJarvis
- Compared with memory benchmarks: LoCoMo, LongMemEval, PersonaMem, PrefEval