Repository navigation
[FEATURE] Add bounded parallel evidence gathering to the ReAct agent #6030
Description
Activity
Suggested technical design
Loadingflowchart TD A[User asks a diagnostic question] --> B[OpenSRE identifies the evidence it needs] B --> C{Can checks run independently?} C -->|Yes| D[Run safe checks together within a limit] C -->|No| E[Wait for the required evidence] D --> F[Keep successful results] D --> G[Record failures and timeouts] E --> H[Run dependent checks] F --> H G --> H H --> I[Combine results with source and status] I --> J[Explain the findings and any missing evidence]In short: gather independent evidence concurrently, preserve useful partial results, then run checks that depend on what was found.
Existing foundation and actual gap
OpenSRE already has useful batch-level parallelism:
core/tool/execution.pyruns a provider-returned batch concurrently when every tool is parallel-safe, preserves provider order, and returns per-call errors.- Tool metadata already exposes
parallel_safe,execution_mode, andside_effect_level. core/agent/react_loop.pyrecords and observes each tool result.
The missing capability is coordination across more than one tool-call batch: explicit dependencies, a per-turn concurrency budget, branch deadlines and cancellation, and a merged provenance/partial-failure view. This proposal should build on the existing executor rather than introduce a second executor.
Execution model
Use a small evidence plan owned by the current agent turn:
- plan id and revision;
- branch id and evidence objective;
- registered tool call and validated arguments;
- dependency branch ids;
- timeout/budget;
- status: pending, running, succeeded, failed, timed out, cancelled, or skipped.
Treat the plan as a levelled DAG. On each wave:
- select branches whose dependencies have completed successfully;
- validate the referenced tools through the normal registry and execution hooks;
- admit only tools declared parallel-safe and non-mutating;
- execute up to the host's remaining concurrency capacity;
- record every outcome before scheduling the next wave;
- return the merged evidence to the same ReAct loop for synthesis or follow-up.
A failed prerequisite should mark dependent branches as skipped with a reason. Independent branches should continue.
Keep planning simple
The current ReAct model should produce the evidence plan; do not add a second planner model or an autonomous sub-agent hierarchy for the MVP. A small internal orchestration tool or structured host request can validate the plan, but nested calls must still pass through the central tool registry, authorization hooks, input validation, tracing, and circuit breakers.
Do not overload the existing sequential
TaskPlan, whose singlein_progressstep is user-facing progress state. Evidence-branch state is execution detail and should have its own focused model.Provenance and merge contract
Extend the existing structured tool result metadata rather than parsing rendered prose. Each merged branch result should retain:
- branch and tool-call ids;
- tool name, integration/source id, and evidence type;
- start/end time and duration;
- dependency ids;
- success, failure, timeout, cancellation, or skip status;
- bounded result content and safe error category.
Merge in declared branch order, not completion order, so prompts, recordings, and tests remain deterministic. Successful results must remain available when sibling branches fail.
Concurrency, timeout, and cancellation
- Apply both a per-plan branch cap and the existing host/process concurrency budget.
- Never create an unbounded executor per branch or per turn.
- Stop scheduling new waves as soon as cancellation is requested.
- Propagate cooperative cancellation and deadlines to tools that support them.
- Ignore late results after the turn is cancelled; they must not update session state or trigger follow-up actions.
- Require provider tools to enforce their own network timeouts because Python worker threads cannot safely terminate an arbitrary blocking call.
Safety
Parallel waves are for evidence gathering, not speculative mutation. A branch is eligible only when its resolved tool contract is parallel-safe and its
side_effect_levelisnoneorread_only. Missing side-effect metadata should fail closed for this path.A plan must not:
- bypass execution hooks, authorization, approvals, or tool input validation;
- run two stateful calls concurrently;
- leak evidence across repositories, sessions, actors, or gateway channels;
- treat a failed tool response as evidence that a goal was achieved;
- let tool output inject new branches without another validated model/host step.
MVP phases
- Add evidence-plan contracts, validation, deterministic wave scheduling, and tests with fake tools.
- Integrate the scheduler with
execute_tool_calls, existing tracing, evidence compaction, and cancellation. - Add user-visible progress and a compact partial-failure/provenance summary.
- Add scenario coverage for CI logs + deploy state + metrics + commits, including one slow source and one failed dependency.
- Measure wall-clock reduction, peak concurrency, completion rate, and partial-result retention in the roadmap scorecard.
Verification scenarios
- Four independent reads with a limit of two never exceed two concurrent calls.
- A dependent branch starts only after all declared prerequisites succeed.
- A cycle, unknown dependency, duplicate id, excessive branch count, or unknown tool is rejected before execution.
- A mixed plan containing a mutating or sequential tool cannot run that tool in parallel.
- One timeout preserves successful sibling results and visibly skips dependants.
- User cancellation prevents queued branches and late state updates.
- Results are merged in declared order even when completion order differs.
- Repository/session scope remains isolated under simultaneous turns.
- Existing single-call and same-batch tool behavior remains unchanged.
Non-goals for the first release
- Restoring the former investigation/RCA pipeline.
- General-purpose workflow orchestration.
- Parallel remediation or deployment changes.
- Recursive agent spawning or long-lived sub-agent conversations.
- Distributed execution across hosts.
Related roadmap proposals: #6026 for provider-neutral CI health and #6027 for runbook-guided evidence gathering.
Hi @muddlebee, I’d like to take ownership of #6030.
I’ve gone through the full issue and the technical design, including the evidence-plan/DAG flow, the existing
core/tool/execution.pybatch parallelism,parallel_safe/execution_mode/side_effect_level, deterministic result ordering, dependency handling, cancellation, and the safety constraints.I’d like to start with MVP Phase 1: implement the evidence-plan contracts, validation, deterministic wave scheduling, and focused tests with fake tools. I’ll keep it scoped to the current ReAct architecture and build on the existing tool executor rather than introducing a separate execution system.
I’ll make sure the tests cover concurrency limits, dependency ordering, invalid/cyclic plans, failed prerequisites, non-parallel-safe tools, deterministic merge ordering, and cancellation behavior. After that, I can continue with the integration phase based on your review.
Could you please assign #6030 to me? I’ll work on it in a focused branch and link the PR back to this issue.
Problem statement
OpenSRE should gather independent evidence sources in parallel and combine them into one traceable result.
Today, parallel-safe tools can run together only when the model emits them in the same tool-call batch. A diagnostic turn cannot represent a bounded, multi-step evidence plan where independent checks run together, dependent checks wait, and every branch has a visible outcome. CI logs, deployment state, metrics, and recent commits can therefore require avoidable serial round trips, while one slow or failed source obscures the useful evidence returned by others.
Proposed solution
Add bounded parallel evidence branches to the current ReAct agent. The agent should group independent read-only checks into parallel waves, execute them through the existing tool runner, and merge results deterministically with source, timing, and success/failure provenance.
For example, a CI diagnosis could fetch failed-job logs, deployment state, service metrics, and recent commits concurrently, then run a dependent comparison after those results arrive.
Success criteria