← All projects

RESEARCH / OPEN-SOURCE CONTRIBUTION

Evidence-aware AI agent execution

An execution controller that limits retries, enforces prerequisites, and prevents unsupported downstream actions after tool failures.

PythonMCP toolsControlled evaluation

Recovery is an execution-control problem.

I implemented an opt-in evidence-aware controller in the AssetOpsBench plan-execute agent. The controller combines argument validation, failure classification, replay restrictions, attempt limits, dependency checks, and outcome-dependent finalization.

Before a tool call, it checks advertised arguments, required fields, and basic types. After invocation, it recognizes exceptions, MCP error flags, empty responses, and application-level error payloads.

The extension preserves the default execution path. Recovery behavior is explicitly enabled rather than silently changing existing benchmark runs.

Bounded recovery decision flowA failed tool step leads to a limited repair. Valid evidence permits dependent work. Exhausted recovery without evidence blocks dependent actions.Tool step failsBounded repairLimited retry budgetEvidence recoveredContinue dependent workEvidence still missingBlock dependent actions
Conceptual policy flow. Recovery has a limit; dependent execution requires evidence.

A retry needs a reason and a limit.

  • Bounded attempts: at most one extra attempt per eligible step, within a default run-wide allowance of two.
  • Replay restrictions: retries require explicit read-only metadata and no destructive flag. Mutating or unknown-safety calls are not replayed.
  • Prerequisite enforcement: failed or missing dependencies block dependent steps before invocation; independent steps may continue.
  • Explicit outcomes: exhausted recovery and failed dependencies route to deterministic failure reports.

Measured behavior under controlled failures.

I evaluated the production planner/parser, executor, and finalizer using seven fixture cases, two summary scripts, two conditions, and five repetitions: 140 deterministic offline executions.

Per summary script · 35 executions per condition
MeasureBaselineRecovery
Unsupported downstream calls900
Strict fixture successes5 / 3515 / 35

In the permanent-prerequisite failure case, recovery exhausted one retry and blocked four dependent steps. The task still failed, but later actions did not proceed on missing evidence.

What these results establish

The runs use scripted responses and mock tools. Repetitions check reproducibility and state isolation, not independent model behavior. Repair uses oracle-corrected arguments; these results do not establish general accuracy or cost improvements.

Execution integrity as the objective.

This work is documented in Execution Integrity through Bounded Recovery for Plan-Execute Agents, coauthored with Dhaval Patel.

The contribution is the integration of recovery boundaries into the executor, with inspectable traces and measured conditional behavior. Correct metadata and declared dependencies remain important assumptions.