AIRTP Intelligent Real-Time Transport Protocol

One application.
Many AI providers.

AIRTP is a transport abstraction layer that separates application logic from AI providers. Applications communicate with a consistent session layer while provider adapters translate requests into provider-specific protocols. Swapping providers becomes a configuration decision rather than a rewrite.

Start with the TL;DR
Application AIRTP Session Layer Provider Adapter Transport AI

TL;DR

1 API

Provider Independence

Application code targets AIRTP rather than a vendor SDK. Adapters map AIRTP semantics onto each provider.

N Transports

Transport Independence

HTTP, WebSocket, local processes, pipes, or future transports all fit behind a consistent session interface.

Streaming

Protocol Features

Capability negotiation, message envelopes, streaming, chunking, and reassembly are protocol concepts instead of provider-specific code.

Core ideas

Provider Abstraction
Session Management
Capability Negotiation
Streaming Messages
Chunk & Reassemble
Adapter Pattern

Interactive Layered Architecture

Each layer has a single responsibility. Select a layer in the diagram to highlight its role and observe how AIRTP isolates application logic from provider-specific implementations.

  • Application — business logic and prompts.
  • Session Layer — lifecycle, routing, state.
  • Provider Adapter — translates AIRTP into provider APIs.
  • Transport — HTTP, WebSocket, IPC, or future transports.
  • AI Provider — executes inference.
Click a layer in the diagram to inspect its responsibility.
Application AIRTP Session Layer Provider Adapter Transport AI Provider

Protocol Flow Animation

AIRTP represents communication as structured protocol messages rather than direct provider SDK calls. Requests travel downward through the stack and streamed responses travel back upward using the same session.

1.
Open Session
2.
Negotiate Capabilities
3.
Send Envelope
4.
Receive Stream
5.
Complete Session
App S A T AI

Provider Independence

AIRTP applications target a stable protocol instead of a vendor SDK. Provider-specific differences are isolated inside adapters, allowing applications to switch providers without changing business logic.

Concern Application Adapter
Authentication None Provider-specific
Request Format AIRTP Envelope Translation
Streaming Session Events Protocol Mapping
Error Handling Unified Normalization
Model Selection Logical Capability Provider Mapping
Application │ ▼ send(envelope) │ ▼ AIRTP Session │ ▼ Adapter ├── Provider A ├── Provider B ├── Provider C └── Future Provider

Adding a new provider requires implementing an adapter rather than modifying application code.

Transport Independence

The AIRTP protocol is independent of the underlying transport. Reliable message delivery, streaming, and session semantics remain consistent regardless of how bytes move between peers.

HTTP
WebSocket
Named Pipe
Unix Socket
Local IPC
Future Transport
AIRTP Session Transport Interface HTTP WS IPC ...

Capability Negotiation

Capabilities are exchanged during session establishment. Applications express requirements while adapters advertise supported features. The result is a negotiated feature set shared by both endpoints.

Capability Status
Streaming Enabled
Structured Output Enabled
Tool Calling Enabled
Audio Unavailable
Vision Optional 
Client
  │
  ├── supported_features[]
  │
  ▼
Session Layer
  │
  ├── intersect()
  │
  ▼
Provider Adapter
  │
  ├── provider_capabilities[]
  │
  ▼
Negotiated Session

Negotiation allows AIRTP to expose the strongest common feature set without requiring application changes for each provider.

Message Envelope Visualization

Every AIRTP exchange is represented as a structured message envelope. Metadata remains separate from payload data, allowing adapters to translate protocol semantics without altering application intent.

{ "session":"5a72...", "sequence":42, "type":"prompt", "stream":true, "capabilities":["tools","json"], "payload":{ "role":"user", "content":"Explain AIRTP." } }
Header Session Metadata Capabilities Payload Integrity / Extensions

Chunking & Reassembly

Large payloads and streaming responses are transmitted as ordered chunks. The session layer tracks sequence numbers, detects completion, and reassembles messages before presenting them to the application.

Chunk 1
Chunk 2
Chunk 3
Chunk 4
Verify
Reassemble
#1 #2 #3 #4 Merge

Why chunk?

  • Supports arbitrarily large responses.
  • Allows progressive streaming to the application.
  • Improves resilience across diverse transports.
  • Provides deterministic ordering using sequence numbers.
  • Enables resumable session semantics.