From IDE Extension to Always-On Service: How Coding Agents Are Changing in 2026

Coding agents are becoming always-on services: they wake on a schedule or repository event, work in a remote environment, and hand you an issue, comment, or pull request to review. The useful response is not to let one loose on your backlog; it’s to give it one recurring, low-blast-radius job and make the output easy to reject.

That is a real shift from the IDE extension workflow. An editor agent waits for your next prompt, shares your attention, and operates in the narrow context of the file or branch you have open. A service agent has triggers, durable state, credentials, an execution environment, and an output channel. It can do work while you are asleep—which is exactly why its permissions and failure modes matter more than whether its inline suggestions feel clever.

The first change is where work starts

The new default trigger is increasingly not “developer types a prompt.” It is “an issue arrived,” “the nightly build failed,” or “it is Monday at 9:00.” GitHub Copilot automations, for example, support hourly, daily, weekly, cron, issue, and pull-request triggers. Cloud automations can run while your machine is off, and GitHub asks you to select the tools they may use—such as pushing changes, applying labels, or creating a pull request.

That means the first decision is operational, not model-related: what event should wake this thing up? Avoid beginning with feature implementation. Start with a job where a bad answer is visible and reversible: summarize new CI failures into an issue, label incoming bug reports, identify stale dependencies, or draft a release note from merged pull requests.

A good first job produces information or a proposal, not an irreversible side effect. “Open an issue with the three failing test suites and their first failing commit” is a service-shaped task. “Fix every flaky test every night and merge the result” is an incident waiting to happen.

Put the agent’s contract in the repository

If a recurring agent matters, its instructions should not live only in somebody’s desktop app or a chat thread. Put the trigger, permissions, allowed output, and instructions under version control beside the code it touches. That turns a fuzzy prompt into something reviewers can inspect like any other automation.

GitHub Agentic Workflows make this unusually explicit: a Markdown workflow holds YAML frontmatter for triggers, permissions, safe outputs, and the selected AI engine, then natural-language instructions in the body. The workflow is compiled into a lock file and run with GitHub Actions or the GitHub CLI. It is still public preview, so expect format and behavior changes, but the design is worth copying even if you use another agent.

gh auth login --scopes repo,workflow
gh extension install github/gh-aw
gh aw init

# After reviewing the generated workflow:
gh aw run weekly-issue-report

The important review is not whether the prose prompt sounds polished. Review the privilege boundary. A weekly issue report needs read access to issues and permission to create an issue. It does not need repository write access, deployment credentials, a production database connection, or unrestricted network access. GitHub’s example for a weekly report declares issue-read tooling and permits only issue creation as its output. Make that level of specificity your baseline.

If you are building the equivalent yourself, write down four things before you write the prompt: the trigger, the maximum credentials, the allowed side effects, and the place a human sees the result. If you cannot name the last one, you have created background activity, not a usable service.

Remote execution turns prompt quality into security work

Always-on agents are attractive because they can clone a repository, install dependencies, run tests, and keep iterating without blocking your laptop. They are also materially different from a foreground assistant that asks before every shell command. Cursor’s background-agent documentation calls this out directly: its remote agents run in isolated Ubuntu-based machines with internet access and automatically run terminal commands; Cursor warns that this raises prompt-injection and data-exfiltration risk.

This is where teams get sloppy. They hear “isolated VM” and mentally substitute “safe.” An isolated machine limits one category of damage; it does not make a repository token, an MCP connection, a copied .env, or a reachable internal endpoint harmless. An agent that can read an untrusted issue, browse the web, run a shell, and write to GitHub has a real attack surface even when it never touches production.

• Give background agents a separate, narrowly scoped identity. Do not recycle a developer’s broad personal token.
• Default to read-only integrations. Add one write action—create an issue or create a pull request—only when the job proves it needs one.
• Keep secrets out of the agent workspace where possible. A test fixture that loads production-like credentials is still a credential leak waiting for a prompt injection.
• Make the agent create a reviewable artifact. A PR, issue, or CI annotation is better than a direct merge, Slack blast, or deployment.
• Run it manually several times before adding a schedule. A cron expression is not a test plan.

The interface is becoming a queue, not a chat pane

The practical UI change is subtle: you will spend less time in a single agent conversation and more time triaging agent runs. OpenAI’s Codex app describes scheduled automations that combine instructions and optional skills, then send completed work to a review queue. It also uses separate worktrees for concurrent agents, so a long-running task need not disturb your local Git state.

That pattern matters more than any particular desktop app. A useful service agent needs a durable task record: what woke it up, which revision it used, what commands ran, what it changed, what it could not do, and where the resulting diff or report lives. If all you receive is “done,” you have no operational interface—just a bot asking to be trusted.

Set a service-level expectation for the output. For a morning CI report, “ready by 9:05 a.m. with links to the failing runs and a proposed owner” is legible. For a dependency-update agent, “one PR per package group, tests attached, no lockfile-only churn without an explanatory note” is legible. “Keep dependencies current” is how you wake up to twelve noisy PRs and a disabled bot.

What these agents are still bad at

They are bad at choosing priorities from ambiguous business context, recognizing that an apparently isolated change crosses an organizational boundary, and knowing when a passing test suite is not evidence. A service agent is also bad at absorbing unbounded work: “watch all alerts and fix important things” becomes expensive, noisy, and difficult to audit fast.

They are better at routine investigation than autonomous resolution. Let one collect CI evidence, correlate it with a commit range, and draft an issue. Let it propose a narrow patch and run the existing test command. Keep the decision to change behavior, merge code, rotate credentials, or ship a deploy in a human-owned queue.

For the next week, pick one recurring annoyance that takes a person five to fifteen minutes, has a clear source of truth, and ends in an issue or pull request. Run it on demand until you can predict its output. Then schedule it. The agent has become a service; the engineering work is defining the contract it has to keep.