Parallel sub-agent strategy for execute stage

Open
  • Is something wrong?
#77 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
go
Domain
ai-infra-agents, backend

Research direction

Start with parent issue #57 and related issue #54, then trace the execute stage, implementation.md steps, and the AgentRun or harness/controller entry point mentioned here. Compare the proposed parallelism and failure-handling options, and define the orchestration, conflict, and partial-failure behavior needed for a complete implementation.

Written by the indexing model from the issue text.

Description

enhancement stream/harness

Context

Split from #57. The execute stage currently processes plan steps sequentially. For large migrations (50+ steps), parallel sub-agents could significantly reduce execution time.

Problem

Each plan step (or group of steps) could run as a separate sub-agent. Each sub-agent handles one step from implementation.md — reads the target file, applies transformations, writes it back.

Sub-agents working in parallel need a git merge strategy. Several approaches exist, each with trade-offs:

Option A: Disjoint files on the same branch

Steps in implementation.md are one-file-per-step, so conflicts are unlikely if steps are partitioned correctly. Sub-agents claim non-overlapping file sets and commit directly to the migration branch.

Pros: Simple, no merge step, natural commit history
Cons: Shared files (pom.xml, application.properties, config files) are touched by multiple phases — these must be serialized or handled specially

Option B: Branch-per-sub-agent

Each sub-agent works on a separate branch. Results are merged back into the main migration branch after all sub-agents in a phase complete.

Pros: Full isolation, no conflicts during execution
Cons: Merge conflicts possible (especially config files), complex merge orchestration, noisy git history

Option C: Phase-level parallelism only

Steps within a phase run in parallel (they typically touch disjoint files). Phases remain sequential (build gate enforces this anyway). Shared config files (pom.xml, application.properties) are handled by a dedicated "config step" at the start of each phase, before sub-agents fan out.

Pros: Leverages the existing phase structure, build gates remain sequential, shared files handled deterministically
Cons: Limited parallelism (only within a phase, not across phases)

Open questions

  • How does the sub-agent strategy interact with context window limits? (Sub-agents get a fresh context per step)
  • How are merge conflicts resolved if two steps touch the same file? (e.g. both adding imports to the same Java file)
  • Should the orchestration live in the skill (goose sub-agents) or in the harness/controller (AgentRun per step)?
  • How does partial failure work — if 3 of 10 sub-agents fail, do we abort the phase or commit the successful ones?

References

  • Parent: #57
  • Related: #54
Dominant language
Go
Stars
5
Forks
13
Avg merge
3d 11h
Merged PRs (30d)
41

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from konveyor/agentic-controller

All issues in konveyor/agentic-controller

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.