Agent Builder stops at the tenant; an open-source agent is a file

What Agent Builder builds, and who it is for

Copilot Agent Builder is the no-code surface inside the Microsoft 365 Copilot app. It opens from microsoft365.com/chat, office.com/chat and the Teams desktop and web clients. It exists for the quick case: an agent that answers from a team's SharePoint files or from web content. You build it in a conversation and test it on a Try it tab before anyone shares it (Agent Builder overview).

Microsoft draws the boundary itself. Agent Builder is aimed at individuals and small teams building "lightweight Q&A agents with organizational knowledge". Copilot Studio is for departments, external customers, multi-step workflows and application lifecycle management (choosing between the two). Agent Builder is included with a Microsoft 365 Copilot add-on, and Microsoft offers it free for agents grounded on web knowledge only. A person can have something useful on the first day, which is what an on-ramp is for.

Two lines on the same page matter more than the feature list. Agent Builder "doesn't support authoring actions that integrate external services" (same page). The documented next step for low-code actions, connectors or workflows is a copy of the agent into Copilot Studio. Skills are in preview, limited to organizations in the Microsoft Frontier Program. The known limitations include no use in Teams group or 1:1 chats (checked October 2026).

Where the agent lives, and who can take it along

An Agent Builder agent is a configuration in the tenant. Administrators see it in the Microsoft 365 admin center under Copilot > Agents and can enable, disable, assign, block or remove it (Agent Builder overview). Microsoft notes that these agents do not consume the tenant's Dataverse storage entitlement. Prompts, instructions, configurations and output content can flow between Microsoft 365 and Copilot Studio in both directions, because Copilot Studio processes the capabilities (data processing).

The arrangement is coherent for a Q&A agent about one team's documents, and it is why the builder is easy to hand out. It also means the agent is a set of settings an administrator governs, rather than a document a reviewer reads line by line.

What happens to the agent when the person who built it leaves?

It stays in the tenant. The person who described the agent does not own it. The administrator's inventory does not depend on that account, so the agent stays available, reassignable or removable as the organization decides. /copilot-agent-management goes through the policy side of that.

Access follows the same logic. Microsoft says the capabilities you can add depend on what is assigned in the tenant (Agent Builder overview). A change there changes what the agent can do. Nothing about the agent travels out with the team that built it.

Moving an agent out of Agent Builder takes a second build

Microsoft documents one hand-off: a copy into Copilot Studio. It preserves the agent's core configuration and instructions and lands it under Power Platform administration in the same tenant (comparison). What a Copilot Studio agent is once it lands there is /copilot-studio-agent. A team that wants an agent hosted outside Microsoft 365 takes Microsoft's custom engine route, which means bringing its own orchestrator and models and hosting them (agents overview). That is building the agent again, in a different runtime.

The same agent as a file in a repo you own

Kortix is the open-source AI Operating System, and its agents are files. The starter ships a front-door agent as agents/kortix.md: frontmatter that sets the mode and the permission, then the prompt itself. The artifact on this page is the opening of that file. The manifest beside it registers what exists: the agents, skills, tools and connectors the project has, and which of them each agent may use. Behavior lives in the markdown, governance in kortix.yaml, and both are in git history.

A session starts from that repository. One isolated sandbox per session. Each session has its own isolated machine and branch. The agent reads, edits, runs and tests there, and only what it commits and pushes survives.

When the work is ready, it does not land by itself. Session work reaches main through a change request. Merge is default-deny for agents. A reviewer opens the change request and reads the diff of the definition. That diff carries the instruction that changed, the model, the permission, the connector the agent now enables by name. Approving it is the same act as approving a code change, with the same history behind it.

That is the difference that matters once an agent encodes a process rather than answering questions about one. In Agent Builder, governance is an inventory screen and a set of admin actions. In Kortix, governance is a diff, and the thing under review is the agent. The control plane Microsoft sells on top of the builder gets its own page at /microsoft-agent-365.

Where it runs, and on which model

Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Any model provider with your own keys. Or the ChatGPT plan you already pay for. Or sign in with your OpenCode Console account for OpenCode Zen and Go.

Agent Builder makes the opposite trade. A declarative agent runs on Copilot's orchestrator and foundation models, and customization is "limited to Copilot's orchestrator and models" (agents overview). The convenience is real, and the model comes with the tenancy.

A fair reading of both

If an agent answers questions about documents that already live in Microsoft 365, and the people asking sit inside the tenant, Agent Builder is the shortest route to a working answer. Copilot Studio is there when the scope grows. If the agent is meant to carry a process the company will still need in three years, on models the company chooses, the definition has to live somewhere the company controls. A file in a repository is that place, and reviewing it is a habit the team already has for code.