Running agent work through gates
For one person directing coding agents: at the end every task takes the same route and every change is checked before it is merged.
- Skill areas
- Based on
- Updated
- ·
Before you start
-
A task queue in which a task is either ready or blocked.
-
A check that runs the same steps locally and on the main branch: tests, types, the build, the design rules and the data checks.
-
A branch for every task and a merge only through the gate.
-
Lanes: areas of work that can move in parallel.
Steps
Write the task before the code
Describe the goal, the limits and what finishes the task. A task that cannot be checked is not ready.
Let the scheduler hand out the ready tasks
Each lane takes its next ready task and starts an agent for it. If no task is ready, the lane waits; it does not invent work.
Run the gate on every change
Every change runs the same checks before it is merged. Only a change that passes is merged; a red result sends the task back to the agent.
Check the main branch after every merge
After a merge, the checks run on the whole main branch. A red result shows on the main lane, and the next green shows that the fault is fixed.
Keep the decisions that need a person
Product and production decisions come to the lead; within the agreed limits, the agents decide the rest. A controller brings the lead only the decisions that need a person.
Release from a green main branch
A release follows a green main check. A halt stops the lanes when a usage limit or a red result needs a person first.
When not to use this
-
Work no program can check, such as choosing a direction: direct it in a conversation and record the decision.
-
A single change with no queue behind it: the route costs more than it saves.
-
A codebase without a check that runs locally: build the gate first.
Where it comes from
The route is the one Hintapiste.fi is built with: every change is tested in 69 steps before release. The working-method page replays two days of it from the event log.