An engineering lead can now run most of an agent coding task without leaving GitHub. Assign an issue to Copilot, wait for the pull request, have a reviewer approve and merge it, and the board can move the card to Done. Since GitHub's documentation says that, starting October 28, 2026, the new Copilot in the cloud experience is available to users with a paid Copilot plan, subject to organisation and enterprise policies, that loop is now within reach of any team on a paid plan whose policies allow it. It is convenient, and for many tasks the convenience is the point.
The question this guide asks is narrower. When the repository, the agent, the issue, the review and the project board all live on one platform, what actually decides that the task is finished? On a default GitHub setup the answer turns out to be a merge, followed by two automations nobody had to switch on. That is a reasonable answer for a great deal of code. It is a weaker answer when the people relying on the work were never in the review, or when the task was defined by something other than the diff.
This post holds one altitude: the GitHub-native path from an issue assigned to Copilot to a Done status, and what a separate, evidenced done decision adds. It cedes the general split between a merge gate and a done gate to our coding agent review queue guide, merge-triggered Done in Linear to our Linear alternative comparison, the grading of session logs and signed commits to our guide to coding agent evidence, and branch, approval and firewall controls to our cloud agent isolation guide. The reader we have in mind is an engineering lead or a Head of Delivery who has to sign off agent work for people outside the repository.
This guide is shipped by the team behind Cognibl, from DILR.AI, a work tracker where people and cloud AI agents share one board and no task reaches done without proof of work. Or see DATS, our five-stage method for placing AI inside enterprise delivery.
What does the GitHub Copilot coding agent do well in 2026?
The GitHub Copilot coding agent does its best work for teams whose code, issues and reviews already sit on GitHub. A developer can start a Copilot task by assigning an issue, by writing a prompt or by seeding a new repository, then steer one session across the web, mobile, the IDE and the command line. The agent works on its own branch, opens a pull request and asks a person for review.
That is a genuinely short path from intent to a reviewable change. GitHub's guide to starting Copilot sessions says that assigning an issue always creates a pull request, and that Copilot works on the task and requests your review when it finishes. Nobody has to copy context from a ticket into a chat window, and nobody has to wire a third-party agent into the repository. For a team that already treats GitHub as its system of record, that removes a whole category of integration work. Our AI developer productivity page sets out how we think about agent tooling inside engineering teams.
The controls around the agent are also worth knowing in detail. Copilot pushes to a single branch, cannot approve or merge its own pull request, and by default its code does not trigger Actions workflows until a person with write access approves the run. We return to those controls below, briefly, because they govern the merge. The rest of this post is about what happens after it.
How does an issue assigned to Copilot reach Done on GitHub?
An issue assigned to Copilot reaches Done on GitHub through a chain of default behaviours. Copilot opens a pull request; a person reviews and merges it; if that pull request is linked to the issue and targets the default branch, the issue closes; and a GitHub Project marks closed issues and merged pull requests as Done through two workflows that are switched on when the project is created.
Each link in that chain is documented separately, which is why teams rarely see it as one decision. GitHub's page on linking a pull request to an issue says that when you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed. The link can come from a keyword such as closes, fixes or resolves in the pull request description, or from the sidebar. The keywords are interpreted only when the pull request targets the default branch; on any other branch they are ignored and the merge has no effect on the issue.
We could not find a statement in GitHub's Copilot documentation that the pull request Copilot opens from an assigned issue always carries a closing keyword or a manual link. So the honest version of the chain is conditional: when the pull request is linked to the issue, the merge closes it. Check a few of your own Copilot pull requests before assuming either way.
The final link is the project board. GitHub's documentation on the built-in project automations puts it plainly: "When your project initializes, two workflows are enabled by default: When issues or pull requests in your project are closed, their status is set to Done, and when pull requests in your project are merged, their status is set to Done." Nobody on the team chose that rule. It arrived with the project.
Read top to bottom, the diagram shows something useful. Exactly one step involves a human judgement, the approval and merge, and that judgement is about whether a code change should enter the codebase. Every later step is automation reacting to the merge. If the merge was the right call, the board is right. If the change merged cleanly but did not do what the issue asked, the board is wrong in the same click, and nothing downstream checks it.
That is not a flaw in GitHub. It is a design choice that equates an accepted change with finished work, and for a bug fix whose whole definition is the diff, that equation holds. The proof of done guide explains why it holds less well for work whose definition sits outside the code.
Which GitHub controls govern the merge, and which govern completion?
GitHub's controls on the Copilot coding agent govern the merge rather than completion. The agent cannot approve or merge its pull request, the person who asked for the change cannot approve it, and workflows wait for a person's approval. None of those controls asks whether the task described in the issue was done, because in the default path described above, completion follows from the merge.
GitHub's risks and mitigations page lists the separation of duties in detail: Copilot pushes to a single branch, draft pull requests it creates must be reviewed and merged by a human, and the user who asked Copilot to create a pull request is prevented from approving it, to keep the required-approvals rule and branch protection meaningful. GitHub's guide to reviewing Copilot output adds that if a repository requires approvals, your approval of a Copilot pull request will not count toward the required number, so another reviewer must approve before it can be merged. Those are good controls, and the isolation guide compares them with other vendors, so we do not repeat that comparison here.
One setting deserves a closer look, because it moves the reviewer onto the same platform as the author. According to GitHub's page on Copilot code review, every Copilot review includes an approval assessment, and by default Copilot's reviews do not count toward required approvals. When Copilot approvals are switched on in repository, organisation and enterprise settings, Copilot can submit an approving review that satisfies the required-approval rule the same way a teammate's approval would, and new commits dismiss it. The page does not say how that setting interacts with a pull request Copilot itself wrote, so treat that combination as a question to test in your own organisation, not an assumption either way.
Put together, a team can end up with an agent from one vendor writing the change, a reviewer from the same vendor assessing it, a platform log recording the session, and the same platform's automation declaring the task done. Each control is sensible on its own. The gap is that the only evidence of completion is the merge itself, and the AI operating model a team adopts should say who signs that off when it matters.
What does Copilot know about the definition of done when it starts?
Copilot knows what the issue said at the moment it was assigned, and nothing written afterwards. GitHub says Copilot receives the issue title, description and existing comments at assignment time, and does not see comments added later. So the definition of done for a Copilot task is whatever the issue contained when the assignment happened, and a reviewer should judge the pull request against that text.
The detail comes from the same Copilot sessions guide, which says follow-up information should go on the pull request instead. That has a practical consequence. A product manager who clarifies acceptance criteria in an issue comment after assignment has clarified them for the humans, not for the agent, and a reviewer who reads the issue thread may be checking the change against criteria Copilot never saw.
The fix is unglamorous. Write the done-test into the issue description before assigning it, in terms a reviewer can check: which behaviour changes, which test proves it, what must not change. Written that way, the reviewer and the agent read the same brief. Our AI placement diagnostic starts from the brief for the same reason.
The same discipline sits at the centre of our AI agent task verification guide, which covers who should do the checking. The point here is narrower: on GitHub, the agent's brief is fixed at assignment, and the board can later record Done without itself checking the work against that brief.
How does Cognibl decide that a coding task is done?
Cognibl, from DILR.AI, decides that a coding task is done only when proof of work is attached, and refuses the status change otherwise. In Cognibl, proof of work is a CSV, the documents it references and, for code, a coverage report. Agents running on Claude Code or Codex open a pull request, only a person can merge, and a merge moves the task one status forward, never straight to done.
Cognibl is described on the Cognibl product page as a work tracker where people and cloud AI agents share one board. The page says agents push through Cognibl's git proxy, which refuses a push to the base branch, and that merge is a console button only a person can press. Merging is also refused while a branch clashes with its base, checks are failing or changes are requested. Five GitHub signals become one status per pull request, and the merge moves the card one step. Completed, the done status in every ready-made workflow, needs a proof of work.
The rule is the same for people and agents, and the refusal says what is missing. A run that ends without proof does not quietly stop: the task moves to Blocked with the comment "Run ended without proof." so somebody looks at it. That is the inverse of the default GitHub path, where a merged pull request that is linked to its issue can land as Done with nothing attached, as long as the default project workflows are on. The phrase proof of work, used here in Cognibl's own sense, has nothing to do with cryptocurrency mining.
Proof is checked in three layers, cheapest first. Deterministic checkers decide what a machine can decide outright, such as the template format, the required files and the thresholds. The AI verification flow then reads the proof against the definition of done and writes the summary a reviewer starts from; like Cognibl's project status flow, it summarises and flags but never decides. Finally a person reviews a share of the passes, sized by the agent's score. Cognibl keeps a reference and a content hash for the referenced files rather than a second copy, and editing proof creates the next version. Proof files can still contain personal data, such as names in a test export, so the usual UK GDPR questions about access and retention apply to them as to any other work record. The record of what an agent called is written by the gateway, append-only and hash-chained, and redacted at capture, as cognibl.com describes it.
The same evidence-first logic underpins our AI execution office, a senior-led delivery function that keeps agent work tied to the outcome a business signed off.
Copilot on GitHub and Cognibl side by side
The table compares the two paths on the questions an engineering lead asks before signing off agent work. GitHub facts come from GitHub's documentation as fetched on 12 November 2026; Cognibl facts come from its live product pages on the same date.
| Question | GitHub Copilot coding agent | Cognibl, from DILR.AI |
|---|---|---|
| How a task starts | Assign an issue, write a prompt or seed a repository | Assign a task to a named agent, as you would a colleague |
| Which agent runs | Copilot | Claude Code or Codex, one microVM each |
| Where the done-test lives | Issue text and comments at assignment | The task's definition of done, which the proof is read against |
| Who merges | A person; the requester's approval does not count when approvals are required | Only a person, from the console |
| What the merge does | Closes a linked issue on the default branch; default Projects workflows set Done | Moves the task one status forward, never to done |
| What decides done | The merge, through default automation | An attached proof of work; otherwise the change is refused |
| A run with no evidence | Can reach Done if merged, when linked and the default workflows are on | Moves to Blocked with a comment |
| Where it fits best | Code, issues and review all on GitHub | Teams that need evidence behind each completion |
One row shows agreement and three show the difference. The fourth row shows both products agree a person must merge. The fifth, sixth and seventh rows show where they part: on the default GitHub path, completion follows from the merge; in Cognibl, completion is a separate decision with its own evidence, and a run without it stops at Blocked. The Devin comparison and the Cursor comparison reach the same row from different starting points.
When is the GitHub Copilot coding agent the better choice?
The GitHub Copilot coding agent is the better choice when a task is fully defined by the code change, when everyone who relies on the result can read the pull request, and when the team already runs its planning on GitHub Projects. In that setting the merge is a reasonable proxy for done, and in our view a second tool adds a step without adding much assurance.
There are other cases where staying on GitHub is right. Cognibl links GitHub repositories today, with GitLab and Bitbucket planned, so a team on either of those is not a fit yet. Cognibl's pages list Claude Code or Codex as its agents, not Copilot, so a team committed to Copilot as its agent would be running two agent stacks. And a team that wants agents to merge their own pull requests will find Cognibl refuses that by design.
GitHub also lets a team loosen the merge-equals-done coupling without changing tools. The built-in project workflows can be edited or switched off from the project's Workflows menu, so a lead can stop merged pull requests from setting Done and move items by hand after a check. That is a fair halfway house, though it relies on a person remembering the check rather than a rule that refuses the move.
If your team sits in this camp, invest in the merge gate. The evaluation harness write-up shows how to make that gate test behaviour, and our approach to placing AI starts from the test rather than the tool.
What is the best GitHub Copilot coding agent alternative in 2026?
The best GitHub Copilot coding agent alternative in 2026 depends on what the team needs a done status to mean. For code-only tasks reviewed inside GitHub, Copilot with required approvals is hard to beat. For work that other people must trust without reading the diff, the better choice is a tracker that refuses done without attached evidence, such as Cognibl, from DILR.AI.
Three criteria separate the options, whether the team plans in Jira, Linear, Asana or Notion today. First, where the brief is fixed: an alternative should hold a written definition of done that the reviewer and the agent both read. Second, what the merge means: it should be one step in the task, not the end of it. Third, what a run without evidence produces: a blocked task someone looks at, rather than a Done status nobody questions.
Other tools meet some of these. As our neighbouring comparisons describe, Devin and Cursor run their own agents with their own review flows, Linear can route a merge to a status, and Jira can require a field before a transition, which our Jira with Rovo comparison examines. Cognibl's case is narrower and checkable: it puts the refusal in the status change itself, for people and agents alike. It concedes the integrated single-platform loop to GitHub, and that concession is real.
Frequently asked questions
Does Cognibl run the GitHub Copilot coding agent?
No. Cognibl, from DILR.AI, runs cloud agents on Claude Code or Codex, each in its own microVM, and the GitHub Copilot coding agent is not among the agents its product pages list. Cognibl links GitHub repositories, so its agents open branches and pull requests there, and only a person can merge. A team that wants Copilot specifically as its agent would keep using it on GitHub.
Can a GitHub Project stop marking merged work as Done?
Yes. GitHub Projects ship with two built-in workflows switched on by default, one setting closed issues and pull requests to Done and one setting merged pull requests to Done. Either workflow can be edited or disabled from the project's Workflows menu, so a merge or a close no longer sets Done through it, and the team can move items after whatever check it requires.
Can Copilot approve its own pull request?
The Copilot coding agent cannot approve or merge its own pull request, according to GitHub's risks and mitigations documentation, and the person who asked for the change cannot approve it either. Separately, Copilot code review can count toward required approvals when Copilot approvals are switched on in repository, organisation and enterprise settings, and GitHub's page does not say how that applies to Copilot's own pull requests.
Want to see the proof rule in practice? Read our guide to agent work management, open Cognibl on cognibl.com, see our DATS methodology, or browse more AI strategy guides from the team. If a sign-off question is blocking a rollout, talk to our engineers or read about Dilr.ai.
Make done mean proved, not merged.
30-min scoping call · No deck · Confidential. We will look at how your agent work is signed off today and where evidence should sit.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.