Feature Summary
Building a workflow today requires knowing the operator catalog well enough to pick the next operator by name. The existing chatbot helps, but only on demand — the user has to stop and ask. There is no ambient guidance at the moment of authoring.
This proposes an ambient operator recommender: after an operator is added to the canvas, 1–3 faded "ghost" operators appear on its output port showing the most likely next operators. Clicking one materializes it and wires the link. It behaves like code-completion ghost text, but for dataflow graphs — predictive and non-intrusive, never blocking the user.
Design was discussed and agreed in #5240.
|
Existing chatbot |
Operator recommender |
| Trigger |
User asks |
Operator added to canvas |
| Mode |
Conversational |
Ambient, ranked ghosts |
| Cost |
LLM call per turn |
Zero in V1; small model in V2 |
Proposed Solution or Design
Ship in two versions, as agreed in #5240 (zuozhiw: "the plan sounds good, please go ahead with first steps"; xuang7: V1 needs no LLM call, "default configuration should be sufficient").
V1 — hardcoded, zero API cost. Validates the whole pipeline before spending anything on inference.
canvas: operator added
│ getOperatorAddStream()
▼
frontend hook ──POST /api/recommend──► agent-service (stateless)
◄──── ranked suggestions ───── hardcoded rule table
│ + operator catalog validation
▼
1–3 ghost operators on output port ──click──► materialize + link
POST /api/recommend in agent-service: stateless, no DB, no LLM, no user token.- Ranks from a small hardcoded successor table keyed on the real operator catalog.
- Suggestions validated against the live catalog (
WorkflowSystemMetadata), so a stale rule degrades to "not suggested" rather than a broken ghost.
- Response carries a
strategy discriminator ("hardcoded" / "llm") so V2 swaps in behind the same request/response shape, no breaking change.
- Frontend ghost rendering gated behind a new opt-in GUI config flag, default off.
V2 — LLM-backed ranking. After community feedback on V1.
Scope of this issue is V1 only, split into two PRs:
| PR |
Scope |
| 1 |
agent-service: stateless POST /api/recommend, hardcoded ranking, catalog validation, unit + route tests |
| 2 |
frontend: subscribe to operator-added events, ghost rendering on output port, click-to-materialize, opt-in config flag |
V2 will be tracked as a follow-up issue.
Affected Area
Workflow UI, Other
Feature Summary
Building a workflow today requires knowing the operator catalog well enough to pick the next operator by name. The existing chatbot helps, but only on demand — the user has to stop and ask. There is no ambient guidance at the moment of authoring.
This proposes an ambient operator recommender: after an operator is added to the canvas, 1–3 faded "ghost" operators appear on its output port showing the most likely next operators. Clicking one materializes it and wires the link. It behaves like code-completion ghost text, but for dataflow graphs — predictive and non-intrusive, never blocking the user.
Design was discussed and agreed in #5240.
Proposed Solution or Design
Ship in two versions, as agreed in #5240 (zuozhiw: "the plan sounds good, please go ahead with first steps"; xuang7: V1 needs no LLM call, "default configuration should be sufficient").
V1 — hardcoded, zero API cost. Validates the whole pipeline before spending anything on inference.
POST /api/recommendinagent-service: stateless, no DB, no LLM, no user token.WorkflowSystemMetadata), so a stale rule degrades to "not suggested" rather than a broken ghost.strategydiscriminator ("hardcoded"/"llm") so V2 swaps in behind the same request/response shape, no breaking change.V2 — LLM-backed ranking. After community feedback on V1.
Scope of this issue is V1 only, split into two PRs:
agent-service: statelessPOST /api/recommend, hardcoded ranking, catalog validation, unit + route testsfrontend: subscribe to operator-added events, ghost rendering on output port, click-to-materialize, opt-in config flagV2 will be tracked as a follow-up issue.
Affected Area
Workflow UI, Other