Technology · Platform

GitLab

Self-hosted GitLab is where my agents open merge requests they are not allowed to merge, and where discovered defects are filed as issues.

Agent SwarmFAFOHiveSelf-hosted merge requests and issues
Who holds what
no agent path to the main branch
  • 2end-to-end runs from a worker's edit to an opened merge request
  • 0agent commits or merge requests against the main repository

Merge requests agents cannot merge

Agent Swarm needed to show that a coding agent on a local model could do real repository work without ever being able to merge it. I decided the merge request would be the boundary and GitLab, self-hosted, would be where a person sees the result. A worker agent edits, tests, commits and pushes to its own branch from a throwaway container. A separate, long-lived gatekeeper agent is the only holder of the repository credential, so a compromised or confused worker has nothing to leak; it checks the worker's request and opens the merge request through the GitLab API. The story A coding agent that never holds the keys tells it in full.

own branchthe keymerge requestmerge
Worker
Gatekeeper
Person

I made the merge request the line agents cannot cross: they propose, a person merges.

I kept GitLab self-hosted and separate from the agent runtime, so the tracker is an ordinary GitLab a person can use without any of my tooling. GitLab itself is third-party; my work is the tools, the credential placement and the workflow around it. The agent runtime also carries a declarative HTTP tool for GitLab, so a persona that is granted it can work issues through the same tool pipeline every other tool uses.

An issue tool with a hand-back state

FAFOHive gives agents one action-dispatched GitLab tool for issue work. The tool carries both the tracker and the local repository work.

The actions, by where they act
tracker · readtracker · writelocal repository · git
On the tracker
  • List and read issues with their merge requestsread
  • Check for updates by typeread
  • Commentwrite
  • Move an issue through the labelswrite
  • Open a merge requestwrite
In the local repository
  • Statusgit
  • Branch and checkoutgit
  • Commitgit
  • Push and pullgit

I built the issue workflow around labels, with an explicit state for handing a problem back to a human: agents take real part in a conventional engineering workflow, and the decisions that matter stay with people. The focus of a pass is a parameter, so the same tool serves a security pass and an architecture pass.

1needs review
2in review
3solution ready
needs human intervention
security
performance
architecture
code quality

Each pass over an issue takes one of the four focuses and a persona.

The tool's description tells agents to use it only under direct guidance, which is the right default for anything that writes to a shared tracker.