Goal-Directed Repair

The foundational mechanism of goal-directed repair is the continuous comparison between the current system state and the explicitly defined desired goal state. This gap analysis is not a simple binary check but a structured evaluation that identifies specific, measurable discrepancies in output, data format, or logical outcome. The agent uses this discrepancy to fuel its corrective reasoning loop.

• Example: An agent tasked with generating a JSON API response compares its output against a JSON schema validator. A missing required field creates a defined 'gap' between the current (invalid) and goal (valid) states.

Repair strategies prioritize minimal intervention, seeking the smallest set of action modifications needed to close the identified goal-state gap. This contrasts with restarting the entire process from scratch. The principle optimizes for efficiency and resource conservation, especially critical in systems with tool-calling costs or latency constraints.

• Techniques include: Action substitution, step reordering, or parameter adjustment rather than full replanning.
• Benefit: Reduces computational overhead and preserves valid intermediate work from the initial execution attempt.

This characteristic describes a repair process that looks forward from the point of failure to devise a new sequence that reaches the goal, rather than extensively backtracking. The agent treats the current (erroneous) state as the new starting point for planning. It is often paired with constraint relaxation—temporarily loosening non-critical requirements—to find a feasible path forward.

• Contrast with Backtracking: While backtracking may be used sparingly, forward-chaining focuses on 'how to get there from here.'
• Use Case: Ideal for situations where actions have irreversible side effects or where the cost of rollback is high.

Goal-directed repair is intrinsically linked to an agent's self-evaluation capabilities. The repair loop is triggered by the agent's own assessment that its output is unsatisfactory or that an executed action failed to produce the expected state change. This creates a closed-loop system: Act -> Evaluate -> Detect Gap -> Repair -> Act.

• Dependency: Effective repair requires accurate error detection and classification from the evaluation module.
• Output: The result is often a revised execution graph or an updated plan that mutates the original action sequence.

The repair process is not performed in a vacuum. It must be context-aware, incorporating the full operational context, including:

• The original user intent and constraints.
• The history of actions already taken and their effects.
• The current state of external systems and APIs.
• Remaining resources (e.g., time, token budget).

This awareness prevents the agent from proposing repairs that are logically sound but contextually invalid, such as repeating an action that failed due to a persistent external outage.

A key differentiator from basic step retry logic is that goal-directed repair involves reasoning and plan modification. A simple retry re-executes the same action, often with a delay or minor parameter tweak. Goal-directed repair analyzes why the current plan failed and synthesizes a different subsequent plan.

• Retry: "The API call timed out. Wait 2 seconds and call the same endpoint again."
• Goal-Directed Repair: "The API call failed authentication. The goal is to fetch user data. Alternative path: Retrieve a new token from the auth service, then call the endpoint."

The real-time modification of an autonomous agent's sequence of actions or tool calls in response to errors, changing conditions, or new information during execution. Unlike static planning, this involves:

• Continuous monitoring of the environment and action outcomes.
• Triggering a replanning cycle when the current plan becomes infeasible.
• Generating a new plan from the current state, not the initial state. This is the overarching process within which goal-directed repair operates.

The process of modifying a partially executed or failed plan to achieve the original goal, often by substituting actions, reordering steps, or relaxing constraints. It is a specific instance of dynamic replanning focused on fixing, not fully regenerating, a plan. Key techniques include:

• Splicing: Replacing a failed action sequence with a new, validated sub-plan.
• Reordering: Changing the sequence of pending actions to resolve resource conflicts.
• Constraint Relaxation: Temporarily loosening a non-critical goal requirement to find a feasible solution.

An algorithmic approach to error recovery where an agent systematically reverses recent decisions (backtracks) to a prior choice point and explores alternative execution paths. This is a foundational search strategy for implementing goal-directed repair.

• The agent maintains a search tree of executed actions and decision points.
• Upon failure, it backtracks to the most recent node with unexplored alternatives.
• It then proceeds down a new branch, effectively "rewinding" and trying a different path. This method ensures systematic exploration of the solution space but can be computationally expensive.

A flexible planning paradigm where actions are arranged with only necessary sequencing constraints, allowing for dynamic reordering and parallel execution during runtime adaptation. This architecture is highly amenable to goal-directed repair.

• Plans are represented as a graph of actions with causal links (this action provides a precondition for that one).
• Actions without strict dependencies can be executed in any order.
• When an action fails, repair can often be achieved by re-satisfying the violated causal link through a different action or sequence, without a complete plan rewrite.

An operation specifically designed to semantically undo or counteract the effects of a previously executed action, enabling forward recovery. This is critical for goal-directed repair in systems that cannot rollback (e.g., those that have performed irreversible external actions).

• Not a simple database rollback. It is a business-logic-aware correction (e.g., "issue a refund" compensates for "charge credit card").
• Used in long-running, distributed transactions as part of the Saga pattern.
• In goal-directed repair, identifying and executing a compensating action may be the first step to reset the state before attempting a new path to the goal.

A fault-tolerant strategy where an autonomous system switches to a predefined alternative action or workflow when a primary operation fails or exceeds performance thresholds. This is a simpler, more deterministic form of execution path adjustment compared to full goal-directed repair.

• Pre-computed alternatives are defined during system design for known failure modes.
• Examples include using a cached response, calling a different API endpoint, or using a less accurate but more reliable model (model cascading).
• It provides fast recovery but lacks the generative flexibility of goal-directed repair for novel failures.