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:

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, Use AIP through A2A, Transport Bindings, Build a Connector, and the Compatibility Profile Reference.