What a Copilot Studio agent is, and where the open-source definition lives

What a Copilot Studio agent is made of

Microsoft's own definition runs to one sentence, and it is worth reading twice. "An agent is an AI assistant that handles conversations and completes tasks" (Copilot Studio overview). The rest of that page describes what the sentence leaves out. The agent follows the instructions a maker writes. It draws on the knowledge sources connected to it, then uses tools to act.

Four parts follow from it. Instructions carry the prompt and the tone. Knowledge is whatever grounding a maker attaches, from a SharePoint library to a public site. Tools and agent flows do the acting, including the ones that reach a system of record. Channels decide where the answers appear. The overview names the reach: agents "can work with employees and customers in multiple languages across Microsoft Teams, Microsoft Copilot, websites, mobile apps, and other channels".

Above those four sits a fifth choice, the harness. "Your choice of harness affects how your agent or workflow reasons, how complex a task it can take on, what it can do out of the box, and how it's billed." A maker picks one of three, and the pick decides how much the agent works out for itself on a given request.

The definition sits in a tenant, behind a login

Copilot Studio is reached as a web app, at copilotstudio.microsoft.com. A maker builds in its editors and publishes from there. Each agent is stored in a Power Platform environment. Microsoft defines one as "a space to store, manage, and share your organization's business data" (environments overview). Each environment sits under one Microsoft Entra tenant. Microsoft states that an environment's resources are reachable only from inside that tenant.

Publishing is the release step, and it takes the whole agent at once. "When you publish an agent, this agent updates on all connected channels." The habit it takes is stated plainly: "Remember to publish your agent again after you make any changes to it" (publish and deploy). A separate page for agents on the GitHub Copilot harness lists what a publish captures (publish overview). The list runs from name and instructions through capabilities, knowledge, skills, workflow nodes and triggers.

Two facts, and they set the shape. A definition and its release are the same action. Between publishes there is a draft, and at a publish the draft becomes what people meet, on every channel at once. The studio holds the draft and the publish unit, so the state a maker edits and the state people meet both sit behind the tenant login. Power Platform moves that unit as a solution. The export page states what the solution carries: "Not all agent components and properties are included. The agent instructions (main prompt) are included. However, some components such as custom topics and knowledge sources might not be included if they're stored as separate resources or Dataverse tables, depending on how they're created or linked" (export and import agents using solutions). Bot properties stay behind as well, among them the conversation ID, the CDS bot ID, the environment ID and topic-level comments. So the instruction text leaves the tenant inside a bundle assembled at export time, and some of the grounding an agent relies on may not come with it. A solution is the artifact Power Platform lifecycle work is built around.

The review question, and what it takes to answer it

Someone will ask what changed in the agent, and who approved it. Microsoft gives a tenant real tools for the second half. Maker audit logs land in Microsoft Purview, and the admin center holds role-based access and an agent inventory (security and governance). A Microsoft-heavy shop gets a governance story there that it already pays for. Moving the agent out of the tenant weakens it.

Power Platform also offers source control, and the same page lists "GitHub integration and deploy-from-Git with audit trails" among its controls (security and governance). That row links to Microsoft's application lifecycle guidance, which treats the exported solution as the thing to keep: an unmanaged solution "should be checked into your source control system" and "should be considered your source for Microsoft Power Platform assets" (solution concepts). For a team that already runs Power Platform application lifecycle management, that is a real answer.

The first half of the question is where the work sits. To say what changed, a reviewer compares one state of the instructions, knowledge and tools with another. Those states live in an editor behind a tenant login. A publish record marks when a change went live, so the comparison gets assembled by hand after the fact. An approver holds a console and a publish timestamp.

A repo answers both halves with one command. A git log on the agent's definition shows each change, its author, the sentence that moved, and the change request that carried it. The comparison is not rebuilt afterwards, because the record is the comparison.

Three shapes, and the team each one suits

The studio, for agents that serve people inside Microsoft 365. If the audience sits in Teams and the data sits in SharePoint or Dataverse, the studio is the right buy. Approval already runs through Purview. Rebuilding that agent elsewhere buys a worse channel story and a second governance model to staff. The migration guide covers the agents that should stay where they are.

A definition in a repo, for agents whose reviewers sit outside the tenant. This is Kortix. The agent is a governance block in kortix.yaml plus a markdown file under agents/. Review is a change request, and the history belongs to the repo.

An agent as code, for a team that already ships services. A framework hands over the whole runtime, along with the bill for it. Channels, credentials, review and rollback are the team's to build. It suits engineers who want the agent in the same pipeline as the rest of their code.

The manifest registers, the agent file decides

Kortix, the open-source AI Operating System, splits one agent across two files, and the split carries the audit. The header of kortix.yaml calls the file the source of truth for project-wide config that lives in git alongside the code (Kortix on GitHub). Its agents: block holds the governance. First the path to the agent's markdown file, then a grant line each for connectors, secrets, permissions and skills.

The behavior sits in agents/<name>.md, where the prompt, the model and the permission are frontmatter and body. Session work reaches main through a change request. Merge is default-deny for agents, so a change to the instruction file arrives as a diff a person approves.

The grant lines are only half of the governance. Per-resource permissions for people and agents. Roles, groups, and an audit trail. One side states the rule and the other records what ran, which is the pairing an auditor asks for.

What to check before moving an agent out of the studio

Five questions, each answerable before a build starts.

• Channels. List the surfaces the work arrives on today. Then check the replacement answers in every one before anything is retired.
• Grounding. Name each knowledge source the agent reads and the person who owns it. Confirm the replacement reaches the same content and can cite it.
• Credentials. Ask where each credential lives, who can read it, and who rotates it. A move that loses that answer is a downgrade.
• The review step. Name the person who approves a change to the instructions, and what they will look at: a diff in a change request, or a screen in a console.
• The runtime. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The self-hosting page walks the install.

Open source. Read it, fork it, audit it. The definition, the grants and the review history are then files a reviewer can pull. The Copilot Studio vs Kortix comparison scores both sides on that basis, and the agent management guide picks up the day-two work when a team runs the studio and Kortix side by side.