Skip to content

Ferry: a Jira card moves, a pull request lands

· By Jean-Noé Kollo

Five agents wired to the columns of a Jira board, running inside GitHub Actions — no server, no daemon to host. Published under the MIT licence, and it is what moves the site you are reading.

A Jira card changes column. A few minutes later a reviewed pull request lands on the integration branch. In between, nobody opened a terminal.

That is Ferry. We built it for ourselves, published it under the MIT licence, and it is what moves the site you are reading.

Five agents, one Jira board

Ferry does not invent a workflow of its own: it plugs into the one already in use. Each agent listens to a board column, and moving the card is what fires it.

The refiner takes a vague ticket and makes it implementable. The developer writes the code and opens the pull request. The reviewer examines it and either approves or asks for changes. The iterator picks up the change requests. The merger merges, and closes the ticket.

Every step moves the card itself, which avoids the worst failure of tools in this family: a board that lies about the real state of the work. Here the board is the state, because the board is what gives the orders.

Nothing to host

Most tools in this family need a service running somewhere: a machine, a daemon, a webhook to expose, and the maintenance that comes with all three. Ferry has none of it. It runs inside GitHub Actions, as a router workflow that calls whichever agent matches the transition it detected.

The practical consequence matters more than the elegance: there is no server to pay for, no secret to move outside GitHub, and no extra component that can fall over during the night. Installing it is one command, and replaying that command regenerates the workflow it installed.

The guardrails matter more than the agents

Letting agents merge on their own is only worth anything if what they produce has to clear the same gates as human work. That is the real subject, and it is the part we worked hardest on.

Agents open their pull requests against the integration branch, never against production. The project's quality chain — lint, tests, build — is a required check on every pull request, with no exemption for the robot. And Ferry's own workflow files sit under CODEOWNERS: an agent cannot edit the rules it is subject to.

That last point is the most important of the three. A pipeline of agents that can rewrite its own guardrails has no guardrails.

Open, and already in production

Ferry is published under the MIT licence, on GitHub and on npm. We do not present it as a finished product: it is a tool we wrote for our own use and maintain because we depend on it. The best regression test we know of is this website.

The model each agent uses is set by configuration — a strong model for refinement, review and merge, where the judgement sits; a faster one for execution. That is the kind of trade-off you want to settle with a variable rather than by rebuilding the chain.