Eidos AGI

Shipr.

Your toolkit for delivering software and monitoring every shipment — across orgs, agents, and humans.

In flight

Bronze means something is shipping. Mark, primary action, in-flight chip: same metal.

The age of AI

Shipping got stranger.

Agents can open a PR, kick Actions, and talk like they own the release. Then the session ends. The next agent starts cold.

They retry what already failed

Without a frontier, every new session rediscovers the same blocker — and burns tokens proving it again.

They invent ceremony

One agent wants a checklist in Slack. Another writes a one-off script. None of it lives next to the product.

Someone still has to say yes

Production deploy, secrets, “did staging actually go green?” — the messy middle that dashboards never owned.

Yesterday

Yesterday’s tools were built for a slower era.

Useful. Incomplete. None of them were designed as shared memory for agents that ship overnight.

× not enough

CI dashboards

A run list is not a shipment ledger. It does not say what was tried, what blocked, or what the next agent should do.

× wrong inventory

Ansible & friends

Great at hosts. Shipping paths — Actions, Railway, a forge publish, waiting on a person — are a different inventory.

× no memory

Chat war rooms

Threads scroll away. Status lives in someone’s head. Agents cannot frontier a Slack channel.

× wrong job

Another control plane

You do not need poetry about delivery. You need a committed model of how this product ships, and a live watch on it.

The gap

DevOps becomes just a config file.

How this product ships should live next to the code — channels, proof commands, who must approve, modules — not in a wiki nobody updates.

Attempts should pile up as evidence. Agents read the frontier. Humans see the same ledger on phone, Mac, tablet, or a Chrome side panel.

In flight

release · v0.4.2

Waiting on proof_commands

2m

Blocked

publish · npm

Waiting on production approve

21m

Failed

hotfix · railguey

proof_commands exit 1

3h

Shipr

Ansible for shipments.

Treat shipping paths as plugins. The committed release model is the playbook. Deliver with the CLI. Monitor from every surface.

Write how the product ships once. Agents load it with shipr model and frontier. Humans watch the same state without opening twelve tabs.

GitHub Actions, Railway via railguey, Cloudflare via clawdflare, proofs via testr, a person who has to approve — each plugs in as a plugin. Same shipment record. Different backend.

// committed next to the product
{
  "role": "shipment_control",
  "channels": ["github_actions", "railway", "pypi"],
  "proof_commands": ["go test ./..."],
  "approvals": ["production_deploy"],
  "plugins": {
    "testr": { "channel": "proofs" },
    "railguey": { "channel": "railway" },
    "clawdflare": { "channel": "cloudflare" }
  },
  "attempts": "/.shipr/release-attempts/"
}

Deliver + monitor

One model, every surface.

Agents keep the CLI. You keep shipr watch — and soon a dock badge, phone strip, or Chrome panel — keyed to the same ledger when AI prompts AI and needs a person.

Local now

CLI watch

shipr watch — live frontier + attempts from the shared ledger. No agent session required.

Shipping

360px floor

Chrome add-in

Side panel on the repo, PR, or Actions page.

Building

Dock badge

Mac

Badge bumps when something is shipping across paired orgs.

Building

Thumb reach

Phone & tablet

In-flight and blockers without opening a laptop.

Building

Install

Start with the CLI.

Write the ship config down. Stop reinventing the release every session. Fleet UI comes after the memory exists.

$ go install github.com/eidos-agi/shipr/cmd/shipr@latest
$ shipr model --project . --write --json
$ shipr frontier --project . --json
$ shipr watch --project .

Open the repo