Replies: 2 comments
|
The piece that tends to get glossed over in these tool-fit conversations is what actually owns the state. If the mapping is skill-per-column plus a "Message to agent" prompt string, then swapping the board means rewriting every column config and re-pasting every prompt, and the methodology layer has quietly become captive to one tool's UI. We hit this building MeshKore, and it pushed us toward a different seam: a shared, repo-resident task-state contract. Markdown files per ticket carrying id and status as frontmatter, sitting in a folder the agents actually read and write. The visual board becomes a projection, something that scans those files and renders them, and the question "which tool fits" turns into "any tool that can read and write that state." The board can be swapped without losing anything, because the contract lives in the repo, not in a prompt box. Kangentic looks decent, but I would treat the integration point as that file contract rather than its column-to-skill mapping. Unanchored work that never lands in the state files is effectively invisible, which is a feature, it forces the task state to be real. So the real question might not be which visual orchestrator, but whether both tools can agree on a slice of disk as the source of truth. That makes the whole board layer an implementation detail. |
|
Thanks --- the "repository as the source of truth, UI as a I tried to follow that idea further, especially around one question:
Below is the reasoning that led me to a slightly different integration 1. Repository-resident workflow is a good starting pointI agree with the core principle that the methodology/workflow should If the only representation is: then Kangentic effectively becomes the owner of part of the methodology. Having an AIDD-side representation of the intended workflow would For example: That representation could describe:
2. But an AIDD-specific format alone does not make UIs interchangeableThis is where I see a limitation in making the repository contract If AIDD defines its own task/workflow/state format, another UI can We would move from: to: This is better in some respects, but it is not general For a truly portable contract, multiple independent orchestrators would 3. Could an existing standard solve this?I looked at a few possible building blocks. A2AInteresting for: agent capability discovery, Agent Cards and Agent Limitation here: AIDD is not really an A2A agent today. Using A2A as Open Workflow SpecificationInteresting for: vendor-neutral workflow definitions. Limitation here: adopting a workflow specification on the AIDD side MCPInteresting for: tool discovery and invocation. Limitation here: MCP is a useful integration/control mechanism, but These are useful building blocks, but none seems to solve the complete Even if AIDD adopted one of these standards:
So adopting a standard only on the AIDD side does not give us It also feels disproportionate to introduce a new protocol/runtime layer 4. Alternative: AIDD owns the desired workflow, adapters own the translationThis led me to another model. Instead of requiring every orchestrator to understand AIDD, AIDD could Then orchestrator-specific adapters materialize that workflow into each flowchart TD
A["AIDD workflow<br/>Source of truth"]
A --> K["Kangentic adapter"]
A --> C["cc-wf adapter"]
A --> O["Other adapter"]
K --> KM["MCP / Config / CLI"]
C --> CF["Config / API"]
O --> OM["REST / SDK / Other"]
KM --> KR["Kangentic runtime"]
CF --> CR["cc-wf runtime"]
OM --> OR["Other runtime"]
The important difference is:
This is not universal portability through a shared standard. It is 5. Use whatever native integration mechanism the orchestrator exposesI don't think AIDD should require a particular integration technology. Different orchestrators may expose different control surfaces:
The adapter's responsibility would simply be:
For example: The adapter should therefore target the safest and most complete If an orchestrator cannot represent a particular AIDD concept, the For example: This also makes differences between orchestrators explicit instead of 6. Kangentic could be a good first experimentKangentic already exposes MCP capabilities for manipulating parts of its If its MCP surface provides enough primitives to create/configure the
Conceptually: flowchart LR
A["AIDD workflow"] --> V["Validate"]
V --> P["Plan changes"]
P --> H{"Human approval"}
H -->|Approve| M["Kangentic MCP / Config"]
H -->|Reject| A
M --> K["Native Kangentic workflow"]
K --> X["Verify"]
If some workflow configuration is better represented through Kangentic's Again, MCP is not the architecture. It is simply one possible 7. Prefer deterministic adapters where possibleThere are several possible levels of implementation. Option 1 --- Deterministic adapter/script (preferred)For example, an AIDD adapter skill could contain: The skill provides the integration knowledge and usage instructions, This should be preferred because:
Option 2 --- Script + skill/LLM assistanceSome parts of the mapping can remain deterministic while the LLM handles This can be a useful compromise when a fully deterministic adapter is Option 3 --- Pure skill/LLM translationNot every orchestrator will expose a sufficiently structured API or In that case, an AIDD skill could teach the coding agent:
The LLM then performs the translation. This is less deterministic and therefore less reliable, but it could So my preference would be: A new integration could even start as a skill-based prototype and 8. Keep the AIDD workflow semanticI don't think AIDD should try to model every runtime detail of every Something relatively small could be enough: stages:
- plan
- implement
- test
- review
transitions:
- plan -> implement
- implement -> test
- test.failed -> implement
- test.passed -> review
- review.rejected -> implement
- review.approved -> done
hitl:
plan:
approval_required: true
review:
approval_required: trueplus references to the appropriate AIDD capabilities/skills. The adapter decides how those concepts map to the target orchestrator. Responsibility splitAIDD - Owns methodology intent. - Owns the canonical Adapter - Translates/materializes AIDD intent into the target Orchestrator - Owns execution. - Owns runtime state. - Owns its This separation seems important: AIDD describes what the methodology 9. Avoid bidirectional synchronization initiallyI would avoid trying to solve this immediately: Full bidirectional synchronization brings back:
A much simpler initial model would be: Changes to the methodology happen in AIDD and are then reapplied to the The adapter could eventually support a Terraform-like lifecycle: For example: Workflow changes:
+ Add Security Review
~ Change Review → Implement transition
- Remove old Documentation stageThen the user approves the changes before they are applied. This provides a natural HITL safety boundary before modifying the user's 10. This does not rule out standards laterThis model does not compete with A2A, Open Workflow, MCP, or a future If a broadly adopted workflow standard eventually emerges and multiple At that point, several orchestrator-specific adapters could potentially But I would avoid making adoption of such a standard a prerequisite for Proposed directionThe architecture I would currently explore is:
For Kangentic, the first experiment could therefore be an AIDD
This seems to preserve the original repository-as-source-of-truth It also gives us an incremental path: without requiring either project to commit to a new interoperability Would this be closer to the separation of concerns you had in mind |
Uh oh!
There was an error while loading. Please reload this page.
Hello
I have been looking at several visual orchestration tools for AI coding agents, and although Kangentic is still a young project, it currently seems to me one of the most promising options.
I am not specifically attached to Kangentic though. If the AIDD maintainers or community know another visual orchestration tool that would fit AIDD better, I would be very interested in hearing about it.
What I find interesting is the potential complementarity:
Kangentic already provides:
AIDD already provides:
A Kangentic workflow could map naturally to AIDD skills, for example:
aidd-dev:01-planaidd-dev:02-implementaidd-dev:06-test/aidd-dev:03-assertaidd-dev:05-reviewaidd-dev:08-debugaidd-vcs:02-pull-requestThis can already be done today by installing both tools and configuring Kangentic's "Message to agent" field.
So perhaps no deep technical integration is needed at all.
A lightweight approach could simply be:
I also noticed the new
aidd-uiplugin. Since it is still at a very early stage, I wonder whether it could be useful to explore existing visual orchestration tools before building overlapping capabilities.This would remain entirely optional.
I do not think AIDD should depend on Kangentic or replace terminal-based workflows.
The idea would simply be:
There could also be a mutual ecosystem benefit:
Kangentic could remain framework-agnostic, and AIDD could remain orchestration-tool agnostic.
Would this kind of lightweight relationship fit AIDD's philosophy?
Would it make sense to:
All reactions