# Profiles, Transports, and Connectors

AIP has one native semantic model. Transports, compatibility profiles, and
connectors solve different integration problems around that model.

Understanding the boundary prevents an integration from becoming a second,
incompatible runtime.

## The Three Boundaries

| Boundary | Question it answers | Examples |
|---|---|---|
| Transport binding | How is a native envelope moved? | HTTP, NATS, SSE, WebSocket |
| Compatibility profile | How does another protocol map to AIP? | MCP, A2A, signed webhooks |
| Connector | How does one product perform real work? | Cal.diy, Hermes, Dify, CrewAI, Chatwoot |

A transport does not change action meaning. A profile does not own product
credentials or business APIs. A connector does not redefine AIP policy or
lifecycle states.

## Transport Bindings

Native HTTP and NATS carry complete AIP envelopes. SSE and WebSocket expose
long-lived delivery behavior for events and streams. The same action id,
identity context, lifecycle rules, and protocol errors apply regardless of
transport.

Choose a transport according to topology:

- HTTP for request/reply, operational APIs, and common service networking;
- SSE for one-way event following with cursor resume;
- WebSocket for authenticated bidirectional multiplexing;
- NATS for brokered routing, queue groups, and service-to-service request/reply.

Transport authentication is not capability authorization. Both checks remain
required.

## Compatibility Profiles

A compatibility profile translates a foreign protocol at the gateway edge.
For example, the MCP profile maps tool calls to native actions and projects
native resources and lifecycle information back into MCP objects.

The profile owns:

- foreign wire DTOs and protocol versions;
- method and error mapping;
- session and transport rules specific to that protocol;
- compatibility conformance fixtures.

The profile does not copy foreign DTOs into `aip-core` and does not create a
parallel action store.

## Connectors

A connector maps a real product boundary to AIP capabilities. It owns provider
authentication, endpoint DTOs, webhook verification, error normalization, and
provider-specific recovery.

The connector publishes only behavior it can prove. If a provider cannot
cancel, stream, deduplicate, simulate, or compensate an operation, its
capability contract must say so.

## One Request Path

An MCP tool call that reaches a Cal.diy connector follows this path:

```text
MCP client
  -> MCP compatibility profile
  -> native AIP Action
  -> gateway authentication and policy
  -> durable runtime lifecycle
  -> Cal.diy connector
  -> Cal.diy API
```

The native action remains the source of truth. MCP is the client-facing
projection; Cal.diy is the product implementation.

## Choosing the Right Extension Point

Use a transport binding when the peer already understands native AIP but needs
a different network mechanism.

Use a compatibility profile when an existing standard protocol must map to AIP
without product-specific behavior.

Use a connector when integrating one product, API, channel, or runtime.

Do not create a new profile merely because a product has unusual endpoints.
Do not place a general protocol mapping inside one product connector.

See [Use AIP through MCP](../guides/use-aip-through-mcp.md),
[Use AIP through A2A](../guides/use-aip-through-a2a.md),
[Transport Bindings](../reference/transport-bindings.md),
[Build a Connector](../guides/build-a-connector.md), and the
[Compatibility Profile Reference](../spec/compatibility-profiles.md).