A coding agent that can open a pull request is useful. A coding agent that can merge one while nobody is watching is a liability with commit access. The gap between those two sentences is the whole problem. Once an agent can push to a branch, run tests, and click merge, the question stops being “can it do the work” and becomes “where does its authority end.”
Most teams answer that question by accident. The agent has whatever permissions its runtime was given, the review happens in whatever terminal the run started in, and the record of who approved what lives in one person’s scrollback. That holds until you are running three agents across two repositories and a Friday deploy ships something nobody read. An approval gate is the fix, but only if it is a real checkpoint in a shared system rather than a habit you hope everyone keeps.
That shared system is what Sharkly provides. You already have coding agents; Sharkly turns their runs into Tasks with statuses, Assignees, and a review step a person has to make on purpose. This article walks through the operating model behind that: who assigns work, who runs it, who reviews it, who accepts it, and exactly where the stop belongs so an agent never merges its own change unreviewed.
What an approval gate actually is
An approval gate is a point in a task’s lifecycle where automated execution stops and waits for a person to decide the next step. Not a warning, not a log line you can scroll past: a state the work sits in until a human moves it.
The distinction that matters most is between an agent proposing a change and an agent landing one. Opening a pull request is a proposal. Merging it is a decision about production. Those are different acts of authority, and the second one is where team judgment has to live. Sharkly makes that boundary explicit: even with GitHub connected, merging a pull request does not change the Task status. The merge stays a human action on the record, not a side effect the agent triggers by finishing.
Keep that boundary in mind, because most “the agent broke prod” stories are really stories about a missing gate between proposal and landing.
The operating model: assign, run, review, accept
Sharkly splits a task into four roles, each with one job. The contract is plain: Agents research, execute, test, and report; People set direction, grant authority, and accept the result.
- Assign. A person describes the need and sets the Assignee. A Task carries two separate assignments: the People on it, and a single execution Assignee, which is the Agent or Crew that runs the work. Changing one does not change the other.
- Run. The execution Assignee does the work in an isolated git worktree, so parallel runs don’t touch each other’s files. Progress, blockers, and results return to the Task.
- Review. When the Agent finishes, it leaves the Task waiting for human review rather than closing it. The diff, the test output, and the change summary attach to the Task, not to a terminal.
- Accept. A person reads the evidence and decides: request changes, or accept and merge. Acceptance is the terminal move, and only a person makes it.
The value here is not that Sharkly runs the agent. It is that the four roles stay visible in one place instead of collapsing into whichever terminal happened to be open. For the deeper version of the review half, see human-in-the-loop coding agents.
Make the gate a status, not a habit
A gate you have to remember is a gate you will eventually skip. So encode it in the task lifecycle.
Sharkly’s statuses carry system meaning through their categories. Backlog is a parking state: a Task there does not execute even with an Agent assigned. Moving it into a ready-for-work category is what lets execution begin. Completed is terminal, and reaching it is a human move, not something the Agent grants itself.
Task status is deliberately separate from the Agent’s working state. While the lifecycle status reads In Progress, the Agent underneath can be working, waiting for a human reply, waiting for human review, or reporting an error. That separation is the gate: the Agent can finish its run and surface “waiting for human review” without the Task ever crossing into a state that implies it shipped. The work returns to the Task and stops there until someone accepts it.
This is also what makes multiple agents safe to run at once. When five parallel agents in isolated worktrees all land in the same review column, you have one place to triage them instead of five terminals to babysit.
One worked example: from ticket to merged PR
Walk a single Task through, using Sharkly’s SH-312 identifier shape.
- File it. A person creates
SH-312, a bug task: “Search returns stale results after a filter change.” The description carries the goal, the reproduction, and the acceptance criteria. Assignee: a Claude Code Agent bound to the search repository. - Shape it. The Agent researches the codebase and related history, confirms scope, and posts its plan back to the Task. The person reads the plan and moves
SH-312out of Backlog into a ready status, which is the signal to start. - Run it. The Agent claims the Task and works in a fresh worktree. It writes the fix, runs typecheck and the test suite, and opens a pull request whose title includes
SH-312so Sharkly links the PR back to the Task. - Stop at the gate. The Agent does not merge. It attaches the change summary, the passing test output, and any known limits, then leaves
SH-312waiting for human review. The work has returned to the Task. - Review. A person opens
SH-312, reads the diff and the evidence in one view, and notices the fix touched a shared query helper. They leave a comment asking for a narrower change. On a Task with a ready Agent Assignee, that comment re-enqueues the run, so the request-changes loop stays on the record instead of restarting in a private chat. - Accept and merge. The second run passes review. The person approves the pull request, merges it, and moves
SH-312to Completed. Because merging does not auto-close the Task, the acceptance and the merge are two recorded human decisions, not one automatic cascade.
Every step in that chain is inspectable later, which is the point of a traceable requirements-to-code workflow: you can answer “who approved this, and on what evidence” without archaeology through someone’s scrollback.
Where not to put a gate
More gates are not automatically safer; they add friction that trains people to click through. Put a gate where the cost of a wrong merge is real. For a small, well-defined, low-risk change assigned to a single Agent, the review-before-merge stop is enough, and you don’t need a Crew or extra approval steps layered on top. Add heavier review when the blast radius is large: shared code, migrations, anything touching auth or billing.
The one gate you never remove is the merge gate. An Agent can research, write, test, and propose all day. Whether its change reaches your main branch is a human decision, and it should stay one even when the Agent is right most of the time. Pair Sharkly’s task-level review with your existing branch protection so the platform enforces what the workflow intends, and keep the tools your team already uses: connect GitHub and assign the ticket to an AI agent without rebuilding your process.
If you’re already running several coding agents and losing track of which finished, which failed, and which is waiting on you, that review column is the reason to try Sharkly. Run your existing agents through it and keep the merge decision where it belongs.
FAQ
Can Sharkly stop an agent from merging on its own? Yes. Merging a pull request does not change a Task’s status in Sharkly, so a run ends at “waiting for human review” rather than landing a change. Pair that with GitHub branch protection to enforce required reviews at the repository level.
What’s the difference between task status and agent state? Task status is the lifecycle category (Backlog, Started, Completed, and so on). Agent state is what the run is doing right now: working, waiting for a human reply, waiting for review, or error. A Task can sit In Progress while the Agent waits for you.
Do I need a Crew for every reviewed task? No. For small, well-scoped work, assign the Task to one Agent and use the review-before-merge gate. Reserve a Crew for a goal that needs a leader Agent to coordinate several members.
