Use Cases

See how kubbi fits into real agent workflows

Explore the patterns teams use to pass files, secrets, results, and state between agents, humans, and workflow steps.

Agent → Agent

One agent finishes the work. Another agent picks it up.

Research agents, extraction agents, planning agents, and execution agents often need to pass structured output, retrieved context, generated files, or short-lived credentials to the next step. kubbi gives the first agent a secure temporary handoff: store the payload, pass the claim URL, and let the next agent claim it only when it is ready.

Common payloads

Structured JSONRetrieved contextGenerated filesShort-lived tokens

How it works

1

Agent A creates a kubbi with the payload.

2

The workflow passes only the claim URL forward.

3

Agent B claims the payload and kubbi burns it on final read or expiry.

Why use kubbi?

Keep raw payloads out of prompts and tool outputs, avoid bloating orchestrator state, and make one-time handoffs easy to expire or burn after read.

Step → Agent

A workflow step stages data for an agent to pick up later.

Orchestrated jobs, scheduled tasks, and pipeline stages regularly produce artifacts that an agent needs to act on - but the agent may not run in the same environment or at the same time. kubbi lets the upstream step store the payload and pass a claim URL through the orchestrator, queue, or task record. The agent claims the data on its own schedule.

Common payloads

ETL outputsStaged datasetsRun-specific configIntermediate state

How it works

1

A workflow step creates a kubbi with the artifact.

2

The claim URL travels through the orchestrator or queue.

3

The downstream agent claims the payload when it spins up.

Why use kubbi?

The upstream step finishes cleanly without waiting for the agent. The payload disappears on expiry or final read - no permanent storage to manage.

Agent → Human

An agent pauses for review without keeping everything alive.

Many agent workflows need a human checkpoint for approval, QA, or domain review. kubbi lets an agent persist a draft result as a temporary handoff, record the claim URL in the task system, and exit cleanly. The reviewer claims the payload later, and the workflow resumes without depending on a long-lived runtime or shared in-memory state.

Common payloads

Draft analysesGenerated reportsApproval artifactsFlagged cases

How it works

1

The agent reaches a review checkpoint and creates a kubbi.

2

The claim URL is added to a task, queue, or review system.

3

The reviewer claims the payload and the workflow continues separately.

Why use kubbi?

You get clean async review loops without dumping sensitive draft output into task comments, chat threads, or workflow state.

Step → Step

Workflow steps hand off intermediate artifacts without shared state.

Not every workflow step runs at the same time or in the same environment. kubbi gives orchestrated jobs, scheduled tasks, and agent pipelines a simple place to stage intermediate artifacts: one step creates a kubbi, the next step claims it later, and the payload disappears on expiry or final read.

Common payloads

ETL outputsStaged datasetsRun-specific secretsIntermediate state

How it works

1

A workflow step creates a kubbi with an intermediate artifact.

2

The orchestrator, queue, or task record carries the claim URL.

3

The downstream step claims the payload on its own schedule.

Why use kubbi?

It reduces schema coordination, avoids oversized messages, and gives you TTL and retrieval limits without turning temporary artifacts into permanent storage.

Other common kubbi patterns

Multi-file packages
Bundle multiple files in a single kubbi - config, data, instructions, and attachments travel together through one claim URL.
One producer, several downstream readers
Use max_retrievals to let two or three downstream steps claim the same intermediate artifact without turning it into durable shared storage.
Cross-org handoffs
When a partner, vendor, or external team needs to hand data to your agent, kubbi lets the payload stay encrypted and temporary while only the claim URL crosses the organisational boundary.
Human → Agent handoffs
A person or internal tool creates a kubbi with files, secrets, or approval data. The agent claims the payload when it starts processing - no sensitive data lingering in chat, email, or ticket fields.

Works with the file types most workflows use

From structured data to generated files, kubbi packages common workflow payloads behind a single claim URL.

.json

JSON

Structured data, API responses, agent outputs

.csv

CSV / TSV

Tabular data, ETL outputs, datasets

.txt

Plain text

Logs, notes, raw output

.pdf

PDF

Reports, invoices, generated documents

.png

Images

Screenshots, charts, generated visuals

.zip

Archives

Bundled artifacts, multi-file handoffs

.yaml

YAML

Config files, pipeline definitions

.xml

XML

Structured markup, SOAP payloads

.md

Markdown

Documentation, formatted notes

*/*

Any MIME type

Binary blobs, custom formats, anything

Common payloads that travel through kubbi

Structured resultjson
{
  "analysis": "complete",
  "confidence": 0.97,
  "next_step": "review"
}
Dataset extractcsv
id,name,status,score
1,alpha-run,pass,0.94
2,beta-run,fail,0.31
3,gamma-run,pass,0.88
Short-lived secrettext
token: sk-proj-████████████████
expires: 2025-07-01T12:00:00Z
scope: read-only
one-time: true
Pipeline configyaml
stage: extraction
model: gpt-4o
max_tokens: 4096
output_format: json

Try kubbi on your next workflow

Create a temporary handoff, pass one claim URL, and let the next agent or human pick it up when ready.