Microsoft put GitHub Copilot's engine in a chat app: where agent instructions live now

On Friday Microsoft rebuilt the Copilot app around three tabs: Home, Code, and Autopilot (official announcement, September 25). Code is the tab that matters here. Microsoft says it is powered by the same underlying technology as GitHub Copilot, runs in a sandboxed environment, and can be hosted securely inside your tenant. Autopilot, previously called Scout, is a cloud-hosted agent that keeps working while you are away.

The Verge called the result a super app and CNBC framed the same launch as a chase after Anthropic. Both are fair reads. If you maintain agent configurations for a team, though, the interesting question is narrower: where do the instructions live when the coding agent has no repo?

What actually shipped

Home merges Copilot Chat and Cowork into one landing surface, with Word, Excel, and PowerPoint built in. Code lets anyone describe a tracker, dashboard, or automation and get a working app that runs sandboxed and can be hosted in the company tenant. Autopilot takes a name, a role, and a goal, then watches channels and follows up on threads without waiting for a prompt.

The rollout is staggered. Home and Code start reaching Microsoft's Frontier early-access program in the coming weeks, Autopilot enters private preview at the end of September, and Code lands in preview for Microsoft 365 Premium and Pro subscribers later this year. This is a vision post with a delivery schedule attached, not a product you can install today.

Code is a coding agent with no repo

The sandbox is the whole design. Microsoft's post says Code "runs in a sandboxed environment and can be hosted securely within your tenant", with Microsoft IQ grounding everything in the context of your work. The apps it produces are small, purpose-built solutions: shared with teammates, connected to live data, governed by IT.

Two positioning details are easy to miss. First, Microsoft explicitly says your software developers continue to use GitHub Copilot for their day-to-day work. The split is deliberate: Code targets people who were never going to keep a repository. Second, when Directions on Microsoft asked how Code relates to Power Apps, the answer was that Code is a "code-first experience" and not a Power Platform replacement. It generates software projects that run locally or in the cloud, not canvas apps.

Spataro's framing is the boldest part: code becomes a fourth unit of knowledge work next to the document, the spreadsheet, and the deck, and learning to build these small tools becomes as basic as writing a memo. That is a claim about who writes code, and it quietly changes who is responsible for what the code does.

Where the instructions go

A repo-based agent reads a file at the root: AGENTS.md, CLAUDE.md, or .github/copilot-instructions.md for GitHub Copilot (I wrote about that file here). The file gives you four things: review in a pull request, a diff when it changes, a version to pin, and a history to blame. That is the entire governance model of agent config as most teams practice it.

In Code, behavior comes from three places instead: the tenant's admin policy, the Microsoft IQ grounding in your work context, and the prompt that started the build. None of those is a file you can diff. The review surface for agent behavior moves from a pull request to an admin center.

The honest counterpoint matters. The person building a team tracker in a chat tab was never going to maintain an AGENTS.md, and a governed sandbox with IT oversight is a real upgrade over a shared spreadsheet with macros in it. The tools serve different audiences. But if your team's whole investment is versioned instruction files, notice that this path has no equivalent artifact, and behavior set through prompts and policy has no changelog.

Managed Runtime is the part developers should read

Buried under the tabs announcement is the piece with the most developer surface: Copilot Managed Runtime, now in public preview. It is the hosting layer that runs code inside the Microsoft 365 tenant boundary, and it already powers apps built in Cowork, Code, and Copilot Studio. Microsoft is opening it to third-party and pro-code developers.

The SDK and CLI support the full development loop: scaffold and configure an app, define its data connections, develop and run locally, then deploy and version through the same toolchain. At runtime, SDK APIs bridge the app to governed enterprise data, identity, and work context, and the Microsoft 365 admin center shows access, usage, health, and policy in one place.

That is a genuinely interesting inversion. The consumer story is "describe it and it runs", and the developer story underneath is a versioned deploy pipeline. If you want the inspectability that packaging usually gives you, this SDK is where it lives, in contrast to approaches like Docker's Kit spec, which packages agent authority as an OCI image you can pull apart offline.

Autopilot is an agent with a directory entry

Autopilot lives in your tenant with its own identity, memory, computer, and workspace, and you can @mention it in Teams and Outlook like a colleague. Directions on Microsoft reports these long-running agents get their own Entra IDs, email, and Teams accounts.

Look at the configuration surface, though. You give it a name, a role, and a goal. That is a form, not a file. The governance surface around it (permissions, audit, policy) is enterprise-grade, which is exactly the asymmetry worth watching: the most autonomous agent in the suite has the smallest config artifact, and everything that constrains it lives in tenant settings someone else may control.

Usage billing changes what gets configured

The commercial model shifted too. The per-user Copilot license stays, but Cowork, Code, and Autopilot, plus frontier models like Astra and Fable, move to usage-based billing via Copilot Credits, additive to the seat license. Context from CNBC: fewer than 7 percent of the more than 450 million commercial Microsoft 365 seats carry the AI add-on today, so usage pricing is the attach-rate fix.

One detail with config implications: in the coding product, users can manually select which model to use, including a cost-efficient Microsoft offering. When every run is metered, constraining an agent's scope stops being hygiene and becomes budgeting. Deciding which model a task deserves is a configuration decision now, same as choosing a rules file.

What to pin down before adopting

If your team evaluates this during Frontier or preview, four questions decide most of it:

1. Who can change what. Tenant policy, IQ grounding scope, and the initiating prompt all shape behavior. Map each to an owner.
2. Can the app leave as code? The Managed Runtime SDK suggests yes for the pro-code path. Confirm before a business process depends on something you cannot export.
3. What does the agent read? Work-context grounding is a permission boundary. Ask what it spans before non-developers build against it.
4. Where is the cost telemetry? With usage billing, per-app spend visibility in the admin center is the difference between adoption and a surprise invoice.

The repo is not going anywhere

Microsoft kept the two worlds separate and built a bridge: professionals keep GitHub Copilot, and the sandbox opens to code-first developers through the SDK. The bridge is a deploy pipeline, not a shared config format, so repo-based instruction files stay the governance model for real repositories. That is the side I work on: pinned, versioned instruction files that travel with the code and survive any host. The full set is AgentConfig Studio, and the free Next.js sample shows the pattern in one kit.

The rule of thumb I would take from the launch: instructions follow the repo, governance follows the tenant. Know which side your agent's behavior lives on, because the suite Microsoft just shipped lets someone configure the most powerful agent in it from a form.