Chaining GitHub Copilot Custom Agents: Automating Your Dev Cycle

Imagine having a brainstorming session with your AI, sketching out a plan, handing it off to a @develop-agent, and then heading to your standup. When you return, a pull request will be waiting, complete with code, tests, documentation, and a review summary. No babysitting required. Just results.

This explores whether GitHub Copilot custom agents can be chained to run independently, mimicking a complete dev-test-doc-review cycle. The answer is yes, but the path there involves some unexpected challenges and discoveries.

TL;DR

• GitHub Copilot custom agents can be chained to create an autonomous dev workflow (develop → test → document → review)
• In the cloud (github.com/copilot/agents), it works surprisingly well, but hits a 59-minute timeout
• Running locally requires explicit use of the `runSubagent` tool to maintain proper isolation
• A DevContainer setup provides a safe “YOLO environment” where you can pre-approve tool usage
• Handover files between agents are key to maintaining context across independent phases
• All tests were conducted using Claude Sonnet 4.5 with Agent mode
• Fork or copy my repository and try the following prompt in cloud-agent or locally

@develop-agent Task: {Your special task to be used}
- Remember to follow the orchestration workflow as described in the repository
- Run subagents for each phase

Keep the human in the loop, but only where it matters. Not as a glorified button-pusher.

Why Separate Agents?

Before diving into the experiments, let’s address the elephant in the room: why not just write everything in one massive custom-agent file?

The answer is rooted in a core principle we’ve learned from software development: small, incremental changes always outperform big, upfront designs. By breaking down different phases into separate agents, each can function independently, without being influenced by the context or instructions from a previous one. This approach enables you to provide each agent with specific instructions or incorporate external resources through MCP servers, without affecting the rest of the workflow.

Personally, I find large custom-agent files, like AGENT.md or copilot-instruction files, difficult to work with and harder to maintain. I prefer to think in small, manageable chunks, solving one issue at a time, just as we’ve always done in our engineering culture. This approach not only makes the code easier to maintain and test, but it also avoids the common pitfall of trying to steer an agent back on track only to have it fail elsewhere in the system. If things don’t work as expected, it’s easy to pivot and merge everything together when necessary 🙂

Setup

Create a `.github/agents` folder where you describe the specific agents and the workflow you want them to follow. Full working files can be found at https://github.com/UnclesLibrary/agentic-workflow-blog:

• develop-agent – Implements features and writes code
• test-agent – Tests implementations independently
• document-agent – Creates comprehensive documentation
• review-agent – Reviews all work and provides feedback
• workflow-architecture – overview of how the chaining of agents can look
• workflow-example – example to implement a simple calculator as a reference
• workflow-orchestrator – actual orchestration with described handover steps

Each agent would hand off to the next using explicit markers and handover files containing the necessary context. It is about the flow, actual instructions how you want your agent to behave can be adjusted to your specific needs.

Experimenting with the Cloud Agent

Testing at http://www.github.com/copilot/agents yields surprisingly good results. Copilot understands the flow and creates separate steps by using the ‘begin’ and ‘end’ custom agent markers.

Starting with a simple prompt:

@develop-agent Task: Create a simple calculator function that supports addition, subtraction, multiplication, and division operations.

The good news? It works. The bad news? The task is too simple; it doesn’t trigger the review loop where the review agent would instruct the development agent to do some refactoring.

Getting more explicit with the instructions:

@develop-agent Task: Create a simple calculator function that supports addition, subtraction, multiplication, and division operations.
- Remember to follow the orchestration workflow as described in the repository
- When targeting the @review-agent please instruct the refactor instructions  "create isolated functions for all arithmetic functions for the sake of maintainability"

The workflow kicked into gear, agents passed handover files back and forth, and the review agent actually requested refactoring. The develop-agent made the changes, and the cycle continued.

All of this for just one premium request. Pretty cool. You can even hook up a MCP to a Copilot Spaces to instruct your review agent on the fly🤔, or maybe you want it to fetch some scanning results from an external tool.

The 59-Minute Wall

GitHub’s coding agents can only run for 59 minutes before timing out. This is GitHub-controlled and cannot be extended. The workaround? Surprisingly simple: “You ran into a timeout, you can continue where you left off.” That’s it. Copilot picks up where it left off (okay, that’s two premium requests now, but still manageable).

Testing a different prompt

When sharing the initial results with some colleagues, they also tried a different approach by just giving the task without explicit flow instructions, yielding a different result.

I want to create a PowerShell script that will run on my Windows 11 laptop. It needs to search my local LAN (multiple subnets) for all devices it can see. Then find out what kind of device it is and look for API endpoints exposed by the device. Devices can range from IoT hubs (e.g., Home Assistant) to IoT devices (Shelly) or even security devices (Ubiquity, with NVR and such).

This time, the agents weren’t triggered at all. The handover was written but the flow never triggered.

It took adding explicitly the @develop-agent Task: prefix and include: - Remember to follow the orchestration workflow as described in the repository to get the agent phases to trigger.

Lesson learned: You need to be explicit about invoking the workflow.

In both scenarios, the cloud agent created nice handover files from one agent to the other, maintaining context across the independent phases.

Running local: Escaping the Timeout

The 59-minute timeout limitation makes running the workflow locally an attractive option. After all, if it works so smoothly in the cloud, local execution should be straightforward, right?

Wrong. So very wrong.

Attempt 1: The Approval Hell

Running the exact same instructions locally doesn’t trigger the workflow as expected. Instead, Copilot repeatedly requests approvals. Between stages, repeatedly typing “continue” becomes necessary. By the time the review agent is reached, the initial instructions about refactoring have been forgotten.

Worse, this creates exactly what the workflow aims to avoid: becoming a glorified button-pusher for the AI. Instead of freeing up time for other tasks, it chains you to your desk.

Attempt 2: The DevContainer “YOLO Environment”

Here’s where things get interesting. Creating a DevContainer that can run locally or in GitHub Codespaces provides an isolated environment where all tool approvals can be set to “always allow” without the fear of Copilot accidentally deleting critical folders or causing other catastrophic issues.

Important security note: Perform this action only in an isolated container. Never set blanket approvals in your main user space. A DevContainer provides the isolation you need to experiment safely while keeping your actual system protected.

The DevContainer setup is functional, providing a “YOLO container” that runs in isolation, allowing agents to operate freely. If the AI were to break the container, that would be something I could live with.

The Max Requests Setting: A Hidden Gotcha

VS Code has a Chat > Agent: Max requests setting that defaults to 25. This means after 25 agent requests, Copilot will pause and ask if it can continue. For longer-running operations, this becomes a problem. The workflow gets interrupted mid-execution, defeating the whole purpose of autonomous operation. Increasing this to 50 gives the workflow more breathing room. Keep in mind, though, each of those requests is a premium request, so there’s a trade-off between convenience and cost. Set this thoughtfully based on workflow complexity and budget.

You can find this setting in VS Code under Settings → Chat → Agent: Max requests.

Attempt 3: Pretending to Hand Over

When running the instructions locally, the feature and cycle were completed quite quickly. That caused suspicion. When debugging the issue, Copilot gave the following answer when asked how it used the context between agents.

Result: Shared context. Everything was faster because it didn’t need to regather context every time, the handovers were lost, and a clear separation of concerns was not to be found. The whole point of independent agents evaporated.

Attempt 4: The SubAgent tool Breakthrough

Even with the DevContainer and the max requests setting adjusted, context issues persist. The breakthrough comes from a key discovery. Abandoning the approach of instructing Copilot on how to handle its own context and explicitly telling it to use the runSubagent, the tool resolves the issue:

- Remember to follow the orchestration workflow as described in the repository
- When targeting the @review-agent please instruct the refactor instructions  "create isolated functions for all functions for the sake of maintainability"
- Run subagents for each phase

Everything came alive.

Each agent ran in true isolation. Handover files were generated properly. The workflow hummed along without constant babysitting. This instruction set worked in both cloud agents and the local setup.

The Prompt File Mystery

Capturing this in a prompt file to call it using /orchestrator "do this for me" format seems like the logical next step. Attempting with this configuration:

---
name: orchestrateAgentWorkflow
description: Orchestrate tasks across develop, test, document, review agents
argument-hint: taskDescription
---
You are orchestrating a complete development workflow using custom agents
in local mode. Run each phase as an isolated subagent and pass explicit context forward.
## Orchestration Prompt
@develop-agent Task: {taskDescription}
- Follow the orchestration workflow described in this repository
- You should run subagents for each phase
## Notes
- Each subagent runs in an isolated context; pass explicit summaries and artifacts
- Always include working directory and commands when relevant (e.g., how to run tests)
- Keep changes minimal and focused; repository conventions

For reasons not yet fully understood, instructions keep failing when captured in this prompt file format. The explicit prompt works, but somehow, instructions are now misunderstood in comparison with the simple direct prompting before. This remains an open mystery requiring further investigation.

Cloud vs. Local: Different Trade-offs

• Cloud agents (github.com/copilot/agents):
  • Work more smoothly out of the box
  • Hit a 59-minute timeout (but can be restarted)
  • Don’t require local setup (just fork my repo into your own, and start with a cloud-agent to test)
  • Consume premium requests and action minutes
• Local agents:
  • Require explicit SubAgent usage
  • No timeout restrictions
  • Need DevContainer for safe automation
  • Consumes more premium requests, but no agent minutes

The Bottom Line

Can you chain GitHub Copilot custom agents to run independently and mimic a complete dev cycle? Absolutely.

Is it plug-and-play? Not quite yet. However, with the right setup, explicit instructions, SubAgent usage, and proper isolation, you can create a workflow where the AI handles the mundane tasks while you focus on the decisions that truly require human judgment.

The goal isn’t to remove humans from the process. It’s to remove humans from the tedious, repetitive parts that don’t need human judgment. Code reviews? That needs a human. Clicking “continue” fifty times? That’s what computers are for.

Have fun coding, or rather, have fun while your agents code for you.

All experiments were conducted using Claude Sonnet 4.5 with Agent mode enabled. Repository with full agent definitions and examples available at https://github.com/UnclesLibrary/agentic-workflow-blog

Q & A

• Why didn’t you use the handoff instruction?
  The handoffs are a Visual Studio Code implemented feature that will give you the option to hand over to a new agent.
• Is the @xxx-agent an official way to call other agents?
  No, it isn’t, but that is what Copilot suggested I use out of the box when I started brainstorming this idea, and it seems to work well.
• There are numerous files in the agent folder. What is the minimum viable product to be implemented?
  To be honest, I’m not entirely sure. I noticed that the workflow instructions really help as a reference to the AI of what is required. I also noticed that when you leave the phases out of the actual custom-agent files, the flow will not work or becomes very hard to trigger.
• The prompt files didn’t work, but what about GitHub Issues?
  The GitHub Issues are giving the same issues as using prompt files. However, you can offset this quite well, but no guarantees, by instructing Copilot during the handover with
  
- Remember to follow the orchestration workflow as described in the repository
- Run subagents for each phase