Copilot Studio in 2026: applications, flows and agents

Written by Mario Larrúa Vega.

A training request can start with a question, continue in a form, require approval and end with a notification. Each step has a different need: converse, collect data, apply rules or perform an action.

Copilot Studio is evolving toward an experience that brings applications, automation and agents together. In its announcement on October 7, 2026, Microsoft introduced applications and Copilot Managed Runtime in public preview, along with knowledge, evaluation and control updates. See the official announcement.

This article explains how to interpret those components and suggests a learning scenario: managing training requests for a training provider. We will distinguish documented capabilities from the example’s design decisions.

Copilot Studio applications remain in preview and rollout is gradual. Microsoft states that preview features are not intended for production and may have restrictions. Check availability and terms in your environment before trying them.

What Copilot Studio is today

Microsoft describes it as a graphical low-code studio to build and manage agents and automations, connect them to data and systems, and publish them to supported channels. Its documentation also includes the application-creation experience in preview. The general reference is the introduction to Copilot Studio.

To understand it, start with each component’s role:

The specific allocation is an architectural proposal. Define the process first, then decide which component each part needs.

New developments worth knowing

Applications created through conversation

The application experience lets you describe a problem, answer questions and generate an initial interactive version. You can then refine it through conversation and review its code. Access requires the new experience to be enabled and the preview applications option to be present; the administrator can disable it.

Sharing an application does not automatically grant access to data the user did not already have. See requirements, gradual rollout and identity behavior in Apps overview.

A managed environment for applications

Copilot Managed Runtime, also announced in public preview, provides Microsoft-managed infrastructure for these experiences, including identity, governed data access, lifecycle, Git-backed versioning and administrative visibility. Its scope is described in the October announcement.

Platform-managed infrastructure does not by itself resolve data quality, process definition or business authorization. Those decisions still need owners and verification.

Reusable knowledge with Foundry IQ

A Foundry IQ connection lets you use a knowledge base combining sources and retrieval configuration. Current documentation requires access to the base and describes one Foundry IQ connection per agent. It includes several authentication options; review the choice according to the required scope. See how to connect Foundry IQ.

In our example, it could retrieve the training policy maintained by another team. Before adding it, we would verify sources, permissions, returned references and out-of-scope questions.

What harness means and why it appears in tutorials

Current documentation distinguishes several execution engines, called harnesses. They affect capabilities, configuration and billing.

The GitHub Copilot harness in Copilot Studio is not the GitHub Copilot service: documentation distinguishes them and explains data handling. See Harnesses in Copilot Studio.

This affects practice: a standard-experience agent-flows tutorial may show different options from a new-experience workflows tutorial. Before copying steps, check which experience it refers to.

Practical scenario: training requests

The training provider wants employees to browse courses, submit requests and check their status. Some requests require manager approval.

For a first prototype, we propose three boundaries:

1. Use only fictional data and sample courses.
2. Keep approval as a human decision.
3. Start without payments, permission changes or automatic enrollment in external systems.

The process would be:

Persona interesada
  ├── Consulta requisitos al agente
  └── Completa la solicitud en la aplicación
             │
             ▼
       Validación de datos
             │
             ▼
       Solicitud de aprobación
             │
      ┌──────┴──────┐
      ▼             ▼
   Aprobada      Rechazada
      └──────┬──────┘
             ▼
     Registro y notificación

We are not claiming that the platform generates this entire process from one instruction. This is the design we want to build and verify gradually, according to available features.

Step 1. Define data and rules

Before opening the designer, write a minimal model:

Also propose transitions: draft, submitted, awaiting approval and resolved. Decide what happens if a course becomes unavailable or the same request arrives twice.

These rules are requirements for the fictional training provider. They must be validated in the system executing the operation, as well as reflected in the interface.

Step 2. Generate a first application

If preview is enabled in your environment, the official guide lets you create an application from the relevant option, describe the problem and refine the result in the interactive view. Follow Create an app.

This is an initial description to experiment with:

Crea un prototipo para gestionar solicitudes de formación de una academia.

Utiliza únicamente datos ficticios.
Incluye un formulario con curso y justificación.
Muestra una lista de solicitudes y su estado.
Separa la presentación de una solicitud de su aprobación.
Indica qué acciones y fuentes de datos necesitan configurarse.
No envíes correos ni ejecutes operaciones en sistemas externos.

Then review fields, validation messages, filters and actions. Check which data the application uses and which parts of the process are simulated.

The description helps build the prototype; permissions and connections must be configured and verified through platform controls.

Step 3. Build the automation

Documented workflows for the GitHub Copilot harness combine triggers, actions, connectors, logic and AI components. They also include node-level testing. The reference is Workflows overview.

In our design, the automation should:

1. Receive a request with an identifier.
2. Validate that the course exists and required fields are complete; return the request for correction if information is missing.
3. Check whether the identifier has already been processed.
4. Determine the approver according to an authorized rule.
5. Request the human decision.
6. Record the outcome and prepare the notification.
7. Maintain a recoverable error state if a dependency fails.

Test each step first with controlled data. The structured process must follow its rules even when an AI component produces an unexpected answer.

Human approval can be implemented through the actions and connectors available for the experience and environment. To study the approval pattern, the following is also useful: introduction to Power Automate approvals. Do not assume every option appears in the same way in Copilot Studio.

Step 4. Add an agent with a limited task

The first agent can provide guidance on courses and requirements. Keep its scope clear: consult information and help prepare the request. Resolution belongs to the approval process.

Initial instructions could be:

Ayudas a preparar solicitudes de formación.

Consulta las fuentes autorizadas antes de explicar requisitos.
Si falta información, pide una aclaración.
Si no encuentras una respuesta, indícalo.
No inventes cursos, plazas, aprobaciones ni cambios de estado.
Solo afirma que una acción ha terminado cuando la herramienta lo confirme.

Prepare connections separately. Check which identity each tool uses and what access it receives. Agent instructions do not replace operation authorization.

The page Start building explains where to start agents and workflows and how to find standard experiences.

Hooks: controls requiring careful design

Hooks, currently in preview for the experience specified in their documentation, run workflows when an agent event occurs. The pre-tool-use event can inspect and block a call.

There is a crucial limitation: if the hook workflow fails, times out or returns unreadable output, the agent continues as if nothing had been returned. Microsoft states that hooks must not be the sole protection for a critical rule. See Hooks overview.

At the training provider, a hook can help log or check calls. The system approving a request must also verify that the person is authorized and the status permits the operation.

How to verify the solution

Before changing instructions or models, prepare a set of cases with expected outcomes. This would be an editorial starting point:

Record identity, channel, inputs, sources, executed tools and outcome. Repeat cases when changing the model, a connection or a rule.

The official agent testing strategy offers methods and resources to organize evaluations. Check which methods your specific experience supports, and supplement answer evaluations with permission, side-effect and failure tests.

Review consumption from the build phase

For agents, workflows and applications using the GitHub Copilot harness, billing is measured in Copilot Credits. Documentation states that creating, previewing, testing and evaluating can also consume credits: consumption does not start only at publication. This structure belongs to this experience and should not be generalized to every mode. See Overview of usage-based billing.

Before the exercise, confirm access, allocated capacity, connectors and possible external-service costs. Then compare consumption across representative cases: a simple query, a document search and a multistep operation.

A design that repeats searches or runs unnecessary tools deserves review, even if the final answer seems correct.

What to check before sharing

The Review panel displays blockers and warnings about readiness and organizational controls. It does not replace administrative oversight or a complete solution review. Its scope is explained in Review agent readiness and status.

Also check channels, identity, owners, documentation, consumption and a procedure to retire or update the version. Policies may prevent publication to certain channels; later changes require republishing to reach users. See Publish an agent.

In this lab, preview applications remain learning prototypes. Any move toward real use requires reviewing availability status and current terms.

What is worth learning from this evolution

Copilot Studio lets you explore a combination of interface, rules, knowledge and reasoning. Professional work means deciding where each component adds value and how to verify the whole solution.

To start, choose a small process and define its data, permissions and expected outcomes. Build in parts, measure behavior and document what you have verified. This approach helps you use new developments while keeping responsibility for the solution you share in view.