Skills and Integrations Framework skills-and-integrations

An integration (formerly known as a tool) is a connection to a data source or backend. A skill is a behavior.

One integration can be used by many skills. One skill can use several integrations. You configure them independently and map them together.

Skills

A skill is the behavior layer of a concierge. It is a named, reusable unit that defines a single job the concierge can do: what it handles, when it steps in, and how it responds. A skill holds no data of its own; it borrows capability from the integrations attached to it.

Every skill is made of five parts:

How a skill behaves at runtime: when a user message arrives, the platform matches it against each active skill’s “use when” trigger and routes the message to the matching skill. That skill then runs its instructions and calls only the integrations attached to it. Its instructions are composed into the concierge’s overall runtime behavior alongside the brand profile and any other active skills.

A skill decides what to do and when. It does not itself connect to any data; that is the integration’s role.

Example of the Site Advisory skill

{width="800" modal="regular"}

Integrations

An integration is the capability layer of a concierge. It is a connection to an external or backend system (a knowledge base, a content source, a live commerce catalog) that actually fetches data or performs an action. Where a skill is judgment, an integration is capability.

Every integration has these characteristics:

How an integration behaves at runtime: when a skill fires and decides it needs data, it calls one of the integration’s tools. The integration executes that call against the live backend and returns structured data to the skill, which the skill then uses to form its response.

An integration provides capability but exercises no judgment. It waits to be called by a skill, does the specific job asked of it, and returns the result.

Capabilities and limits (the self-serve boundary)

Integrations available out of the box

Below are the integrations shown in Composer’s Browse integrations panel.

{width="800" modal="regular"}

Skills available out of the box

Below are the skills shown in Composer’s Browse skills panel. Each one lists its recommended integrations.

The two commerce skills are catalog-only capabilities and depend on the Commerce MCP integration, which is not part of the baseline. In a non-commerce concierge, Site Advisory and Product Advisory run against the auto-created Knowledge Base Search instead.

{width="800" modal="regular"}

What is wired at concierge creation

When a concierge is created via one-click setup, the baseline is assembled for you.

FAQ

What is the difference between a skill and an integration?

An integration is a connection to a data source or backend; it is what the concierge can reach out to, such as a knowledge base or a live commerce catalog. A skill is a behavior; it decides what the concierge does, when it does it, and which integrations it is allowed to use.

Rule of thumb: An integration is a capability; a skill is the judgment about when and how to use that capability.

Can the same integration be used by more than one skill?

Yes, and this is intentional. Commerce MCP’s tools are shared across both Catalog Discovery and Product Comparison. Building an integration once and reusing it across many skills and many customers is the core efficiency of the 2.0 framework; it is what removes the per-customer custom build.

Can a practitioner add an entirely new capability without engineering?

Only if an integration for it already exists in the catalog. A practitioner can freely map, configure, and instruct any existing integration; that is self-serve. But if the capability requires a backend or connector that does not exist yet (a new API or a new data source type), that is an engineering task to build the integration first. Once it exists in the catalog, configuring it becomes self-serve again.

How is this different from BC 1.0’s single system prompt?

In 1.0, behavior was driven by one large system prompt (the manifest), which was hard to edit safely and generally required engineering to change. In 2.0 the manifest still exists, but it is composed from modular pieces rather than written as one block. That is what makes behavior configurable by a practitioner and makes individual guardrails and instructions legible and auditable instead of buried in one prompt.

What exactly does the early crawl create?

The crawl creates a knowledge base, a searchable store of the site’s content, built from the top 10 to 15 pages found via the sitemap. This is the data layer only. The crawl does not create a skill or an integration; it produces the content that they later act on.

If the crawl creates the knowledge base, what is the Knowledge Base Search integration?

Knowledge Base Search is a built-in integration whose job is to search that knowledge base. The knowledge base is the data; Knowledge Base Search is the capability that queries it. They are two separate things: one is the content, the other is the tool that reads the content. It is a common mistake to treat them as the same; they are not.

How does the concierge answer a general question at creation, end to end?

Three layers work in sequence, and they map exactly onto the skill, integration, and data model: