SkillsBus for Agents

The Idea

Right now, most agentic AI projects run into the same pain points: scattered endpoints, slightly different schemas for the same thing, memory that grows without real structure, and no easy way to see what actually happened in a flow. The idea behind a Skill Bus is to put a very small, opinionated layer in the middle and normalize all of that into capabilities, contracts, and policies a developer can reason about.

Instead of having agents call raw URLs, they call named capabilities like inventory.get_item or payments.create_invoice. The Skill Bus knows where those capabilities live, what their inputs and outputs look like, and what should be remembered or logged after each call.

Why This Matters

• Endpoint sprawl becomes reusable capabilities. You register something like finance.calculate_rate_card once. Every agent, every workflow, every script uses the same capability. If you need to add a new region, you update one place.
• Schema drift gets caught by contract testing and version pinning. An agent calls finance.calculate_rate_card 2.0.0 and knows exactly what input it needs to send and what it will get back.
• Memory stops being this gigantic context window stuffed with every conversation snippet. You say keep the decision rationale, keep the quote ID, discard the raw prompts, mask any personal info, and keep everything for a year. The system enforces it.
• Knowledge reliability goes up. Instead of embedding your whole knowledge base and letting similarity search take a stab at it, you rank sources. Company policy documents get weighted higher than a web search from three months ago. Citations become mandatory. The agent has to tell you where it got that information.
• Cross-vendor consistency improves because all the glue logic lives in one place. You can swap out a vendor, update the adapter, and the rest of the system just works.
• Governance at scale becomes feasible. You can see which capabilities are actually being used.

What the Skill Bus exposes

A minimal Skill Bus can be thought of as four simple surfaces:

• A catalog of capabilities with input and output schemas
• A registry of adapters that map capabilities to concrete systems
• A call endpoint that executes a capability with validation and routing
• An audit and memory surface that records what happened in a way humans can read later

A capability is just a JSON entry with a name, version, description, input schema, and output schema. You version it so old agents don't break when you add new fields. An adapter is a binding that says "this capability maps to this OpenAPI endpoint with this auth type and these environment rules." A memory policy says "for this capability, keep the decision rationale and the quote ID, discard raw prompts, mask PII, keep it for a year." A knowledge plan ranks your sources and says "policy docs are high trust, pricing tables are high trust, that external exchange rate API is medium trust."

A simple example of what a capability definition could look like in JSON:

{
  "name": "orders.create",
  "version": "1.0.0",
  "description": "Create a new order based on a list of items",
  "inputSchema": {
    "type": "object",
    "required": ["items", "currency"],
    "properties": {
      "items": {
        "type": "array",
        "items": {
          "type": "object",
          "required": ["id", "quantity"],
          "properties": {
            "id": { "type": "string" },
            "quantity": { "type": "number" }
          }
        }
      },
      "currency": {
        "type": "string"
      }
    }
  },
  "outputSchema": {
    "type": "object",
    "required": ["orderId", "status"],
    "properties": {
      "orderId": { "type": "string" },
      "status": { "type": "string" }
    }
  }
}

Capabilities are stable names and contracts. Adapters are where you connect those names to real systems.

Here is a simple adapter definition for the capability above:

{
  "capability": "orders.create",
  "environment": "prod",
  "backend": {
    "type": "rest",
    "baseUrl": "https://api.example.com",
    "path": "/v1/orders",
    "method": "POST",
    "auth": "bearer-token"
  },
  "timeoutMs": 5000,
  "idempotency": {
    "enabled": true,
    "keyFrom": ["items", "currency"]
  }
}

From the agent point of view, the call to the Skill Bus looks like this:

{
  "capability": "orders.create",
  "version": "1.0.0",
  "input": {
    "items": [
      { "id": "item-123", "quantity": 2 },
      { "id": "item-456", "quantity": 1 }
    ],
    "currency": "USD"
  },
  "correlationId": "abc-123"
}

The Skill Bus validates this payload against the input schema, derives an idempotency key if configured, chooses the right adapter for the environment, calls the backend, validates the response against the output schema, and returns the result to the agent.

Memory and audit details
The other thing that tends to get messy in real systems is memory. Instead of letting every agent reinvent its own logging and memory rules, the Skill Bus can attach a simple policy to each capability.

Here is an example of an audit entry for a single call:

{
  "timestamp": "2025-12-12T09:15:00Z",
  "capability": "orders.create",
  "version": "1.0.0",
  "correlationId": "abc-123",
  "inputSummary": {
    "itemCount": 2,
    "currency": "USD"
  },
  "outputSummary": {
    "orderId": "order-789",
    "status": "created"
  },
  "durationMs": 321,
  "sourceAgent": "quote-assistant"
}

What matters is that:

• Agents talk to capabilities with clear names and versions
• Schemas live at the boundary and are easy to inspect
• Adapters keep all the system‑specific details out of the agent logic
• Memory and audit rules are part of the contract, not an afterthought

The goal of sharing this here is not to present a finished framework, but to see if this mental model matches what others are already building in their own stacks. If you are already doing something like this, it would be interesting to compare notes on where it helped, where it got in the way, and what should be standardized versus left flexible for each team. I would really appreciate insights and suggestions from others who are building similar agentic systems.