Product 01
Agent teams
that ship software.
agentd runs teams of specialised AI agents that take a work item from plan to a reviewed pull request — or a single seat that works out of a mailbox. On your infrastructure, under your identity, with every step on the record.
Team builder
Create agents from templates or from scratch: model, prompt, skills, capabilities, delegation edges. Saving a definition never starts a workload — starting one is a separate, deliberate act.
One desired state, two runtimes
The same team definition materialises as containers on Docker locally and as Deployments on Kubernetes in production. Concurrent edits fail loudly with a conflict instead of silently overwriting each other.
Delivery with a human gate
Clone, plan, delegate, code, run the project’s own tests, push, open the pull request. Review and merge are yours — the pull request is the gate.
Identities without ceremony
A delegation edge creates a scoped OIDC client automatically; removing the edge removes the client. Published agents get their public URL and an exact-origin browser client from one wildcard DNS record.
Skills and tools, allowlisted
Checked-in skill packages, explicit command allowlists, web search, image generation, diff review, shared repository knowledge. The UI grants compiled capabilities — it does not turn arbitrary code into tools.
Cost and evidence
Every run records actor, model, tokens and cost. Reasoning and tool steps are visible live while the team works — not reconstructed afterwards.
How a task ships
Five steps, all of them visible.
- Frame it. Title, acceptance criteria, repository — the work item carries everything, the team is repository-agnostic.
- The lead plans. It breaks the goal down and delegates by the files that will change, not by the wording of the task.
- Specialists build. Scout reads, developers write, in a shared workspace — each seat with its own model and its own rights.
- The project judges. The team runs your test suite, not a proxy metric. Failures are reported, not hidden.
- You decide. Push, pull request, review — nothing merges without a person.
First measured end-to-end run: 10 min 52 s, $0.10, 20/20 tests green — verified independently, and every run since is measured the same way.
The mail door
Not every task starts as a ticket.
A seat can be given a mailbox instead of a work item. It polls, sorts what arrives into the classes you describe in plain words, and answers — as a draft you release, automatically only where you said so, and always to the sender of the mail being answered. Only addresses you allowed in get through the door at all.
The mailbox is the queue
Handled mail moves to a Processed folder; whatever the seat could not finish moves to Held, where a person sees it. A journal written before the reply is sent and confirmed after means a restart mid-answer never writes to the same person twice.
It opens what arrives
An attachment is identified by its leading bytes, not by its filename or the type the sender declared — both of which the sender writes. A file that is not what it claims holds the mail instead of being answered around, and a signature logo is never mistaken for somebody’s document.
It files into the system you run
A document can be filed through an existing API — but only under a record the seat looked up in the same turn, only under a heading that system itself has, and only with bytes that arrived with the mail. Nothing it cannot place is placed anyway.
Measured against a live mailbox: a lab report carrying an instruction in white type one point tall — invisible on paper, read perfectly by a model — told the seat to file it under a different person. It filed nothing there. A document is a delivery mechanism, so the guard sits on the write, not on the reading.