AI Ecosystem Inventory Map

c21.ai-session-map proved that qmap can make one agent session legible. What we do not have yet is the company-wide inventory view: a listing/index surface that answers a broader question:

Which agents were active in this timeframe, what repos and files are they touching, and what MCP servers, tools, and sub-agents make up that working ecosystem?

That is not just a larger version of c21. The structure is different:

• multiple active agents instead of one focal session
• repositories as first-class nodes between agents and files
• files that need to read as nested under repos
• tools and sub-agents that should stay distinct in the mental model even if they share a mesh family
• stress cases that are much denser than the current synthetic session fixtures

This cycle exists in design because the current workspace can safely hold the planning artifacts and synthetic dataset contract even though the implementation should happen in qmap.

Capture the implementation plan for a new qmap cycle that introduces:

• a dedicated inventory/index wrapper component for qmap
• a deterministic synthetic dataset suite covering tiny demo and large enterprise conditions
• a graph contract that can express agents, repositories, files, MCP servers, tools, and sub-agents without requiring immediate new qmap mesh types

In:

• planning artifacts in cycles/c43.ai-ecosystem-inventory-map/
• deterministic synthetic data in app/data/qmap-ai-ecosystem-inventory.ts
• proposed qmap wrapper contract, grouping modes, and scenario matrix

Out for now:

• editing the sibling qmap repo from this workspace
• adding a design-site route for the inventory map
• committing to new qmap mesh types before the wrapper is proven
• wiring live production data

• CYCLE.md
• execution-plan.md
• initial-prompt.md
• app/data/qmap-ai-ecosystem-inventory.ts

This cycle now defines the implementation shape and synthetic test contract for the future qmap work. The next coding step should happen in qmap as a new implementation cycle, using these artifacts as the starting brief.

Recommended qmap cycle:

• c25.ai-ecosystem-inventory-map

Recommended initial wrapper:

• src/components/QMapInventoryIndex.vue

Recommended experiment surface:

• dev/experiments/c25.ai-ecosystem-inventory-map/

The first pass should stay compatible with qmap's existing actor types.

Recommended mapping:

• AI Agents -> agent
• Repositories -> app
• Files -> file
• MCP Servers -> mcp-server
• Tools -> skill
• Sub-Agents -> skill

Entity meaning should be carried by tags, not new meshes, for the first implementation:

• entityType: 'AI Agent' | 'Repository' | 'File' | 'MCP Server' | 'Tool' | 'Sub-Agent'

Important consequence:

• tools and sub-agents can be visually separated by grouping and label copy before we decide whether qmap needs a dedicated tool or sub-agent mesh family
• repositories can be tested as app actors before introducing a dedicated repository mesh

The wrapper should accept an inventory-shaped object and emit normal qmap actors/dataflows internally.

Suggested public shape:

{
  timeframeLabel: string,
  actors: Actor[],
  dataflows: Dataflow[],
  stats: {
    activeAgents: number,
    repositories: number,
    files: number,
    mcpServers: number,
    tools: number,
    subAgents: number,
  },
  meta: {
    scenarioId: string,
    summary: string,
  },
}

The key is to keep the wrapper consumer-facing and semantic, while still reducing to standard qmap primitives.

The first experiment should validate at least these modes:

• Entity Type -> level1: 'entityType'
• Repository -> level1: 'entityType', level2: 'repo'
• Team -> level1: 'team'
• Business Unit -> level1: 'businessUnit'
• Flat -> {}

Repository mode is the critical one for this cycle because it tests whether files can read as subordinate to repos without needing a bespoke nested rendering system.

1. Is a dedicated QMapInventoryIndex wrapper enough, or does the inventory view need qmap-level layout affordances that current wrappers do not expose?
2. Can repository -> file relationships stay legible in a dense multi-agent map without introducing a third grouping depth?
3. Are tools and sub-agents distinguishable enough when both are represented as skill actors plus tags?
4. At what scale do repository/file-heavy scenes need summarization, filtering, or aggregation?
5. Which synthetic scenarios should become the long-term regression harness for this view?