Moving a card runs Git.

refs/heads/main — the flow, described once

Statuses across the top. Repositories down the side.

Each cell of that matrix answers two questions: where a branch is cut from when work enters the stage, and where it merges when it leaves. A cell you leave empty means the stage does not touch that repository. That is the whole setup, and you do it once.

a card enters a stage

Then the board writes the Git

The branch appears, named the way your team names them. The first push opens the pull request — a provider will not take one with no commits, so it waits for the commit rather than forging an empty one. Promoting the card merges it into wherever the next stage points.

card → In development

git branch feature/42-… main

first push

pull request opened

card → In production

merge, tag, changelog

card ← dragged back

revert opened, card waits for it

and where it refuses

A board that will not lie about what shipped

A stage can require green checks, a minimum role, an approval. A red build, a branch somebody deleted by hand, a merge that will not apply — the card does not move, and the reason is written on it. Dragging a card out of production is not a status change either: the revert is opened, and the card stays where it is until that revert actually merges. Until it does, the code is still out there.

three repositories, one piece of work

Front and back move together, or neither moves

A card holds a branch in each repository it touches and a pull request in each. It is promoted across all of them at once — and refused across all of them, which is the half that keeps them honest.

a branch opened by somebody who is not a person

An agent that opens pull requests, and answers for them

Give it a model, a key and a list of what it may do. It joins the workspace with a badge, reads the card, and writes the code in a container with no network at all. The only moment it reaches out is to install dependencies, through a proxy that allows the registries its language uses and nothing else.

It proposes on a branch, as itself. When the build goes red it hears about it and tries again. When somebody asks for a change in review, it reads the review. What it never does is merge — unless merging is one of the things you gave it.

• whatever the repository is written inGo, Python, Rust, Node, Java — read from your devcontainer, or from the manifest at the root.
• a ceiling on what it may spendPer organization and per run, in money. It stops at the ceiling instead of you finding out afterwards.
• nothing lands without a diff you readEvery run is a proposal, with what it cost and what it touched. A secret found in a diff is refused, not warned about.

what it will never do

It orchestrates above your repository, never underneath it

If the repository forbids squash merges, Tylon does not offer them. If a protection rule refuses a merge, the card stops and shows the refusal in the provider's own words rather than working around it. And nothing of yours leaves with us: delete the organization and every branch, pull request, tag and release it made stays exactly where it is, in the repository that was always yours.

what it costs

Twelve dollars a person. Agents are not seats.

You already pay for the tokens an agent spends — the model key is yours, and the provider bills you directly. Charging for the agent as well would be charging twice for one thing, so we do not.

14 days of everything to start, no card. Nothing is taken away when it ends — the limits stop what is new and leave what you already made alone.