--- title: "Copilot Agent Mode vs. Cloud Agent: Automate Your DevOps Backlog" description: "GitHub Copilot agent mode vs the cloud agent: which backlog items to delegate, how to write async-ready issues, and how to cap the review queue." canonical: "https://adamtheautomator.com/github-copilot-agent-mode-vs-cloud-agent/" --- # Copilot Agent Mode vs. Cloud Agent: Automate Your DevOps Backlog > GitHub Copilot agent mode vs the cloud agent: which backlog items to delegate, how to write async-ready issues, and how to cap the review queue. Source: https://adamtheautomator.com/github-copilot-agent-mode-vs-cloud-agent/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Copilot Agent Mode vs. Cloud Agent: Automate Your DevOps Backlog](https://adamtheautomator.com/wp-content/uploads/publisher/4065d9c85b2b81fa8f07fcb190d60bd6/cb069ef52cd49af9b896cfac2ba510145d7ec0576d41d2297dad95219ab96f06.webp) # Copilot Agent Mode vs. Cloud Agent: Automate Your DevOps Backlog [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)29 October 202613 min. read Categories: [AI Agents](/category/ai-agents/) Tags:[GitHub](/tag/github/)[GitHub Actions](/tag/github-actions/)[DevOps](/tag/devops/)[AI](/tag/ai/) Table of Contents * [Four Surfaces, Two Execution Models](#four-surfaces-two-execution-models) * [Who Holds the Loop](#who-holds-the-loop) * [Two Limits That Shape Your Issue Text](#two-limits-that-shape-your-issue-text) * [A Faster Backlog Needs a Wider Exit](#a-faster-backlog-needs-a-wider-exit) * [The Ratio to Watch](#the-ratio-to-watch) * [Score an Item Before You Delegate It](#score-an-item-before-you-delegate-it) * [Sorting the Queue with gh](#sorting-the-queue-with-gh) * [Write the Issue an Async Agent Can Finish](#write-the-issue-an-async-agent-can-finish) * [Split by Validation Command](#split-by-validation-command) * [Worked Example: One Failing Deploy Workflow, Two Ways](#worked-example-one-failing-deploy-workflow-two-ways) * [The Synchronous Pass: Agent Mode in the Editor](#the-synchronous-pass-agent-mode-in-the-editor) * [The Asynchronous Pass: The Cloud Agent](#the-asynchronous-pass-the-cloud-agent) * [What the Difference Costs You](#what-the-difference-costs-you) * [Per-Item Economics: Credits, Runner Minutes, and Reviewer Hours](#per-item-economics-credits-runner-minutes-and-reviewer-hours) * [Build the Cost per Merged Pull Request](#build-the-cost-per-merged-pull-request) * [Where Manual Work Stays Cheaper](#where-manual-work-stays-cheaper) * [Guardrails for an Agent That Can Edit Your Pipelines](#guardrails-for-an-agent-that-can-edit-your-pipelines) * [The Approval Rule That Surprises Teams](#the-approval-rule-that-surprises-teams) * [Tool Autonomy Without a Prompt](#tool-autonomy-without-a-prompt) * [Cap the Review Queue First](#cap-the-review-queue-first) * [The Division That Sets the Cap](#the-division-that-sets-the-cap) * [What Not to Hand Over](#what-not-to-hand-over) * [Run a Four-Week Pilot and Let the Numbers Decide](#run-a-four-week-pilot-and-let-the-numbers-decide) * [Where the Backlog Actually Shrinks](#where-the-backlog-actually-shrinks) Prove your review queue can absorb one more pull request before you hand an agent a backlog full of them. The choice comes down to a capacity calculation and which of GitHub Copilot’s two execution models gets you there. One keeps you inside the loop in your editor, approving commands as they run. The other turns a written issue into a branch, a pull request, and a review request while you sit in a meeting. Both close backlog items at different cost, and leave reviewers holding different amounts of work. Four surfaces feed those two models, and only one of them runs without you. ## Four Surfaces, Two Execution Models You type, Copilot renders ghost text at the cursor, and Tab accepts it. That loop never leaves your keyboard, and [inline suggestions](https://code.visualstudio.com/docs/editing/ai-powered-suggestions) remain the surface most engineers touch all day. Chat reads instead of writes: paste a failing step, ask why the deploy job targets the wrong resource group, and it answers from your workspace. Agent mode changes the contract. You hand it a task, it picks the files, streams edits into the editor, and proposes terminal commands. GitHub’s documentation for [agent mode](https://docs.github.com/en/copilot/how-tos/copilot-in-your-ide/use-copilot-agents/use-agent-mode) lists VS Code, Visual Studio, JetBrains IDEs, Xcode, and Eclipse, and states that by default you approve each command before it runs. The cloud agent drops the editor entirely. GitHub’s [documentation on Copilot surfaces](https://docs.github.com/en/copilot/concepts/copilot-surfaces/copilot-on-github) puts the mechanics in one sentence: “Copilot cloud agent can research a repository, plan changes, and implement them in the background. It can edit files and run tests and linters in an ephemeral cloud development environment, rather than your local IDE.” | Surface | Where it runs | Who approves each step | Item shape it finishes | | --- | --- | --- | --- | | Inline suggestions | Editor, at the cursor | You, by accepting or ignoring | One-line null check, rename, missing import | | Chat | Editor or GitHub.com | Nobody, it only answers | “Why did the deploy step fail?” | | Agent mode | Your workstation, inside the IDE | You, per command and per edit | Workflow rewrite, provider bump, multi-file refactor | | Cloud agent (GitHub’s async coding agent) | Ephemeral GitHub Actions runner environment | CI, then a human on the pull request | Dependency bump, test backfill, YAML lint, docs | ### Who Holds the Loop Agent mode leaves the operator in the chair. You can redirect it with a follow-up prompt before it finishes, reject each proposed command, and undo streamed edits you dislike. The cloud agent gives you a session log and a pull request. When a run goes sideways, you comment `@copilot` with the correction, and by default Copilot pushes commits straight to the pull request branch, as the [pull request review docs](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/review-copilot-prs) describe. The fix lands, and you wait through the loop again. ### Two Limits That Shape Your Issue Text The same [surface documentation](https://docs.github.com/en/copilot/concepts/copilot-surfaces/copilot-on-github) states the hard ceilings: “Each Copilot cloud agent session has a maximum execution time of 59 minutes. This limit cannot be extended or bypassed.” It also notes that Copilot “can only work on one branch at a time and can open one pull request per task,” and that a session changes only the repository named at the start. The three documented ceilings (one repository, one branch, 59 minutes) are a decomposition spec. One repository per run kills the shared-module-plus-three-consumers epic, and 59 minutes kills any task whose validation suite cannot finish inside the budget. ## A Faster Backlog Needs a Wider Exit The bottleneck argument stopped being theoretical. A Harvard study of 718 firms, built on roughly 300 million work events from the Jellyfish analytics platform between January 2021 and March 2026, separated assistants from agents and measured the downstream effect. [InfoQ’s writeup](https://www.infoq.com/news/2026/10/jellyfish-ai-productivity/) carries the numbers. Agents lifted lines of code by 30%, commits by 20%, and pull requests by 23%. The count of Jira issues and epics resolved per worker rose 12%. Meanwhile the average time to review a pull request climbed 49%, comments per pull request rose 53%, the share of pull requests needing changes doubled, and the share of workers doing reviews rose 14%. The authors name the mechanism: “engineers spend 30-40% of their time writing code; the remainder goes to these complementary tasks. When AI raises productivity in code writing, complementary steps may serve as bottlenecks.” Your backlog sits on the far side of that sentence. The chart below shows how far: agent output climbs upstream while review load climbs just as fast downstream. ![Agent output vs review load](https://adamtheautomator.com/wp-content/uploads/publisher/c9d68dad023941c1aba0b78598161b6760f33478960c284bb7e94bd010c7f519.jpg) ### The Ratio to Watch Count merged pull requests per engineer-hour of review. If your team merges 40 pull requests a week on 60 hours of review, an agent that adds 23% more adds about nine, and those hours have to come from smaller diffs, a second reviewer, or a queue that grows while everyone feels productive. * * * _**Reality Check: A pilot that measures lines of code or sessions started will look like a success while your release cadence stays flat. Measure the queue that receives the work.**_ * * * ## Score an Item Before You Delegate It Most teams delegate by vibe: the ticket looks small, the file is familiar, the mood is optimistic. Five scored questions predict which surface finishes an item without a second review round. | Question | Scores 2 when | Scores 0 when | | --- | --- | --- | | Can you specify it? | Files, change, and done condition fit in 200 words | The ticket says “improve logging” | | What is the blast radius? | One repo, no shared infrastructure, identity, or secrets layout | A merge changes production networking or IAM | | Can CI prove it? | A command verifies the result in under 20 minutes | Success means “looks right in the portal” | | Is the context local? | The repo, its issues, and its docs hold the answer | The answer lives in a Slack thread | | Can you revert it? | A revert commit restores the prior state | Rollback needs a data restore | Add the five scores. Eight to ten points is cloud agent work, where the issue text alone carries the task. Four to six is agent mode work, where you watch the commands and correct course. Zero to three is human work with Copilot at the cursor. The flow below routes those scores into a surface and names the deciding constraint under each outcome. ![Routing one backlog item](https://adamtheautomator.com/wp-content/uploads/publisher/bc41d509c9b8972d47ed195ac1d02632ef6501f88e6c470451d264648cd54272.jpg) ### Sorting the Queue with gh Start with the issues your team already labels: ```bash gh issue list --repo OWNER/REPO --state open --limit 300 \ --json number,title,labels,assignees > backlog.json ``` Two caveats first. An incompatible ruleset blocks the agent outright: a rule that allows only specific commit authors can stop Copilot from creating a pull request, and the [ruleset documentation](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository) explains the bypass actors. Administrators can also disable the cloud agent per repository, so a failed assignment may be a permissions problem. ## Write the Issue an Async Agent Can Finish The cloud agent converts text into a branch. Thin text produces a thin diff, and you discover the gap during review, the most expensive place to learn. Paste this into every delegable ticket: ```markdown **Goal** Pin the azurerm provider to 4.x and keep the storage module on the same major version. **Files** - infra/modules/storage/main.tf - infra/environments/dev/main.tf **Acceptance criteria** - terraform init -upgrade resolves azurerm 4.x - terraform plan shows no resource replacement - terraform fmt -check passes **Validation** ./scripts/validate-infra.sh dev **Out of scope** Application code, CI workflow changes, production environments. ``` The file list tells the agent where the change belongs and marks the rest out of scope. Acceptance criteria phrased as commands give it a stopping condition it can test. The out-of-scope block is the cheapest guardrail in the file: an agent that respects it will not touch your deploy workflow while pinning a provider. ### Split by Validation Command Two acceptance criteria that need different commands belong in two issues. A task whose success cannot be proven by a command inside the session budget becomes a pull request a human validates by hand, which turns async automation back into synchronous work. The 59-minute ceiling applies per session, and a session that spends 40 minutes bootstrapping a test database has little left for the change. The [environment customization docs](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/customize-the-agent-environment) let you trim that bootstrap: the `copilot-setup-steps.yml` job accepts `timeout-minutes` with a maximum value of 59, and the job must be named `copilot-setup-steps` or Copilot ignores the file entirely. ```yaml # .github/workflows/copilot-setup-steps.yml name: "Copilot Setup Steps" on: workflow_dispatch: push: paths: - .github/workflows/copilot-setup-steps.yml jobs: copilot-setup-steps: # must be named exactly this runs-on: ubuntu-latest permissions: contents: read timeout-minutes: 25 steps: # setup steps run before Copilot's automatic checkout, so clone first - uses: actions/checkout@v4 - run: ./scripts/bootstrap-ci.sh ``` A setup script that installs the whole toolchain from the network each session eats the budget you wanted for the repair, and a flaky bootstrap turns a delegable task into a `timed_out` session. ## Worked Example: One Failing Deploy Workflow, Two Ways Take a ticket your team has opened this month: the deploy workflow on `main` fails at the login step because the long-lived credential it injects from a repository secret has expired. The fix is [OpenID Connect (OIDC) federation](https://adamtheautomator.com/entra-workload-identity-aks-no-more-secrets/) with `azure/login@v2`, a job-level `permissions: id-token: write`, and deletion of the secret reference. Start both passes from the same evidence. The [`gh run view` reference](https://cli.github.com/manual/gh_run_view) documents the log flags, including `--log-failed`, which shows only the failed steps: ```bash gh run list --workflow deploy.yml --status failure --limit 5 gh run view --log-failed ``` ### The Synchronous Pass: Agent Mode in the Editor Open the repository, switch the chat to agent mode, and give it the whole job in one prompt: replace the credential login with OIDC, add the permission block, drop the secret reference, and run `actionlint` when it finishes. You approve commands as they stream, veto anything that rewrites the release workflow, and push a branch when the diff looks right. An illustrative run takes 20 to 30 minutes of a person’s time, most of it reading the diff and waiting for the workflow. You spend attention continuously and review once, as the work happens. ### The Asynchronous Pass: The Cloud Agent Write the same scope as an issue, then hand it over from the command line. The [`gh agent-task` command set](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/use-cloud-agent-from-cli) requires GitHub CLI v2.80.0 or later: ```bash gh agent-task create "Switch .github/workflows/deploy.yml from the AZURE_CREDENTIALS secret to OIDC using azure/login@v2. Add permissions: id-token: write at job level and delete the secret reference. Acceptance: actionlint passes and a dev deploy run succeeds." \ --base main --follow ``` The agent opens a pull request for your review. GitHub holds the workflow run until a human clicks **Approve and run**, a security feature you should keep. Then the interesting failure appears: the dev deploy takes 40 minutes, the agent reruns it after a fix, and the session hits the 59-minute ceiling before validation finishes. The task ends `timed_out` with a pull request that looks plausible and has never been proven. ### What the Difference Costs You The synchronous pass spent 25 minutes of attention and produced a verified change. The asynchronous pass spent 8 minutes writing the issue, 20 more reviewing a second attempt, and still needed a human to run the deploy. Delegation lost here, and the reason was knowable in advance: validation was longer than the session budget. Change one variable. Make validation a 6-minute unit test run, keep deploy verification out of the acceptance criteria, and put deploy approval in a separate workflow. The same ticket becomes a clean async job, because the agent can prove its work inside the budget and leave the risky step to a human gate. ## Per-Item Economics: Credits, Runner Minutes, and Reviewer Hours Three consumables decide whether delegation pays: the agent session, the CI runs it triggers, and the reviewer time the pull request consumes. Only the first shows up on the invoice you already watch. GitHub’s [usage-based billing documentation](https://docs.github.com/en/copilot/concepts/billing-and-usage/organizations-and-enterprises/billing) names the unit: “GitHub AI Credits are the billing unit for Copilot usage in Copilot Business and Copilot Enterprise.” The same meter is still reported as premium requests in some org dashboards, so budget by the credit figure and ignore the label. ### Build the Cost per Merged Pull Request Add them at a loaded rate, then compare that total against the engineer time the item would have taken. The async path carries a fixed weekly cost: issue templates, setup-job bootstrap, and first reads of agent pull requests. The break-even column amortizes it. | Backlog item | Manual path | Async path | Break-even | | --- | --- | --- | --- | | Dependency bump, one file, green CI | 10 min engineer time | 1 session, 2 CI runs, 12 min review | Manual wins on engineer minutes; async pays only when those 10 minutes would wait behind other work | | Workflow rewrite, three files | 35 min engineer time | 2 sessions (one retry), 4 CI runs, 40 min review | Synchronous wins unless you batch similar repos | | Base image CVE bump across six repos | 6 x 30 min engineer time | 6 sessions, 12 CI runs, 6 x 15 min review | Parallel wins only if reviewers are available | _Figures are illustrative._ Substitute your own rates, and count the rework round, since the study found the share of pull requests requiring changes doubles on agent-heavy repositories. ### Where Manual Work Stays Cheaper Delegation loses when the item is cheaper to do than to explain. A one-line fix inside a workflow you already understand costs less than the issue text, the review, and the wait, and a review that doubles to 40 minutes has already spent the manual cost. ## Guardrails for an Agent That Can Edit Your Pipelines An agent that can open a pull request against `.github/workflows/deploy.yml` can change how software reaches production. Grant that access the way you would to a contractor: narrow scope, mandatory review, and no ability to approve its own work. Start with the approval gate. GitHub does not run workflows automatically on an agent’s push, and [GitHub’s guidance for reviewing Copilot pull requests](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/review-copilot-prs) tells you to be “especially alert to any proposed changes in the `.github/workflows/` directory.” Keep that click manual during the pilot. Add [`CODEOWNERS`](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) entries for `.github/workflows/`, `infra/`, and environment configuration. That forces a platform engineer onto every pull request touching deployment mechanics, which is cheaper than discovering the change at deploy time. ### The Approval Rule That Surprises Teams [Branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) interacts with Copilot in a way that catches people mid-rollout. The same review page states: “If you have rules or branch protections that require pull request approvals, and you ask Copilot to create a pull request, you can approve the pull request, but your approval won’t count toward the required number of approvals. Someone else must approve the pull request for it to be merged.” A one-person platform team cannot self-approve, and a pilot that assumes one review per agent pull request will stall at the merge button. Line up a second reviewer before you queue the first task. ### Tool Autonomy Without a Prompt Model Context Protocol servers extend what the agent can reach, and the [MCP configuration docs](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers) carry a warning worth reading twice: “Once you’ve configured an MCP server, Copilot will be able to use the tools provided by the server autonomously, and will not ask for your approval before using them.” Allowlist specific read-only tools rather than `*`. Treat any write-capable tool as a privileged integration with a named owner, because a tool that can merge, deploy, or change settings collapses the human gate you just built. Network access is the third control. GitHub limits outbound access with a firewall, and a blocked request appears as a warning in the pull request body naming the address and the command that tried it, per the [firewall documentation](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall). * * * _**Warning: Never hand the cloud agent a long-lived cloud credential “just for the deploy step.” Use OIDC federation with a scoped trust policy, and keep [environment protection rules](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) on the environments that publish.**_ * * * ## Cap the Review Queue First Delegation stays pleasant until your senior engineer has nineteen open agent pull requests and no time to think about them. Set the cap before the first assignment, and derive it from review hours. ### The Division That Sets the Cap If a platform engineer protects six hours a week for reviews, and an agent pull request costs 25 minutes including rework, that engineer can absorb roughly fourteen a week. Two engineers with overlapping expertise do not double it, because context switching consumes the overlap. Take 60% of the theoretical 28 and you land near 17, too many for a pilot. | Concurrent agent pull requests | What reviewers experience | What breaks first | | --- | --- | --- | | 5 | Queue clears within a day | Nothing; this is the pilot cap | | 10 | Review age doubles, diffs get skimmed | Rework rounds climb | | 25 | Triage replaces review | Defect escape and rollback | Keep the study’s 49% review-time increase in view as agent pull requests arrive. GitHub’s [Copilot usage metrics](https://docs.github.com/en/copilot/concepts/billing-and-usage/copilot-usage-metrics/copilot-metrics) expose pull request lifecycle trends across your organization. ## What Not to Hand Over Some tickets look delegable until the run hits a decision the agent cannot make. The pattern behind each entry: recovery requires a judgment call inside 59 minutes, and a wrong merge costs more than a revert. * Incident response: the session starts from an issue, and your incident clock runs in minutes. * Production hotfixes under a deadline: a 59-minute ceiling plus a review cycle is slower than the engineer holding the stack trace. * Live schema migrations: a revert commit does not restore dropped columns. * Credential, certificate, and key rotation: a half-finished rotation locks out the service it was meant to protect. * Release cutovers: the blast radius is the thing you ship. * IAM, DNS, network policy, and production Terraform modules: these belong in agent mode, where you approve every command and see the plan. * Anything that edits environment protection rules or OIDC trust: the agent would be modifying its own gate. GitHub’s [risks and mitigations page](https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations) names the threat that makes this list urgent: users can hide instructions inside issues assigned to Copilot or in comments left for it, as a form of [prompt injection](https://adamtheautomator.com/stop-github-copilot-leaking-enterprise-data-2/). An issue body is an input channel, so treat a delegated issue like code. ## Run a Four-Week Pilot and Let the Numbers Decide Pick one repository with green CI, label twenty backlog items, and route them through the rubric for four weeks. Pull the agent pull requests first: ```bash gh pr list --search "author:app/copilot-swe-agent" --state all \ --json number,createdAt,mergedAt,reviewDecision,reviews --limit 200 > agent-prs.json ``` Then check session health through the [agent tasks API](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/use-cloud-agent-via-the-api), still in public preview, where each task reports a state of `queued`, `in_progress`, `completed`, `failed`, `idle`, `waiting_for_user`, `timed_out`, or `cancelled`: ```bash curl -s -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2026-03-10" \ -H "Authorization: Bearer $GITHUB_TOKEN" \ https://api.github.com/agents/repos/OWNER/REPO/tasks \ | jq -r '.tasks[].state' | sort | uniq -c ``` Set thresholds before you look at the data, so the pilot cannot be reinterpreted afterward: * Sessions ending `timed_out`: under 10%. * Issues closed per week: up against the same baseline window. * Cost per merged pull request: below your manual cost from the table above. Expand when merge-without-change clears 60%, rework rounds come in at 1.5 or fewer, and review age holds flat. Stop and rewrite the issue templates when `timed_out` sessions pass 20%, because that pattern describes a decomposition problem. ## Where the Backlog Actually Shrinks The backlog shrinks in the review queue, so the surface choice depends on how the work decomposes. Inline suggestions keep a small fix small. Agent mode takes the items where you need to see the commands and the plan, with [plan mode](https://docs.github.com/en/copilot/how-tos/copilot-in-your-ide/use-copilot-agents/use-plan-mode) for ambiguous scope. The cloud agent takes the boring, provable, single-repository chores that would otherwise sit behind three more interesting tickets. The hybrid loop is where most teams end up: prototype in agent mode where you can steer, delegate the polish to the cloud agent, and patch its pull request back in agent mode when the diff needs three focused edits. Set the review cap first, write issues that end in a command, and let four weeks of numbers decide how far this goes. The teams that benefit most from asynchronous agents already had review capacity to spare, and that capacity comes from policy rather than from a better prompt. * * * _**Key Insight: Every delegated item becomes a review the queue owns, so budget reviewer hours as deliberately as you budget Copilot seats.**_ * * * Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Fgithub-copilot-agent-mode-vs-cloud-agent%2F&text=Copilot%20Agent%20Mode%20vs.%20Cloud%20Agent%3A%20Automate%20Your%20DevOps%20Backlog)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Fgithub-copilot-agent-mode-vs-cloud-agent%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Fgithub-copilot-agent-mode-vs-cloud-agent%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/2024/12/featured-image-8.webp) ### [Creating Custom GitHub Actions: A Complete Guide for DevOps Teams](/custom-github-actions-guide/) Learn how to build custom JavaScript GitHub Actions to share standardized, reusable code across your organization's workflows. This hands-on tutorial walks through creating authentication and secret management actions. ![](https://adamtheautomator.com/wp-content/uploads/publisher/3f25d9c85b2b813e8a0dea451dc89138/6fb0067ffdaeca7dafae4e68bbfde0f73ea197247f36bcc3d64e68dd24a4df0d.webp) ### [Build a Slack Help Desk with Notion Custom Agents](/build-a-slack-help-desk-with-notion-custom-agents/) Connect Slack to Notion Custom Agents and build an answer library from pages your team trusts, with source lines, honest refusals, and a human queue. ![](https://adamtheautomator.com/wp-content/uploads/publisher/3f25d9c85b2b817b9916e1d7c0ce0d01/9553685a308ab52c50530c8cc96e715bb8f2194da3d00a46fb09a3e8836a559a.webp) ### [Notion Workers: Stop Agents Guessing Customer Lookups](/notion-worker-customer-lookup/) Build a read-only lookupCustomer tool in a Notion Worker, then attach it to a Custom Agent so it answers with a plan and status instead of a guess. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)