The short version
On January 26, 2026, GitHub launched the Agents tab inside every repository — a new tab sitting between Pull requests and Actions.
Sounds like just another tab. It's not.
Before this, Copilot coding agent lived somewhere else. You'd open Copilot chat in a separate surface, kick off a session, and only come back to the repo to review a PR. Two contexts, two mental models.
Now GitHub has moved the AI agent right into the repository navigation, next to Code, Issues, and PRs.
It means GitHub is telling you that AI agents aren't a side experiment anymore — they're part of the normal workflow.
In April 2026, three more updates shipped that change the game: Research, Plan, Code modes, built-in security scanning, and a CLI handoff.
Here's what you need to know, three real workflows, and what to watch out for.
GitHub changed how it thinks about AI agents — put them next to the code
Monday morning. A dev opens a repo to start a new sprint. Normally they see tabs lined up: Code · Issues · Pull requests · Actions · Projects · Wiki · Security.
Now there's one more — Agents — sitting between Pull requests and Actions. Click it and you land on a dashboard showing what the agent is working on, what it's finished, which sessions are waiting for review.
That's a mental shift.
Last year, AI agents were new toys. Nobody knew quite how to use them. You had to open another tab, open a separate chat, copy-paste between windows.
GitHub's answer now is — just put it next to the code. Because an agent isn't a special tool. It's another teammate that helps write code.
This relocation changes how the whole team thinks.
- Agents aren't a "side experiment you try when you have free time." They're a work lane with a status you can check, like a PR.
- Agent sessions have history, the way commits do. You can look back.
- Agent output links straight to PRs. Same flow as review from a human.
It makes agents a first-class citizen in the repo.
What the Agents tab is — a one-minute overview
Launched: January 26, 2026
Location: Repository navigation, between Pull requests and Actions
Who sees it:
- You need Copilot coding agent enabled on the repo
- Available on all paid Copilot plans
- On Business / Enterprise, an admin has to enable it first
What it does: It's the "mission control" for Copilot coding agent.
Mission control means one page where you can see everything the agent is doing in this repo. Start new tasks. Switch between sessions. Archive old ones.
No separate chat window. No hunting through notifications. Everything in one place.
Five things you can do from the Agents tab
1. Start a new session without leaving the repo
Before, firing up a Copilot agent meant opening Copilot chat in another tab. Now you're already in the repo — hit "New task" in the Agents tab and you're off.
Why it matters: fewer context switches. When you have to jump to another tab to tell the AI what to do, your train of thought breaks. Staying on one page means your brain doesn't have to reset.
2. Read the session log — now readable
The session log in the Agents tab isn't a wall of text anymore. It's been redesigned:
- Grouped tool calls — similar calls are grouped, so you don't scroll past 200 lines
- Inline preview rendering — markdown or images render right in the log
- Diff views — file edits appear as diffs without waiting for the PR
- Distinctive icons — each tool has its own icon
- Visible bash commands — every bash command the agent runs is right there
That last one is the biggest deal — you can see exactly what the agent ran.
Before, an AI agent was a black box. You'd say "fix this bug." It would say "done." What happened in between was anyone's guess. Now npm install, a test run, a grep, a git command — you can audit every step.
Transparency equals trust. If an agent is going to be part of your workflow, seeing what it actually does isn't optional.
3. One-click to the PR the agent opened
Inside the session view, there's a link straight to the PR. Click it and you're there.
The whole new flow: start a session → agent works → click through to the PR → review the diff → merge or comment back.
All in one tab. No window juggling.
4. Hand off to the Copilot CLI
There's a "Continue in Copilot CLI" button. Click — copy the command — paste into your terminal — and the session state transfers so you can keep going.
Who'll actually use this: devs who live in the terminal. Some people start in the web because it's convenient, then want to pipe output through their own scripts. Hand off to the CLI. No restart, no re-explaining context.
5. Archive and manage history
Finished sessions can be archived. You can page through old ones.
The payoff: you start seeing patterns. A team that's been using agents for a few months notices which kinds of tasks the agent handles well, which prompts are effective, which ones waste time.
History is your team's improvement data.
April 2026: Research, Plan, Code modes
In April 2026, GitHub pushed a big update that changes how you work with a Copilot agent at a basic level.
Before: Copilot agent = write code, open PR
The old model was straightforward: tell the agent → agent writes code → agent opens a PR → you review.
The problem — everything had to go through a PR. If all you wanted was for the agent to "read the codebase and tell me how we handle auth," it still had to open an empty PR first. Not flexible enough.
Now: three modes
Research mode — ask a big question, let the agent research the repo. Example: "Map out where we handle authentication across this repo, and which pattern is used the most." Agent reads the code and comes back with a summary. No PR.
Plan mode — ask for an implementation plan, for you to review. Example: "Plan how we'd refactor the data layer to use the repository pattern." Agent drafts a plan. You read it, edit it. Once it looks good, the agent goes to write code.
Code mode — write code on a branch. A PR is now optional. The new branch-only mode generates code on a branch without opening a PR — great for experimental work. There's also self-review via the Diff button — the agent reviews its own work before handing off.
Natural language control
You can now drive agent behavior through natural language in the prompt:
- "Create a pull request when done"
- "Don't open a PR — just push to the branch"
- "Review your own diff first before submitting"
No config file. No settings toggles. Just plain English.
Built-in security
This is the feature I (wearing my Software House hat, helping clients with PDPA compliance) like the most.
Every PR the agent opens goes through a security scan first:
- Code scanning — looks for security anti-patterns
- Secret scanning — catches tokens or keys left in code
- Dependency vulnerability check — flags CVEs in any package the agent added
Why it matters: AI-generated code has real risks — copying deprecated patterns from training data, pulling in a library with a known CVE, hard-coding secrets because the example did. GitHub scans before the PR even opens.
Organization controls (April 2026)
Another early-April update:
- Default runners or self-hosted runners for the org
- Faster performance
- Access to internal resources — the agent can reach internal registries and APIs via the runner
Important for enterprises with private code behind a firewall.
How to actually use it — practical workflows
Scenario 1: bug report from a user
A user reports a bug — "I delete a record but it still shows up in the list. Only disappears after refresh."
New flow:
- Create the issue as usual
- Assign the issue to the Copilot agent through the Agents tab
- The agent researches — which component loads the data, where is cache invalidation handled
- The agent plans — tells you where it thinks the fix should go
- The agent implements — writes the code and a test
- The agent opens a PR (after passing security scan)
- You review the diff, then merge
What used to take two or three hours becomes a twenty-minute review.
Important: actually review it. Don't just skim.
Scenario 2: big feature, approach unclear
The PM sends over a big spec — "We want to add multi-tenant support." A senior dev usually spends days just understanding how the current codebase handles authentication, authorization, and data isolation.
New flow:
- Tell the agent (Research mode): "Summarize how we handle tenant isolation today."
- Agent researches for 10–15 minutes, comes back with a summary
- Tell the agent (Plan mode): "Write a plan for adding multi-tenant support given the current state."
- Agent plans → you review → edit → approve
- Tell the agent (Code mode, branch-only): "Implement steps 1–3 of the plan on branch
feat/multi-tenant."
- Review the output — if it looks good, have it open a real PR
You get speed without losing control.
Scenario 3: cross-repo refactor
Your team has five repos with similar patterns. You need to swap out the logging library everywhere.
New flow:
- Start a session in the Agents tab of each repo
- Give them all the same prompt: "Migrate logging from library A to library B following our pattern."
- Watch the progress in each session
- Review each PR, merge them one at a time
Having an Agents tab per repo makes it easy to track — no hunting around to remember which session lives where.
What to watch out for
1. AI-generated code still needs review
Don't merge without reading it. The agent is getting better, but it still writes code that looks correct while the business logic is wrong. Edge cases the agent doesn't know about — because they aren't in the code. Human review is not optional.
2. Security scanning isn't a guarantee
Code scanning, secret scanning, vuln checks all help. But:
- Logic bugs — the agent writes a function that compiles, tests pass, but returns the wrong value. No scan catches that.
- Business rule violations — the agent doesn't know that records from another company should never be exposed.
- Privacy concerns — PDPA-related issues need a human who speaks the language and context.
Security scans are a safety net, not a replacement for review.
3. Cost
Copilot coding agent burns tokens by plan, and a big session uses quite a few. A large team using it heavily will see the bill climb. Track consumption monthly; set a budget per person or per team.
4. Team discipline
You need a guideline: which tasks go to the agent (boilerplate, refactor, research), which tasks a dev does (critical business logic, security-sensitive work, client data handling), and when to review more rigorously than usual. No guideline, and the team uses the agent inconsistently — quality gets uneven.
5. Branch hygiene
The agent creates a lot of branches. Without cleanup, the repo fills up with dead ones. Set a policy: agent branches with no activity for 14 days auto-delete.
For a Software House team (like Enersys)
I work at Enersys — a software house focused on Odoo ERP, Enterprise AI, and PDPA compliance for a mix of clients. For us, having GitHub move agents into the main workflow has clear upside:
- Faster iteration: client asks for a small feature → agent drafts → dev reviews → client sees a prototype faster.
- Knowledge transfer through the log: an agent session log is documentation in disguise.
- Onboarding new devs: instead of raw code, have them read agent sessions from real tickets — they see problem, solution, and pattern together.
- Built-in quality gates: code scanning helps enforce PDPA compliance — catches hard-coded personal data or stray secrets.
- Cost discipline: track where agents are spending tokens — which tasks are worth it, which should stay with humans.
We don't think AI will replace devs. We think AI lets devs focus on work that matters — boilerplate, research, first-pass review go to the agent. Client business context, architectural judgment, and stakeholder trust stay with the dev.
Takeaways
The GitHub Agents tab isn't a blockbuster new feature. It's a relocation that changes the mindset.
Before: AI agent = an extra tool somewhere else. Now: AI agent = part of the repo, on par with Code, Issues, and PRs.
When the agent lives next to PRs, devs treat agent sessions like PRs — with status, history, review process, archive. The April 2026 update adds Research / Plan / Code modes plus built-in security scans, making the whole thing more flexible and safer.
Recommendations for teams:
- Turn on Copilot coding agent on one or two repos before rolling out org-wide
- Write a guideline for which tasks go to the agent vs. a dev
- Use Research mode more — don't jump straight to Code mode
- Audit session logs once a week — see what your team is doing with it
- Don't lower review standards just because "we have security scan now"
None of this is a job-killer for devs. It's a divider — between devs who know how to use the tool and devs who don't. The ones who know will move faster.
Sources
