Writing code
The most developed piece of work in the product is the coding controller: hand it an issue, get back a merge request. The interesting part is where it deliberately stops.
Why each step is there
An exact commit, not a branch name. The checkout is pinned to a specific commit, so the work the agent reviewed is the work it changed. A branch that moved underneath it would silently invalidate everything after.
A plan before code. The agent writes what it intends to do and that plan passes the gate. Reviewing an intention costs a minute; reviewing a finished 40-file diff costs an afternoon.
Bounded repair. Verification failures trigger a retry loop with a hard limit. Without the limit an agent can burn budget indefinitely on a problem it cannot solve.
Idempotent output. Running the job twice updates the existing merge request rather than opening a second one, so a retry after a crash does not litter the forge.
Where the work comes from
An agent can be handed work three ways: a person asks in chat, someone mentions the bot on a merge request or issue in GitLab or GitHub, or a schedule fires and starts a turn with no human present at all. The third case is why the audit log and the interrupt governor exist — proactive work needs the same record and the same manners as work you asked for.