Kai Chat: multi-project context — cross-project comparison, migration assistant, and lineage root-cause tracing

[yustme]

Problem

Kai Chat is today scoped to exactly one project at a time. You pick a project in the top bar and the entire chat session — including Kai's tool calls — operates within that single project boundary.

This makes three common real-world workflows impossible or very painful:

1. Project migration — I need to compare two projects side by side: "Do both projects have the same table structure? What configs exist in the source but not in the target?"
2. Multi-project (layered) architecture — Data pipelines often span multiple projects in layers (L0 raw → L1 staging → L2 domain → L3 reporting). When a table in L3 breaks, I need to chase the root cause all the way back to L0 across project boundaries.
3. Shared data / bucket linking — Keboola supports cross-project bucket sharing. Kai has no visibility into which tables a project is consuming from another project and cannot reason about the full dependency graph.

Proposed solution

Option A — Multi-project context selector in Kai Chat (preferred)

Add a project selector to the Kai Chat UI that allows choosing 2 or more projects as context for the session. Kai would then have MCP / tool-call access to all selected projects simultaneously.

┌─────────────────────────────────────────────────┐
│  Context:  [b2b ×]  [b2b-staging ×]  [+ add]   │
│  ─────────────────────────────────────────────  │
│  > List all tables in b2b and compare them      │
│    with b2b-staging. Show what's missing in     │
│    staging.                                     │
└─────────────────────────────────────────────────┘

Kai answers using storage metadata, configs, and lineage from all selected projects.

Option B — Dedicated "Multi-project workspace" view

If multi-project Kai Chat is architecturally complex (Kai API may not support injecting context from multiple projects), a separate "Cross-project Agent" view could achieve the same outcome. It would expose a Claude/kbagent-powered chat that calls kbagent CLI commands across projects directly — bypassing the single-project Kai constraint.

kbagent CLI already runs most read commands across all registered projects in parallel (kbagent storage tables, kbagent search, etc.), so the data is available — it's purely a UI/UX gap.

Key use cases to support

1. Migration comparison

User: "Compare the Storage tables in project 'prod' vs 'prod-v2'.
       List tables that exist in prod but are missing in prod-v2."

Kai:  [calls storage tables on both projects]
      Tables in prod but missing in prod-v2:
      - out.c-reporting.customer_lifetime_value
      - out.c-finance.monthly_invoices
      ...

2. Cross-project root-cause tracing (L0 → L3)

User: "The table out.c-reporting.revenue_summary in L3 has wrong numbers
       since yesterday. Trace back through L2 and L1 to find where the
       data issue was introduced."

Kai:  [inspects L3 table lineage → finds source in L2 project]
      [inspects L2 → traces to L1 transformation config]
      [inspects L1 → finds a failed job in L0 yesterday at 03:14]
      Root cause: L0 project 'data-ingestion', config 'sfdc-orders',
      job 78123456 failed on 2026-05-13 at 03:14 with error: ...

3. Shared bucket awareness

User: "Which of my projects consume tables from the 'b2b' project
       via bucket sharing?"

Kai:  [inspects sharing links across all registered projects]
      Projects linked to b2b buckets:
      - pricing-automation → in.c-b2b-orders (shared from b2b)
      - controlling-finance → in.c-b2b-customers

Why this matters

kbagent already registers 16 projects and can query them all in parallel via the CLI. The MCP server exposes these tools. The missing piece is a chat interface where Kai (or a Claude-powered agent) can reason across project boundaries in a single conversation — maintaining context, correlating results, and tracing lineage end-to-end.

This would make kbagent genuinely useful for anyone running a multi-layer Keboola architecture, which is the standard pattern for any non-trivial data platform.

[padak]

Po review nebudeme implementovat — z těchto dvou důvodů:

1. Kai (Keboola AI) je per-project assistant: cross-project context, multi-project comparison ani lineage tracing není v Kai API a nemyslíme si, že by se tam v dohledné době dostal. Embedovaný Kai v kbagent serve drží zámek na single project, který odpovídá tomu, jak Kai API ve skutečnosti funguje.

2. Pro cross-project workflow má uživatel lokální Claude Code (nebo Codex/Gemini): kbagent CLI dává Claude full toolbelt přes kbagent context a všechny příkazy fungují multi-project (--project NAME, kbagent lineage build, kbagent search, atd.). "Migration assistant" a "lineage root-cause tracing" se v praxi dělají právě tímto směrem — uživatel řekne lokálnímu Claude "porovnej tyhle 3 projekty" a Claude si zavolá kbagent CLI tolikrát, kolikrát potřebuje. Žádný value-add pro duplikování toho v Kai chatu.

Closing as wontfix. Pokud potkáš konkrétní cross-project use case, kde lokální Claude nestačí, otevři issue zvlášť — řešením bude doplnit chybějící kbagent CLI příkaz, ne přidávat multi-project do Kai.