Spike: human-in-the-loop planning stage — interrogate the application before planning

Open
  • Is something wrong?
#253 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@ibolton336 is already working on this.

Since Oct 5, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend

Research direction

Start by inventorying Hub questionnaires and reviewing harness/experiments/skills/questionnaire/SKILL.md. Prototype analysis through ask_user or the ACP elicitation path, then assess how answers can be persisted and whether turn blocking supports multiple questions. Done means a findings write-up, a generic/domain-specific seam recommendation, and a follow-up issue if the stage should be implemented.

Written by the indexing model from the issue text.

Description

enhancement kind/research ready-for-human stream/controller stream/harness

Context

Today a workflow run goes straight from analysis to plan: the harness writes
.konveyor/analysis.json, and the plan stage turns it into docs/plan.md
without a human in the loop. The only human interaction available mid-run is
ask_user (ADR 0017), which the agent reaches for opportunistically inside a
turn rather than as a deliberate step.

We want a planning step where a human is a first-class participant: analysis
runs, then the agent uses the skills loaded for it to interrogate a human about
what should happen to this application, and the answers are persisted as a
plan and/or as architectural decision records before any code is touched.

This matters beyond better plans. The answers to "what is this application, what
constrains it, and where is it going" are exactly the decisions a team wants
written down — and they are the input that makes the artifacts in
ADRs in the target repository worth writing.

Open question: where the generic/domain-specific seam goes

This spike must produce a position on a question it does not currently answer:
which of these concepts are first-class in the agentic controller, and which
belong to a harness above it?

Konveyor already has questionnaires in Hub. An interrogation stage could:

  • read Hub's existing questionnaires, making the concept Konveyor-specific and
    the harness the place it lives; or
  • define an interrogation/decision concept in the controller itself, with
    Konveyor's questionnaires as one source among several; or
  • live in a non-Konveyor-specific harness layer that sits above the
    Konveyor-specific one, so the capability is reusable but the controller stays
    uninterested in it.

The third option implies a harness layering we do not have today. Whatever the
recommendation, it also constrains
ADRs in the target repository and
skills in the target repository, so those
issues should reference this one's outcome rather than re-deriving it.

Timeboxed tasks

  • Inventory what Hub's questionnaires actually provide (schema, API, how the
    assessment module uses them) and whether their content is usable as agent
    input without reshaping.
  • Evaluate harness/experiments/skills/questionnaire/SKILL.md — it was
    written for roughly this purpose and never shipped. Say whether it is a
    starting point or a dead end, and why.
  • Prototype one interrogation pass against a real application: analysis →
    questions to a human via the existing ask_user / ACP elicitation path →
    persisted answers. A throwaway branch is fine.
  • Determine whether the existing ask_user turn-blocking model is adequate
    for a multi-question interrogation, or whether a distinct stage type is
    needed. Note that ask_user fails closed with no viewer attached, which
    makes an interrogation stage unrunnable headlessly — decide whether that is
    correct or needs an escape hatch.
  • Write the seam recommendation described above.

Deliverables

  • A findings write-up covering the prototype and the questionnaire evaluation.
  • A recommendation on the generic/domain-specific seam, to be promoted to an ADR
    if accepted.
  • If "carry it": a follow-up issue for the stage implementation.

Out of scope

Dominant language
Go
Stars
5
Forks
13
Avg merge
3d 6h
Merged PRs (30d)
47

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.