One container for every agent — and the road to hosted

Buying an AI agent is easy. Running one is not.

What arrives is a folder. Somewhere inside it is a README telling you to install some dependencies, set some variables, and work out what the thing expects as input. Every agent answers those questions differently, so every agent becomes its own small integration project — and that work lands on the buyer, at exactly the moment they were hoping to get something done.

We have spent this month removing that step, and the first half of the answer went live on Docker Hub this week. Here is what we built, why it is shaped the way it is, and where it points next — including the part that does not exist yet.

One image, every listing

sigrix/runner is a single container image. Not one per listing, not one per seller — one, for every runnable listing on the marketplace.

That constraint drove the whole design. A purchase should not turn into a registry artifact, and hitting Publish should not turn into a build: the moment each listing needs an image of its own, sellers wait on a build queue and we pay to store a thousand near-identical copies of the same runtime. So the image carries the runtime, and the agent arrives at boot:

what happens when you start it  your token          →  resolved from the environment
  entitlement check   →  is this account licensed for this listing?
  bundle pull         →  fetched from the distributor
  digest verify       →  SHA-256 must match what was stated
  serve               →  Postern on port 8787

One command, and the thing you bought is running. Nothing touches the disk until the download's SHA-256 matches the digest the distributor stated, so an altered or truncated bundle leaves you with nothing rather than with most of something.

It is published, it is real, and you can pull it today. The job that publishes the image also runs its acceptance tests against the exact image it built, and we pulled the result onto a machine that had never built it to confirm the bytes matched.

Your keys never come to us

Your provider keys — whichever model or tool the agent calls — are read by the run itself, inside the container, from an environment file you supply. They are never uploaded, never stored, and never reach Sigrix. The protocol gives a credential nowhere to travel even if it wanted one.

The agent writes only inside its own bundle folder, as an unprivileged user. Your token licenses the listings on your account and nothing else — ask for something you have not bought and you get the same "not found" you would get for something that was never there.

None of that is a policy we are asking you to take on trust. It is the shape of the software, and the software is open.

We did not invent a private format

The container speaks Postern, an open protocol we wrote for this problem and published under Apache-2.0.

It is four verbs:

Anything that can call HTTP can be a client — a terminal, an IDE plugin, a web app, another agent. Anything that can serve HTTP can be an agent, in any language. There is no Sigrix SDK to adopt, and there is not going to be one.

We could have kept this closed. A proprietary format is a lock, and locks look like moats. But the reason agents are hard to buy is that every one of them is a bespoke integration, and you do not fix a fragmentation problem by adding one more private standard to it. If Postern is useful, it should be useful to people who never sell a thing on Sigrix.

How a listing reaches you today

Why a container, if the bundle already runs locally?

Fair question — and the answer is the interesting part.

Every bundle already runs without Docker. Unzip it and the same runner serves the same four verbs, because the container is a deployment shape of that runner rather than a second implementation of it. Same code, two places.

That is deliberate, and it is the hinge everything below turns on: the same bundle that runs on your laptop can run on infrastructure that is not yours. Once that is true, where an agent runs becomes a choice instead of a rewrite.

Where this goes: you should not have to run anything

Docker is a good answer for people who have Docker. For plenty of buyers it is not an answer at all — they want the result, not a runtime. The honest end state of this road is that you buy an agent and it simply works: hosted, metered by what you actually use, with nothing installed anywhere.

That is the direction we are building toward. It is not where we are today, and we are not going to put a date on it in a blog post.

We hold ourselves to a rule that predates this article: the claim ships after the mechanism, never before. Hosted execution opens when buyers demonstrably want to run things they have not downloaded — not because it would look good in a pitch deck. Announcing it today would mean advertising economics we have not earned yet, which is precisely the failure we wrote our own strategy to avoid.

What we can say is that the ladder is already half-climbed, and that every rung stands on its own. Crew listings are executed on our infrastructure before they are allowed into the catalog. Crew pages lead with the output of those runs, and assistants carry a capped "try it" preview. The bundle, the protocol and the container all shipped this month. If the last rung never opens, none of that becomes stranded work — each piece made buying safer on its own terms.

What does not change

Whatever the runtime eventually looks like, the guarantees underneath it are the ones on our vision page, and they are not up for renegotiation:

• A human checks the work before it reaches the catalog.
• Only buyers can review, and reviews publish without our approval.
• Fourteen days to get your money back, written into the terms.
• Creators keep 80% — 85% for the founding cohort, for the life of the account.
• Your keys stay yours. That promise gets harder to keep the more we host, which is exactly why we are walking this road rather than sprinting it.

Try it, or come build on it

If you have bought a crew or a workforce, your token and listing identifier are on your account's plugin-feed card — and the identifier is already filled in at the top of your bundle's .env.example. The image's page on Docker Hub has the exact command.

If you have not, browse the marketplace and see what is there. If you build these things for a living, sell them here — the founding cohort keeps 85% for the life of the account.

We will keep posting as this gets built, including the parts that do not work yet. The protocol is public, the image is public, and anything unfinished gets named as unfinished. That is the deal.