A coding agent can turn a ticket into a pull request while you get coffee. That speed creates a quieter question the tooling never answers for you: once the diff exists, who owns it? Not who typed it, the agent did that. Who is accountable for whether it ships, whether it was the right change, and what happens when it breaks at 2am. Execution moved to the agent. Ownership did not, and it can’t.
The blur gets worse the moment you run more than one agent. Give one bug to Claude Code and another to Codex, and you now have two branches, two summaries, and no shared answer to a simple question: whose name is on each of these when they land? Ownership that lives in a terminal scrollback isn’t ownership. It’s a guess that survives until the next git log.
This is the problem Sharkly is built around. Sharkly sits above your coding agents as the layer that records who assigned the work, which agent ran it, who reviews the result, and who accepts it. This article lays out that operating model as four roles and a set of statuses, then walks one ticket from assignment to a merged PR. For the review mechanics underneath it, our guide to human-in-the-loop coding agents covers the five gates that enforce these decisions.
TL;DR
Human ownership of agent work means accountability for a change never transfers to the agent, even when execution does. The operating model has four roles: a person assigns, an Agent runs, a named human reviews, and that same human accepts. Agents can move a Task as far as Ready for review; only a person moves it to Done. Agents research, execute, test, and report. People set direction, grant authority, and accept the result.
Who owns the work an agent produces
Ownership and execution are two different jobs, and confusing them is the root mistake. Execution is producing the change: reading the codebase, editing files, running tests, opening a PR. An agent does that well and fast. Ownership is being answerable for the outcome: that the change was worth making, that it meets the acceptance criteria, and that someone can be asked about it in three months. That answerability stays with a person, because an agent can’t be asked to justify a tradeoff after the fact or carry the consequence.
The cleanest way to state the split is the human-agent contract: agents research, execute, test, and report; people set direction, grant authority, and accept the result. Automation stops where team judgment is required. Everything up to “accept the result” can be handed to an agent. The acceptance itself can’t, and neither can the decision to release. Our piece on AI assistants vs AI teammates draws the same line from the other direction.
The operating model: assign, run, review, accept
Once you separate ownership from execution, the workflow falls into four roles with one job each. Naming them is what keeps five parallel agents from turning into five orphaned branches.
| Step | Who acts | What they own |
|---|---|---|
| Assign | A person | Deciding the work is worth doing, writing acceptance criteria, and naming who’s accountable |
| Run | An Agent, through a Runtime on a Computer | Producing the change, running tests, and reporting what it did and what’s uncertain |
| Review | The human Assignee | Judging the result against the acceptance criteria and the evidence |
| Accept | The same human Assignee | The decision to merge and release |
The important detail is in the first and last rows: the same person owns assignment and acceptance. That’s how the loop closes. Whoever decided the work mattered is the one who confirms it was done. Sharkly supports this by keeping two assignment slots on a Task at once, a human Assignee and an Agent assignee, so responsibility and execution are recorded as separate facts rather than one ambiguous “assigned to.” For how work reaches the agent, see our guide to assigning, tracking, and reviewing agent work in one place.
Statuses and gates: agents reach Ready for review, people move work to Done
The operating model becomes real when it maps onto Task statuses, because a status change is a decision you can point at later. Here the rule is strict and worth stating plainly: agents can advance work up to Ready for review; only a person moves a Task to Done.
| Status category | Who moves it | Meaning |
|---|---|---|
| Backlog | Person | Not started. Assigning an Agent here runs nothing |
| Ready for work | Person | Moving a Task into this category is what starts the Agent run |
| In progress | Agent | The run is executing in an isolated worktree |
| Ready for review | Agent | The run finished and is waiting for the named human |
| Done / Accepted | Person | A person read the evidence and accepted the result |
Two boundaries protect this. First, an Agent can’t select a status its Task Workflow doesn’t grant it, so it can’t mark its own work accepted. It leaves the Task waiting for human review, and that signal lands in the responsible person’s Inbox rather than a channel nobody reads. Second, merging a linked pull request does not change the Task status. A merge is a Git event, not an acceptance decision, and Sharkly keeps them separate so “the PR merged” is never mistaken for “a person judged this correct.” If review capacity is your worry, our analysis of why human review is the real bottleneck covers how to design for it.
From ticket to merged PR: one worked example
Here’s the model running end to end on a single Task, SH-312, “Add rate limiting to the public search endpoint.”
- Assign. An engineer writes the Task: the endpoint, the target limit, and acceptance criteria (429 on overflow, existing tests still pass, a new test for the limit). She sets herself as the human Assignee and picks the Agent assignee. The Task sits in Backlog. Nothing runs yet.
- Run. She moves
SH-312to a Ready-for-work status. That status change starts the run. The Agent claims the Task, prepares a fresh worktree so this work can’t collide with anything else, reads the description and recent comments, edits the endpoint, adds the test, and runs the suite. - Report. The Agent opens a pull request and posts a comment on the Task: the change summary, the tests it ran and their results, and one honest note that it did not load-test the limit under real traffic. It moves
SH-312to Ready for review. It stops there. It can’t go further. - Review. The waiting-for-review signal reaches the engineer’s Inbox. She reads in order: the acceptance criteria, the Agent’s comment, the execution log, then the diff. The log shows why the run was queued and what tool calls it made, so she’s reviewing the change and not a story about it. The load-test gap is real, so she comments asking for a test at the documented ceiling. That comment enqueues a follow-up run for the same Agent; she doesn’t open a second Task.
- Accept. The Agent adds the test, reports again, and returns the Task to Ready for review. This time the evidence matches the criteria. She merges the PR and moves
SH-312to Done, two deliberate acts by the person who owned the work from the start.
Every step returns to the Task: the run, the PR link, the review comments, the acceptance. Nothing lives only in a terminal. Our guide to reviewing AI-generated code with task-level evidence goes deeper on what to read before you accept.
Where ownership quietly breaks
You don’t need this full ceremony on every Task, and pretending otherwise turns review into theater. Use the light version when work is read-only or trivially reversible: a repository audit or a dependency bump with green tests can go from run straight to a quick acceptance. Use the full four-role loop, with a named human on both ends, whenever a change touches data, alters a public interface, or can’t be undone with one command.
The failure mode to watch for isn’t agents doing too much. It’s ownership going unassigned. A Task with an Agent assignee and no human Assignee has execution without accountability: the orphaned-branch problem dressed up as progress. The fix is one rule everywhere: every Agent Task names a human who owns it. When you’re coordinating handoffs between several agents, our guide to agent-to-agent and agent-to-human handoff patterns shows where the human owner sits in the chain.
Conclusion
Human ownership of agent work isn’t a brake on automation. It’s what makes automation safe to scale. Let agents do the execution, all of it, at whatever speed they can. Keep four decisions with people: what to assign, whether to grant the authority to run, whether the result meets the bar, and whether to release it. Write those decisions down as status changes on a shared Task, so accountability is a fact anyone can read rather than a guess in someone’s scrollback.
If you’re already running several coding agents, Sharkly gives you one place to assign their work, watch it run, and record who reviewed and accepted each result. You can wire this model together by hand with worktrees and a spreadsheet, or download Sharkly and let the Task carry it. For the layer’s full shape, start with coding agent management above Claude Code and Codex.
FAQ
Does human ownership mean a person watches every agent run? No. Ownership is accountability, not supervision. A person assigns the work and accepts the result; the agent runs unattended in between. Watching a terminal doesn’t scale past one agent anyway.
Can an agent mark its own work as done? No. An Agent can advance a Task to Ready for review, but its Task Workflow doesn’t grant it the accepted status. A person reads the evidence and moves the Task to Done.
Does merging the pull request accept the task? No. Merging a linked PR is a Git event and does not change the Task status in Sharkly. Acceptance is a separate status change made by the human owner after review.
Who should own an agent’s task? The person who decided the work was worth doing. Sharkly keeps a human Assignee slot alongside the Agent assignee, so the review signal routes to that person and they accept it.
What happens if no human is assigned? You get execution without accountability. The safe rule is that every Agent Task names a human owner, so a finished run always has someone answerable for it.
