Agent-to-Agent CONDUIT

CONDUIT is the wiring protocol that moves products from creation to consumption across three systems: Creator Engine, CLI, and Marketplace API. For agents, CONDUIT is not just a publishing pipeline — it is the discovery and installation backbone that makes agent-to-agent workflows possible.

What is CONDUIT?

CONDUIT defines how a product travels from a creator's workspace to an agent's context window. The protocol spans 28 wiring points (WP-1 through WP-28) across three boundaries.

Creator Engine          CLI                    Marketplace
─────────────          ───                    ───────────
Scaffold product  →  Read vault.yaml    →  Validate payload
Build content     →  Collect + scan     →  Persist to Firestore
Validate MCS      →  Pack + upload      →  Index for search
Generate manifest →  Call API           →  Serve to agents
                                           ↓
                              Agent discovers via search/MCP
                              Agent reads context payload
                              Agent installs via CLI
                              Agent consumes product files

The key insight: CONDUIT was designed so that every boundary can be crossed by an agent without human intervention. The CLI accepts --json on all commands. The API returns structured responses. The manifest (vault.yaml) is machine-readable YAML.

For the full publishing protocol from a creator's perspective, see CONDUIT Publishing Protocol.

The 5-level agent stack

Agents consume MyClaude content through five levels, ordered from highest abstraction to raw content. Each level serves a different context budget and task complexity.

An agent that needs to answer "what is MyClaude?" reads L5. An agent that needs to install a product for a user reads L4 (buyer context payload) and L2 (CLI commands spec). An agent building a product reads L1 (the full publishing guide).

For details on each level's entry points, see Agent Integration Overview.

How agents discover and install products

Agent-driven discovery follows a three-step pattern: search, evaluate, install. Every step is available as both a CLI command (with --json output) and a REST API call.

# Step 1: Search
myclaude search "code review" --category skills --json
# Returns: array of {name, slug, category, price, downloads, mcsLevel}

# Step 2: Evaluate
myclaude info @securitydev/code-review-skill --json
# Returns: full product metadata including version, license, tags

# Step 3: Install
myclaude install @securitydev/code-review-skill --json
# Returns: {installed: true, path: ".claude/skills/code-review-skill", version: "1.2.0"}

The --json flag is the agent's interface. Every CLI command outputs structured JSON when this flag is present, making output parseable without regex or string matching.

Agent consumption patterns

Context payloads

Context payloads are ~500-token YAML files designed for system prompt injection. An agent loads a payload and gains working knowledge of MyClaude's categories, CLI commands, pricing, and terminology — without consuming 30,000 tokens of full documentation.

Three payload types exist: marketplace.yaml (general platform), creator.yaml (publishing workflow), buyer.yaml (discovery and installation). Served from /specs/context/.

See Context Payloads for the full specification and examples.

MCP tool schemas

MyClaude exposes marketplace operations as MCP tools defined at /specs/mcp-tools.json. An MCP client (such as Claude Code) discovers these tools automatically and can invoke myclaude_search, myclaude_install, myclaude_info, and others without constructing HTTP requests.

Products can also declare their own MCP tools in vault.yaml under the config.mcp_tools field. When installed, these tools become available in Claude Code's tool inventory.

See MCP Tool Schemas for the complete tool definitions.

Structured CLI output

Every myclaude CLI command supports --json for machine consumption. This means an agent orchestrating a workflow can parse install results, search responses, and validation output programmatically.

Building agent-aware products

Products that agents can discover and reason about effectively include two fields in vault.yaml:

# vault.yaml — agent-aware fields
name: code-review-skill
version: 1.2.0
category: skills
description: "Automated code review with security focus."
agent_summary: "Reviews code for security vulns. Input: file path. Output: findings list."
agent_spec:
  inputs: [file_path, focus_area]
  outputs: [findings, severity, suggestions]
  side_effects: none
  context_budget: 800

The agent_summary appears in search results and docs-index.json. Agents use it to decide relevance without fetching the full product page. Write it as an imperative statement of what the product does, not a marketing pitch.

The agent_spec helps orchestrating agents decide whether a product fits their workflow constraints. A product that declares side_effects: none and context_budget: 800 tells the agent it is safe to invoke in a pipeline and will not blow the context window.

MCP integration

MyClaude operates as an MCP server for Claude Code. This means Claude Code can interact with the marketplace — searching, installing, validating — through native tool calls rather than shell commands.

Claude Code session
  ├── User asks: "Find me a code review skill"
  ├── Agent selects: myclaude_search tool
  ├── MCP runtime: calls MyClaude API
  ├── Result: [{name: "code-review-skill", ...}]
  ├── Agent selects: myclaude_install tool
  ├── MCP runtime: installs via CLI
  └── Product files now in .claude/skills/

The MCP layer is an ergonomic bridge over the REST API. Agents that already use the API directly do not need it. The benefit is integration with Claude Code's native tool-calling interface — no HTTP construction, no auth header management.

Future: agent-to-agent marketplace transactions

The current CONDUIT pipeline assumes a human creator publishes and a human or agent buyer consumes. The next evolution is agent-to-agent transactions: an agent that identifies a capability gap searches the marketplace, evaluates options, purchases the best fit, and installs it — all within a single session.

This requires three capabilities that CONDUIT already supports in principle:

1. Programmatic discovery — myclaude_search MCP tool or --json CLI output.
2. Automated evaluation — agent_summary and agent_spec provide machine-readable quality signals.
3. Unattended installation — myclaude install with --json returns structured success/failure.

The missing piece is programmatic purchasing for paid products. Today, myclaude install for paid products opens a Stripe Checkout in the browser. Agent-to-agent purchasing will require a headless checkout flow — a planned extension to the CONDUIT protocol.

Related pages

• Agent Integration Overview — entry points and the PRISM architecture
• MCP Tool Schemas — MCP tool definitions and consumption patterns
• Context Payloads — pre-packaged YAML for bootstrapping agent knowledge
• CONDUIT Publishing Protocol — the creator-facing pipeline reference