TL;DR
E-Ledger is a four-part harness around an agent. Before every action, code checks it against company policies and either allows it, asks for clarification, tries a probe, or blocks it. The agent keeps a state log: what’s been verified and where it can be seen. Next to it sits a registry of hidden rules: “if you do X, Y quietly changes.” WorldAbduct is a way to fill that registry. The model breaks down failed runs using four questions, proposes hypotheses about hidden rules and tests them with separate probe actions. Only confirmed rules make it into the registry.
The core pain: the tool replies “success,” but something else actually changed. For example, after a credit was posted, the customer’s priority quietly went up, and the next transfer now violates policy. The agent sees only the tool’s response and assumes the world is exactly as the response describes it. It doesn’t know rules that appear neither in the policy nor in the response. On top of that, it forgets previously confirmed facts and can reason its way around a “known” rule.
The method plugs these holes with three things. Policies are enforced by code, not by “please comply.” Facts live in a log with sources. Hidden rules start as hypotheses and only enter the registry after a probe. On an enterprise benchmark, the share of safely completed tasks grew 2–4x compared with a regular agent. For readers who don’t code, the transferable ideas are: the log, the gate, verification after a write, and breaking down logs with four questions.
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
E-Ledger runtime (on every agent step):
STEP 1: Task agent proposes an action + a forecast of “what will change” → action + expected change
STEP 2: Policy-context agent pulls the fields needed for the policy check from the log → facts for the gate
STEP 3: Code gate checks the action against policy → execute / query / probe / block
(query and probe — not enough data; block — violation, replace the action)
STEP 4: The action runs, the tool responds
STEP 5: State-tracking agent updates the log (with evidence) → dynamic state
+ the hidden-rule registry helps interpret indirect effects
WorldAbduct evolution (after runs, a separate loop):
STEP 1: Break down the trajectory through 4 lenses:
• state consistency (forecast ↔ tool response ↔ log)
• “observation gap” (what changed, but the tool said nothing about it)
• gate correctness (why the action didn’t pass the gate)
• goal assessment (stopped too early? a violation slipped past the gate?)
STEP 2: Two kinds of output → a direct harness edit OR a hypothesis about a hidden rule
STEP 3: Abduction agent, in a fresh environment, designs probe actions for the hypothesis
STEP 4: Decision: act (another probe) / revise (adjust the hypothesis) / verified / unresolved
STEP 5: Only verified → into the hidden-rule registry (action, condition, effect, evidence)
In the original this is several agents plus code. A chat version is described below in the templates.
Example
Task: You’re setting up an agent for Salesforce that moves deals through the pipeline. Policy: a discount above 15% requires the head of sales’ approval. The agent has handled a dozen deals, and in two cases something broke. After moving to “Invoice Sent,” the “Discount” field turned out to be locked, and the contract went out to the customer. The tool’s response simply said “Deal updated.” You need to figure out which hidden rules are behind this and update the agent’s instructions.
Prompt:
You are an agent-run diagnostician. Break down the log below through four lenses, then propose hypotheses about hidden rules and design safe probes to test them.
<Policy>
1. Discount > 15% — only after the head of sales approves.
2. A deal can be moved to “Invoice Sent” only if billing details are filled in.
</Policy>
<Log>
1. get_deal(4821) → stage “Negotiation,” discount 12%, billing details present
2. update_deal(4821, discount=18%) → “Deal updated”
3. move_deal(4821, “Invoice Sent”) → “Deal updated”
4. update_deal(4821, discount=10%) → ERROR: field not editable
5. Agent reported: “18% discount applied, deal in progress”
</Log>
<Lenses>
A. State consistency: where did the agent’s forecast diverge from the tool’s response? What should the agent have recorded in the log but didn’t?
B. Observation gap: what changed even though the tool didn’t report it? Which steps could have caused it? Phrase it as a hypothesis.
C. Gate: which actions should policy have stopped? Why weren’t they stopped? What data was the gate missing?
D. Goal: can the task be considered safely completed? Is there a violation nobody caught?
</Lenses>
<Output>
1. Direct edits to the agent’s instructions (short, as bullet points).
2. Hypotheses about hidden rules in the format: (action, condition) → effect.
3. For each hypothesis — a probe plan in a sandbox copy of the org: which 2–4 actions, what you expect to see, what would disprove the hypothesis.
Mark hidden rules “HYPOTHESIS” until they’ve been tested. Don’t move anything into “confirmed.”
</Output>
Result: The model will produce a breakdown in four blocks, A–D. It will show that the 18% discount went through without the head of sales’ approval and that the agent didn’t check the state after moving to “Invoice Sent.” Next come edits to the instructions and hypotheses like “moving to ‘Invoice Sent’ locks the discount and triggers sending the contract.” Each hypothesis comes with a probe plan for a sandbox copy of the org. Which rules turn out to be real will only become clear after the probes. The model merely proposes hypotheses.
Why it works
The weakness. An LLM agent relies on what it sees: the tool’s response and its own history. If the tool is silent about a side effect, the agent assumes there is none. A “follow the policy” line in the prompt text is something the model can reason its way around: “but the action makes sense.” And on long tasks it loses confirmed facts and either re-checks the same thing or stops too early.
The strength. Models are good at three things. They extract facts from a noisy response into neat fields. They search a log for which past action could have caused a strange change. And they design targeted probes to test a hypothesis. All of this is abduction: inferring a likely cause from an observed effect.
How the method ties these together. Enforcement goes to code, and the model does what it’s good at. The gate doesn’t depend on the agent’s reasoning. The log keeps facts outside the context. Breaking things down through four lenses yields hypotheses, and testing with probes weeds out fabrications. A made-up rule in the registry is worse than no rule at all.
Knobs:
- Gate decisions. Add probe/query instead of a binary “yes/no,” and the agent gathers missing data instead of guessing.
- Set of lenses. In the experiment, each lens has its own profile. Goal assessment yields more completed tasks but, on its own, triggers unsafe actions. The “observation gap” delivers maximum safety. You need all four together.
- Rule status. Hypothesis → tested → into the registry. Remove the testing step and the registry fills up with false rules.
- Evidence in the log. Every entry has a source. Conflicts and unverified fields are flagged separately.
Prompt Template
The original relies on a code gate. Below is a version for a regular agent with instructions: the gate is a separate verification step. It’s weaker than code, but it carries over the structure itself.
Template 1. Agent system instructions (E-Ledger runtime in text)
<Role>
You carry out tasks in {system}. You work in a loop: propose → check → execute → update the log.
</Role>
<Policies>
{list of policies: what’s forbidden, what requires approval, which preconditions apply}
</Policies>
<WorldLedger>
<StaticRules>
<!-- Confirmed hidden rules. Format: (action, condition) → effect. Source/evidence. -->
{rules_or_empty}
</StaticRules>
<DynamicState>
<!-- Facts for the current task: ids, fields, links. Every fact has a source (which tool response it came from). -->
{state}
</DynamicState>
</WorldLedger>
<Loop>
Before EVERY write action (create, update, delete, move, send):
1. PROPOSE: name the action and predict what will change (including side effects from StaticRules).
2. CONTEXT: list the fields from DynamicState needed to check the policies. If a field isn’t in the log — don’t make it up, mark it “no data.”
3. GATE: check the action against every policy and choose exactly one decision:
- execute — all preconditions are confirmed in the log with a source;
- query — data is missing: run a read call first;
- probe — it’s unclear how the policy applies: do a safe probe;
- block — violation: replace the action, don’t execute it.
Reasoning like “it makes sense, so it’s allowed” does not count as grounds for execute.
4. ACT: execute the action only on an execute decision.
5. UPDATE: compare the tool’s response with your forecast. Record in DynamicState only what the response confirms. Mark discrepancies and unresolved fields “CHECK.” A “success” response is not proof of the final state: read the record back with a read call if a policy depends on it.
</Loop>
<Finish>
Don’t finish the task until: (a) all subgoals are closed according to the log; (b) there are no “CHECK” fields that affect policies. If the task can’t be completed safely — explain and decline.
</Finish>
Template 2. Run diagnostician (WorldAbduct)
<Role>
You are a diagnostician. You analyze an agent’s work log and improve its instructions and the hidden-rule registry.
</Role>
<Input>
Task: {task}
Policies: {policies}
Current agent instructions: {instructions}
Log (actions, tool responses, agent forecasts): {log}
Result assessment (if available): {result}
</Input>
<Diagnosis>
A. StateConsistency: agent forecast vs. tool response vs. log. What wasn’t recorded, and what was recorded without support from a response?
B. WorldObservationGap: what changed in the state without the tool reporting it? Which earlier actions are candidate causes? Formulate hypotheses.
C. PolicyGate: which actions failed the gate or should have? Why? How can the agent’s action or the gate’s data be improved?
D. GoalJudgment: was the goal achieved? Was there a premature stop? Did a violation slip past the gate? Is safe completion or a justified refusal still possible?
</Diagnosis>
<Output>
1. DirectUpdates: the smallest edits to the instructions that close the gaps found.
2. Hypotheses: (action, condition) → effect; status HYPOTHESIS.
3. ValidationPlans: for each hypothesis, 2–4 probe actions in a clean test environment, the expected result, and what would disprove the hypothesis.
</Output>
<Abduction>
When I send the probe results, choose one for each hypothesis:
- act: another probe is needed (say which);
- revise: the data points to a different rule (give a new formulation);
- verified: give the rule, its condition of applicability and the evidence;
- unresolved: not enough data.
Move only verified rules into the hidden-rule registry.
</Abduction>
What to fill in. The system name (CRM, ITSM, ERP), the policies verbatim, the agent’s current instructions, and the run log including tool responses. Leave the log and registry empty at first.
🚀 Quick start — paste into a chat:
Here are the E-Ledger template (an agent runtime with a log and a gate) and WorldAbduct (a run diagnostician). Adapt them to my task: [your system and what the agent does].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about your system, the types of write actions, the policies and approvals, and which side effects you’ve already noticed. It needs this for the first entries in the hidden-rule registry and for the gate conditions. The model will take the structure from the template and assemble working instructions for your system.
Limitations
⚠️ A text gate is weaker than a code gate: the main safety gain comes from code that can’t be reasoned around. Without code, the model can “agree with itself.” The template only lowers the risk; it doesn’t guarantee anything.
⚠️ You need an environment for probes: a hidden-rule hypothesis is tested in a fresh copy of the environment. Never test on a live CRM or production database: the probes themselves change things.
⚠️ More expensive and longer: the agents take more steps, and the full method costs noticeably more than plain ReAct. For simple tasks with no policies or side effects, it’s overkill.
⚠️ Small sample: there weren’t many test tasks (results come in multiples of 5 pp). Treat the effect sizes as orders of magnitude, not precise figures.
⚠️ A single lens is risky: goal assessment on its own boosts completion but triggers unsafe actions. You need to use all four lenses.
⚠️ Cautious models: some models simply stop when in doubt instead of looking for a safe workaround. Safety holds, but fewer tasks get completed.
⚠️ Without hidden-rule testing, the log isn’t enough yet: on one of the models, base E-Ledger without evolution was no better than a regular agent at safe completion. A log without knowledge of hidden rules doesn’t add much.
How the research was done
The researchers used the World of Workflows enterprise benchmark. There the agent works with records, permissions and approvals, and some consequences of its actions are hidden from it. To check generality, they added two science environments, ScienceWorld and DiscoveryWorld. All tasks were split 2:1:2: training trajectories drive evolution, validation ones pick the best harness version, and test ones stay closed for the final evaluation.
Four models and three approaches were compared. The first is plain ReAct with no harness. The second is MemoHarness, which edits six harness components based on case breakdowns. The third is WorldEvolver, which builds a library of state changes only from what’s visible in tool responses. WorldEvolver doesn’t test hypotheses with probes.
The results are striking in scale. On one model, safe completion rose from 25% (ReAct) to 80% (E-Ledger + WorldAbduct). On another, from 20% to 70%. The best competitor trailed by 5–15 pp. On DeepSeek, E-Ledger doubled the share of safe completions at the same overall completion rate: the remaining errors were mostly “didn’t finish,” not “violated.”
Ablations showed what each part contributes. Remove the hidden-rule registry and safe completion drops from 75% to 40%. That’s the heaviest blow. Without the state log, it drops to 65%. Without the code gate, the completion rate doesn’t change but safety falls: the model can still take a forbidden action for the sake of the goal. Another non-obvious finding: on one model, E-Ledger without evolution was no better than a regular agent at safe completion (30% vs. 35%). The “gate + log” skeleton doesn’t replace knowledge about the world — that has to be accumulated.
Adaptations and extrapolations
🔧 Technique: “four-question breakdown” without multiple agents → a quick agent audit
Feed any agent log (Claude Code, Cursor, an n8n workflow) along with a short instruction:
Break down this log using four questions: (1) where did the agent write something to memory that wasn’t in the tool responses? (2) what changed in the system that the tools didn’t report? (3) which actions should have been stopped by a policy check? (4) was the goal actually achieved, or did the agent stop early? For each point, give an edit to the agent’s instructions.
This is the easiest way to use the idea from the paper.
🔧 Technique: “read call after a write” → a rule in CLAUDE.md / AGENTS.md
Add this line to your instructions file: “After any change to data that policies depend on, re-read the record and compare it with what you expected. ‘Success’ in a response is not proof of the final state.”
Extrapolation: a
hidden-rules.mdfile for your agent. Create a file in your project with blocks of “action → side effect → how it was verified → date.” Add only what you’ve confirmed by hand or with a test run. Reference it in CLAUDE.md: “Before any write action, check hidden-rules.md.” That gives you an equivalent of the hidden-rule registry without code.
Resources
- Paper: Safe, Persistent, and Evolving Agent Harness for Understanding Partially Observable Worlds (E-Ledger and WorldAbduct), preprint
- Code: https://github.com/HKUST-KnowComp/ELEDGER-WorldAbduct
- Authors: Yisen Gao, Yue Guo, Qing Zong, Yiwen Guo, Yangqiu Song — Hong Kong University of Science and Technology, LIGHTSPEED
- Benchmarks: World of Workflows (Gupta et al., 2026), ScienceWorld (Wang et al., 2022), DiscoveryWorld (Jansen et al., 2024)
- Baseline methods: ReAct (Yao et al., 2022), MemoHarness (Huang et al., 2026), WorldEvolver (Zhang et al., 2026)