The side-channel pattern

Your agents already pass messages through a queue, a webhook, an MCP tool result, an A2A message. Those channels are great for control flow. They are awkward for the payload itself: size limits, sensitive data sitting in queue logs, multi-file bundles that don't fit inline.

kubbi takes the payload off the channel. The producer stores it once and gets back a claim URL. The channel carries the URL. The consumer claims the payload when ready.

What "side-channel" means here

The producer and consumer are connected by some primary channel, which is the control flow. kubbi is a parallel channel that carries the payload, separate from that primary route. The two channels meet only at the claim URL: a short reference that lives in the primary channel and points to the payload sitting encrypted in kubbi.

This is the claim-check pattern: a well-established enterprise integration pattern where the messaging path carries a token and the actual data lives somewhere else. kubbi is a managed claim-check service with defaults shaped for agent workflows.

Why pair instead of replace

kubbi doesn't replace your queue, webhook, MCP server, or A2A bus. It pairs with them. The primary channel still moves control, still maintains ordering, still handles retries. kubbi only takes the bytes off that channel and serves them server-side with TTL, burn-after-read, and a manifest preview, all server-enforced.

For deeper coverage on the defaults, see TTL and retrievals, encryption and storage, and payloads and files. For the comparison to S3 + presigned URLs, raw webhooks, queue-inline payloads, and rolling your own, see kubbi vs. the alternatives.