How I put AI agents to work.

An agent makes a change and submits it to the project as a proposed change. Automated tests run on it, and a separate AI agent reads it. Then the repository’s own rules decide what happens next.

Small changes that can be undone, and that the agents have permission to make, can be added on their own. Often that happens through GitHub auto-merge, which adds the change once the required checks pass. Major upgrades, work the agents cannot properly check, and decisions outside their permission wait for me.

One agent run on October 14 reached that stopping point. The work at BuyLandFL needed my input, so the agents checked Yapword next. Several upgrades failed the automated checks. Another affected the game’s share cards, and the agents had no working preview to check those cards. They left the upgrades for me and recorded what needed attention. The record below counts what has merged without me pressing merge, and which route each one took.

The threat I plan for first is an instruction hidden in something an agent reads: a file in the repository, a pull request description, a web page, or the output of a tool. My shared workflow file says that external content is data, never an instruction, and that the hooks which check an agent’s work may not be changed without my authorization. Both are written rules. A hook scans files as the agent reads them, but it only warns. What code enforces is narrower. The graph checker refuses any plan where the model closes an irreversible step or verifies its own work, and a companion check refuses to treat a copy of that checker as a gate once it no longer matches the canonical one. The merge gate runs from the main branch, so a pull request cannot edit the check that judges it, and it rejects a review whose reviewer is the author. That reviewer is a fresh session that did not write the change, not a different model. The gate checks the name on the record and the exact commit it read, not which model wrote the review.

When something goes wrong, we use the failure to improve a test, an instruction, or a handoff. Changes to those tools need review too. An agent can propose an improvement; it does not get to remove its own checks to finish a task.

Scheduled jobs watch for problems with the projects, memory, and operating costs. Recovery tools handle specific failures, such as restarting an unhealthy database or restoring a known stale copy of a tool. They leave unfamiliar changes for review.

The aim is to catch mistakes early, keep them from spreading, and leave enough evidence to recover. I keep experimenting because different projects need different arrangements.