Open-source Kortix keeps the agent in your repo; Copilot Studio keeps it in Microsoft's tenant

Microsoft Copilot Studio is a graphical, low-code studio for building and managing AI-powered agents and workflows, and inside a Microsoft 365 tenant it is a productive place to build them. Kortix is the open-source AI Operating System, and it asks a different question about the same work: where is the agent defined, versioned and run? In Copilot Studio the answer is Microsoft's cloud at every step. The agent is built in the studio, stored in a Power Platform solution, published into Microsoft's surfaces and billed to the tenant in Copilot Credits. In Kortix the answer is a file in a repo your team owns.

What Copilot Studio does well

Microsoft's own pages describe a mature product. Each strength below comes from those pages.

• Low-code for the whole team. Microsoft says you can build capable solutions without an extensive technical background, while professional makers keep the depth they need (Copilot Studio overview). A maker can describe an agent in plain language, test it and publish it.
• Reach inside Microsoft 365. Agents publish into Teams, SharePoint and Copilot Chat, where employees already work (Copilot Studio). Authentication with Microsoft Entra ID is on by default for those channels (Publish and deploy your agent).
• Enterprise plumbing included. The platform documents a full Dev-Test-Prod lifecycle with version control, release pipelines and approval gates, plus audit logs that flow into Microsoft Purview (Copilot Studio). Administrators inventory agents across the organization with role-based access.
• Prebuilt connectors. Agents connect through Power Platform's prebuilt connectors, standard and premium, and custom connectors reach any public API (Use connectors in Copilot Studio agents). Work IQ, Microsoft's intelligence layer, tunes agents for the tenant's own workflows (Copilot Studio).
• A serious runtime for hard work. The GitHub Copilot harness takes a goal, breaks it into steps and runs each task in a sandbox governed by Copilot Studio. It is a Studio framework rather than the GitHub Copilot service itself, and agent data stays under Copilot Studio's own commitments (Harnesses in Copilot Studio).

For a company that runs on Microsoft 365, that list is the product working as intended, and it holds up until the question turns to ownership.

The tenant boundary is the lock-in

Every Copilot Studio agent is an object inside Microsoft's cloud, and Microsoft's docs say so plainly. When you create an agent in Copilot Studio, the agent is created within a Power Platform solution, the unit the platform uses to move agents between environments (Create and manage custom solutions). Definition, version history and runtime all sit on Microsoft's side of the wall. The studio is where you visit the agent, and Microsoft's cloud is where the agent lives.

Publishing wires a channel to the agent and leaves the runtime where it is. The channels doc lists live websites, mobile apps, Microsoft Copilot, Teams and Facebook, each a connection configured inside Studio (Publish and deploy your agent). The pricing page draws the same line from the other side: a Microsoft 365 Copilot license covers agent building for use inside your organization, and reaching outside channels takes a standalone Copilot Studio plan (Copilot Studio pricing).

Billing follows the tenant too. Copilot Credits measure the time and effort an agent needs to retrieve information, respond and use its actions (Standard harness licensing). They replaced the old message currency on 1 September 2025. The standalone plan is sold as tenant-wide packs of 25,000 credits a month, each a tenant license (Microsoft Copilot Studio capacity packs). Microsoft lists the pack at $200 a month (checked October 2026) (Copilot Studio pricing), with a pay-as-you-go meter on an Azure subscription as the alternative. The same doc carries the conditions: the maker license is free of charge only after the tenant holds a prepaid Copilot Credit pack subscription, unused credits do not carry over, and usage beyond purchased capacity can end in service denial.

That is what software sold to a tenant looks like. It also puts the real question below the feature grid: what do you hold when the build is done, and who can read it?

The agent as a file you own

Kortix answers that question with a different object. A Kortix project is a git repo with kortix.yaml at its root, and the agents, skills, memory, tools, triggers and connectors are files inside it (Kortix docs). The starter project every new deployment begins with shows the shape. The manifest registers what exists and leaves the decisions to each agent:

# packages/starter/templates/base/kortix.yaml
#
# The project REGISTERS what exists (skills, tools, commands, extensions,
# connectors, secrets). Each AGENT decides: its prompt, model and permission,
# and which registered things it enables, by name. Nothing applies to every
# agent by itself, and an agent sees only what it enables.

The front-door agent lives beside it as a markdown file. This is the starter's own text:

You are a **Kortix general knowledge worker** for **{{projectName}}**.

You are hands-on: you read, edit, run, search, fetch, and ship. The
session you're in is an isolated sandbox — an ephemeral branch of
this repo, your own `/workspace` — so you can install, experiment,
and recover freely. Only what you commit + push survives.

An agent is agents/<name>.md for behavior plus an agents.<name> block in kortix.yaml for governance, and that pair is the whole definition. The session line carries the versioning story: a session is a branch of the repo, so the agent's history is the repo's git history, and only what it commits and pushes survives.

Kortix is open source. Read it, fork it, audit it (Kortix on GitHub). Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The work comes back reviewable: session work reaches main through a change request, and merge is default-deny for agents, so a person reads the diff before anything lands.

The cost model follows the same logic. Free is $0 with 200 credits per month and 1 project. Paid plans start at $50 a month for 5,000 credits, and members are free, sharing one credit pool (Kortix pricing).

What moves and what gets rebuilt

Microsoft documents one way to move a Studio agent: as a Power Platform solution, exported and imported between environments (Export and import agents using solutions). The doc is specific about what survives the trip. The agent instructions, the main prompt, are included. Custom topics and knowledge sources stored as separate resources or Dataverse tables might not be included. Conversation IDs, bot IDs and environment IDs do not transfer, and the imported agent arrives with an empty icon and no channel details. Authentication is configured again, and the agent must be published before it can be shared. The documented purpose is moving an agent between Microsoft environments; running one outside Microsoft's platform is not a documented use.

In Kortix the same move is a clone. The agent is already a file, so moving means cloning the repo and running it wherever the platform runs, from a laptop to your own VPC. Coming the other way, a Studio agent's main prompt becomes the body of an agents/<name>.md file, and the connectors and triggers it relied on get declared in kortix.yaml. The topic tree and the flows do not travel: a topic becomes a prompt plus skills you write, and Power Automate flows become triggers and project tools.

Where Copilot Studio is the better pick

For some companies, the boundary is not a cost. Three things Studio does for them have no file equivalent.

• Your people work in Microsoft 365. Agents that answer in Teams, SharePoint and Copilot Chat meet employees where they already are (Publish and deploy your agent). For internal agents, that reach is included with the Microsoft 365 license rather than a separate purchase, and a company that measures its work in Microsoft 365 seats will feel the integration first.
• Non-developers build the agents. Microsoft's pitch is that low-code lets people close to the work build capable solutions (Copilot Studio overview). Kortix asks for a repo, a review habit and, on self-hosted deployments, someone who runs it. Studio's designer gives those same makers drag-and-drop workflows instead.
• The compliance surface is prebuilt. Audit logs flow into Microsoft Purview and the platform documents data-residency alignment (Copilot Studio). That is a real advantage when your security review is written around Microsoft's controls, and Copilot Studio is available in the US Government Community Cloud plan.

If your company will run on Microsoft 365 for the foreseeable future and wants citizen-developed agents inside it, Copilot Studio is the right tool. The comparison turns when the agent has to be something you own.

Side by side

The table holds the rows a Studio buyer decides on. Each cell states one side's own position.

When to pick which

What buyers ask about Copilot Studio

Is there a free version of Copilot Studio? Yes for building and testing, no for publishing on your own terms. Microsoft's docs list a trial license that can build and test agents in the test chat but cannot publish them, and a maker license that is free of charge only after the tenant holds a prepaid Copilot Credit pack subscription. Building internal agents is included with a Microsoft 365 Copilot license; reaching outside channels needs the standalone plan.

What is the best open source alternative to GitHub Copilot? That Copilot is the coding assistant, a different product from Copilot Studio. In the editor, the open-source picks are Cline, which runs in VS Code, JetBrains and the terminal, and Tabby, a self-hosted completion server; both take the models you configure. GitHub's own plans page lists Copilot Free at $0 with paid tiers above it (checked October 2026) (GitHub Copilot). The full coding lane is compared in the open-source Copilot map.

Is there an open source version of Copilot? No. Microsoft ships each Copilot product as a closed, hosted offering, and none is published as source you can run yourself. The open-source route is a replacement platform rather than a Microsoft release: Kortix for the org-scale agent lane, Cline and Tabby for code, as the map post lays out.

What is Google's equivalent of Copilot Studio? Google's closest equivalents sit in Gemini Enterprise. On Google Cloud, the Gemini Enterprise Agent Platform documents Agent Studio for low-code agent design and the Agent Development Kit for code-based builds, alongside governance components such as Agent Gateway and Agent Registry (Google Cloud documentation). Like Copilot Studio, it runs in the vendor's cloud rather than on infrastructure you own.

What should you switch to when Copilot Studio feels too limited outside the Microsoft ecosystem? Decide by the limit you hit. If the limit is the tenant boundary, agents that publish into Microsoft's surfaces and bill Copilot Credits to the tenant, the switch is to a platform where the agent is a file in a repo you own. Kortix is that platform: agents, skills, memory and connectors as files in one repo, any model with your own keys, and a change request a person approves before work lands.

The open-source Microsoft Copilot map splits the Copilot line into lanes and picks a project for each, GitHub Copilot included. Kortix vs Gumloop runs the same comparison against a hosted no-code builder.

Start with Kortix on managed cloud or self-host it free. Either way, the agent, its history and its review gate stay in a repo your team can read.