How K9X Studio Is Built
K9X Studio doesn't just help you design K9-AIF architectures — it is one.
The studio runs pip install k9-aif to pull in the published
k9_aif_abb framework package, and builds directly on its base
classes — BaseRouter, BaseOrchestrator,
BaseAgent, BaseSquad — rather than reimplementing them.
The studio's own router and agent layers, studio_core and
studio_agents, extend that framework with the studio-specific
mechanics it needs — event routing and parallel sub-agent spawning.
The spec-import flow you use to upload a doc and get a canvas is a real K9-AIF
squad, not ad-hoc service code: GovernanceAgent screens the
document, then SpecParserAgent spawns three sub-agents in parallel —
project info, agent table, zone mapping — via K9SubAgentSpawner
(mechanics-only ABB, ThreadPoolExecutor-based), and
LLMGroupingAgent → ScoringAgent →
CanvasBuilderAgent turn the merged results into the canvas
suggestion — all defined declaratively in
squads/yaml/spec_import_squad.yaml.
The Flow, Top to Bottom
The Intake tab is where a project starts — you can upload a spec doc, upload a BPMN export, or just describe the project and let the studio suggest an architecture. All three land at FastAPI; the diagram below follows the spec-doc path, since that's the one rebuilt as a real K9-AIF squad — from the browser, through the router and orchestrator, into the squad, and back to the canvas:
The Class Architecture
The same flow, broken down by class — what extends what, and which pieces come from the framework versus the studio's own code:
k9_aif_abb — pip-installed framework package (k9-aif>=1.2.6)
studio_core / studio_agents — the studio's own SBB/ABB extensions
application code — orchestrators, agents, squads
