Introduction

BlobHub is where a company’s agents are built, governed and audited. Every team develops its agents against the same building blocks, so what one team ships can work with what another team built, and the coding agents your engineers already use, Claude Code, Codex and Antigravity, join in through the same threads from their own machines. Each agent works with the access it has been granted and stops for a person where a rule says it must. Every run, message and approval is recorded as it happens, so you can read back what any agent did. This tab is the overview, written for the people who decide how agents are built and run across a company with many teams, and for the developers who build them. It explains why BlobHub exists, what it is made of, and how it covers an agent before it runs, while it runs and after it ran; the tabs that follow, from the API Reference to the Worker, are the reference.

​

Agent sprawl

Agents arrive in a company one team at a time. Each team picks a framework, wires up its own model keys, and invents its own way to run, approve and log. Every one of those choices is reasonable. The sum is a company that cannot say how many agents it runs, what they are allowed to do, or what one of them did last Tuesday. The rest of this page is what BlobHub does about it.

​

A new set of primitives

BlobHub is to agents what the cloud was to servers: a new set of primitives to build against. The primitives are sessions, threads, shared objects, workflows, schedules, credentials, permissions and policies. You develop against them the way you develop against cloud services, and the agents, copilots and apps your teams build from them share the same parts. Because your agents are made of these primitives, they live and work inside BlobHub. That makes BlobHub the system of record and action for your agents. Almost everywhere else, the system that runs agents and the system that remembers what they did are separate products, joined by instrumentation.

​

Build, Govern, Audit

Build. Govern. Audit. Every team builds from the same primitives, every agent runs inside your guardrails, and everything they do is on the record.

​

Build

Before it runs. The same primitives, so everything works together. Sessions, threads, scheduling, credentials, a UI and an API are there on day one, and you write the agent. Start with Workflows.

​

Govern

While it runs. Agents run inside your guardrails. Credentials and permissions are platform features you configure, not code you maintain, and so are the policies and approvals the worker applies to the coding agents it runs. Start with Organizations & access.

​

Audit

After it ran. Everything they did, on the record. Every run is recorded from the start, with nothing to set up, and debugging starts from that record. Start with The record.

​

Apps

An app is built on BlobHub from its building blocks and deployed as content, with no platform code of its own.

• Missions (Engineering, live). Delegate work to coding agents: a mission is broken into cells wired into a graph, each worked by an agent under a procedure and a policy, and a person approves what matters.
• Day Trader (Finance, in build). Intraday trading for US equities, being built from the same primitives.

Apps & Missions covers what an app is made of and how Missions works.

​

How it works

Under the hood, BlobHub is a serverless platform for versioned blob storage with workflow automation: a workflow, a schedule or a model is a typed, versioned blob behind one REST API. What you build is stored in blobs that your organizations own. Each blob has a type that says what it holds, such as workflows, schedules or a model, and most types keep a history of revisions; a scheduler’s one revision is changed in place. How BlobHub works explains that layer and names the blob type behind each primitive.

​

Where to go next