Managing Reasoning Runs

ReActCore gives its subclasses explicit run handles. A handle identifies one solve, so concurrent solves do not share a single current-run slot. These APIs are available in ASTRA 2.8.1.

Inspect the outcome

Inside an agent extending a ReAct strategy, use:

ReasoningRun run = runs.create();
!solveRun(run, question, string answer, string outcome);
console.println("Outcome: " + outcome);
console.println(runs.diagnostics(run));

Import astra.langchain4j.reasoning.* in the source file. Initialize the model and tools before this fragment.

Outcome	Meaning
completed	The strategy produced a final answer. This does not certify its correctness or external effects.
exhausted	The turn limit was reached, or a structured conversation could not fit its context budget.
failed	Preparation, reasoning or cleanup failed.
cancelled	The run observed a cancellation request.

The existing !solve(question, answer) remains available. It propagates failed and cancelled outcomes through native goal failure; exhaustion still returns an exhaustion answer. Use !solveRun when the caller must branch on the outcome explicitly.

Bound work and request cancellation

maxSteps(int) bounds model turns; it is not a token allowance, a wall-clock deadline or a limit on the number of external effects. A structured model response can request several tools in one turn, and ReActTools processes those calls sequentially.

Call runs.cancel(run) from another intention to request cancellation. Turn control checks it before starting the next turn. It does not itself interrupt an in-flight model request or undo a tool action. Protocol adapters have their own deadline and cancellation operations.

Diagnose failures

runs.diagnostics(run) returns bounded diagnostics containing the failure stage and root exception. Stages include preparation, a turn, retention and cleanup. A successful solve can still have a retention failure: inspect runs.retentionFailed(run) separately from the solve outcome.

When investigating a run, record its ID (runs.id(run)), outcome, diagnostics and relevant tool results. Use the GUI history to follow native intentions. Keep model responses and tool observations available in the application’s own diagnostic records when they are needed to explain the decision.

A tool error may become an observation and allow reasoning to continue. An exhausted run may contain successful tool actions. Check external state before retrying a task whose actions have side effects.