The agent setup I keep coming back to looks less like a chat window and more like a small engineering team with a strict work queue.
There is a shared story list. Each story has a state: pending, in progress, blocked, ready for review, approved, merged, done. An implementer agent claims a story by moving it to in progress and attaching its agent id. From that point on, the work has an owner, a trail, and a place to put evidence when something goes sideways.
The story is the contract
This only works if the story is written well. A vague ticket gives the agent too much room to invent the product. A good story names the desired behavior, the files or systems likely involved, the acceptance criteria, and the cases that should fail. I want the agent to spend its creativity on implementation, not on guessing what the business meant.
Once a story is claimed, the implementer makes the smallest useful change and opens a pull request. The PR is not just a delivery artifact. It is the review surface for the whole system. The branch, commits, tests, screenshots, notes, and tool output all become part of the record.
Review should be a separate job
I do not want the same agent that wrote the code to be the only reviewer of the code. A reviewer agent should come in cold, read the story, inspect the diff, run or request the right checks, and leave comments the way a human reviewer would. If the project lives in Bitbucket, Claude can review in Bitbucket and write PR comments there. Codex can implement. Another provider can handle compliance. The exact model matters less than the separation of duties.
The compliance agent gets its own pass. It looks for the things product teams tend to remember late: data boundaries, audit requirements, regulated workflows, unsafe defaults, missing logging, or behavior that would be hard to explain after release. When it finds an issue, it comments on the PR or marks the story blocked with a reason.
The loop is the automation
If review requests changes, the implementer goes back to work. It updates the branch, responds to comments, and opens the next revision. The reviewer checks again. Compliance checks again when the change touches its area. The cycle continues until the PR is approved and merged.
After merge, the story still is not done. The implementer updates the story state to done and opens a small PR for that status change. That update can be reviewed too. It sounds fussy until you watch autonomous systems lose track of what they think they finished. State changes deserve the same discipline as code changes because they control what the next agent is allowed to pick up.
Autonomy needs ordinary engineering habits
The useful part of this setup is that it does not ask agents to become magical coworkers. It gives them the same rails engineering teams already use: ownership, pull requests, review comments, approval gates, blocked states, and merge records. The automation works because the workflow is legible.
Different LLM providers can sit in different seats. One may be better at implementation, another at code review, another at policy or compliance checks. That diversity is useful as long as the shared worklist remains the source of truth. Agents can come and go. The story state and PR history keep the system coherent.
The big assumption is still human: someone has to write good stories. Detailed stories are the prompt engineering that actually matters here. They carry intent, constraints, and acceptance criteria into a loop that can run without a person watching every step.
That is the shape I trust most right now. Not a swarm. Not a bot that says it is done. A work queue, a few specialized agents, and enough process that a human engineer can audit the run after the fact without reading tea leaves.