Keep Rejected Options in Your Agent Decision Log

An activity log tells us what an agent did. A decision log should also tell us what it considered and rejected.

Without rejected options, a later reviewer sees a clean path that never existed: model B was selected, the task restarted, the result succeeded. Missing are the reasons model A was unsuitable, why staying put was worse, and what new evidence would change the choice. That information matters for trust and recovery. It lets people challenge a decision without reconstructing the entire session.

Execution history is necessary, but different.

Current Execution History

The MonkeyCode model-switch record at commit c58bcd4 stores the task and user, from/to model IDs, request ID, whether to load the session, success, message, session ID, and timestamps. The switch use case creates that switch record, restarts the task with the target configuration, and records the result. That is valuable execution history. It answers “what switch was requested and what happened?”

The expanded rejected-options structure below is my design proposal, not a claim about MonkeyCode's current schema or interface.

Add the Decision Before the Outcome

A reusable record can separate choice from execution:

{
  "decision_id": "task-42-model-switch-7",
  "context": "The task needs the required tool-call contract.",
  "chosen": {
    "option": "model-b",
    "reason": "Passed the declared capability contract",
    "evidence": ["evaluation/capability-model-b.json"]
  },
  "rejected": [
    {
      "option": "model-a",
      "reason": "Required tool-call case failed",
      "evidence": ["evaluation/capability-model-a.json"],
      "revisit_when": "Adapter version changes"
    }
  ],
  "execution": {
    "request_id": "req-switch-7",
    "result": "success",
    "session_id": "session-9"
  }
}

The key field is revisit_when. “Rejected” should not mean universally bad. It should mean unsuitable under a specific context and evidence set.

Design the Interface for Progressive Disclosure

Do not paste this JSON into the main task timeline. Use three layers:

• Timeline: Switched from model A to model B
• Why: B passed the required tool-call contract
• Details: 2 rejected options, evidence, operator, execution result

The first layer supports reorientation. The second supports a quick trust judgment. The third supports audit, debugging, and appeal.

When execution fails, keep the decision and result separate:

• Decision: choose model B based on capability evidence
• Execution: restart failed; task remains on model A
• Recovery: retry, choose another option, or ask the operator

Otherwise the interface may imply that a chosen action actually took effect.

Validate the Record

The companion validator requires context, chosen evidence, at least one rejected option, a reason and revisit condition for every rejection, execution identity, owner, and review date.

node validate-decision-log.mjs decision-log.json
node test-decision-log.mjs

Expected output:

PASS decision log
PASS complete decision; rejected options without reasons or revisit conditions failed

Validation cannot judge whether the reason is truthful. It makes omission visible and gives review tools a stable surface.

Research the Pattern Before Making It Default

Use task-based evaluation with operators who review or recover agent work. Give them two histories-execution-only and decision-plus-rejections-and ask them to:

• explain why the action happened;
• identify which evidence they would challenge;
• recover after a failed action;
• decide whether a rejected option is now viable;
• report which details felt useful or overwhelming.

Measure explanation accuracy, recovery time, erroneous assumptions, and expansion of the details layer. This article does not report a user study; it proposes that study.

Rejected options are not clutter when they preserve decision boundaries. They are the counterfactual context that turns an agent trace into something a person can question, repair, and learn from.

Disclosure: I contribute to the MonkeyCode project. Current execution-history fields are based on the linked pinned source. The rejected-options schema, interface layers, and research plan are proposals; the standalone validator was tested locally.