Your team wants to turn the results of a demo repository into a report. The agent can read the tests, prepare a document, and now interact with a desktop application. But who decides that the document is ready to be shared? Moving from a local file to an action in another software requires defining what you are actually delegating.
Let's take a fictional scenario: preparing a test report in a space without a personal account, then stopping before any sharing. This proposed process has not been carried out. It serves to distinguish three decisions: accessing an application, preparing an operation, and allowing its effect.
Two announcements, two different questions
October 1, 2026, GitHub announces in public preview the interactions of Copilot with desktop applications, in Copilot CLI and Copilot App on macOS and Windows. Access is based on application permissions and administrator controls. This announcement does not cover desktop control on Linux.
The same day, dynamic workflows move to public preview. They make it possible to describe orchestration in code: steps, parallelism, and review points. The scope includes the CLI, the app, and the SDK, the set of tools intended for integration Copilot in a program. In the CLI, the announcement asks to enable experimental features.
| Announced object | Question to ask before the pilot |
|---|---|
| Interaction with the desktop | Which applications and which operations are accessible? |
| Dynamic workflow | In what order are the steps executed and where do they stop? |
| Application authorization | What exact technical scope does it open? |
| Review of the result | Who approves the document and the expected business effect? |
These questions remain distinct. A scheduled orchestration can organize an analysis that is wrong. An application permission can open multiple actions of which only one is desired. The order of the process and the correctness of the result are verified separately.
Describe the action before opening access
In our example, 'producing the report' seems simple. However, it can mean reading a file, creating a document, overwriting an existing document, or transmitting information. Your instruction must specify the input, the output, the authorized location, and the stopping condition.
A first task could be: read only the summary results of the test repository, write a document in the demonstration folder, and display a preview. External sharing remains a separate step. The scope becomes understandable for the person reviewing, even if they do not know the agent tool.
The following matrix is a Partitech proposal for this pilot. It does not describe automatic settings of Copilot.
| Operation | Proposed authorization | Evidence to review |
|---|---|---|
| Read the summary results | In the pilot folder | List of files used |
| Prepare a report | In a new local location | Document and corresponding sources |
| Modify an existing report | After explicit comparison | Difference before/after |
| Share the document | New human decision | Recipient, content, and channel |
| Delete work data | Separate procedure | Exact list of the items concerned |
For each operation, examine its error cost and reversibility. Correcting a local title requires little effort. Removing a document sent to a third party can become impossible. This difference should be reflected by a visible boundary in the process, rather than by a general statement about caution.
Make the orchestration readable by the team
A workflow is the path that a task follows. By describing it in a program, you can make certain steps explicit: collecting inputs, requesting an analysis, checking its structure, and then presenting a result to a person.
Here is a conceptual pseudocode, without SDK syntax and without executable call. It illustrates our proposed process; it is not a tested example of the GitHub interface.
identifier les fichiers autorisés
vérifier que les entrées sont présentes
produire une proposition de rapport
contrôler les références et les sections attendues
présenter le rapport et les changements prévus
attendre une décision explicite
si la décision autorise une action précise : exécuter cette action
sinon : arrêter en conservant le brouillon
The program can impose a review step. It does not replace the review itself. A correct structure can contain an incorrect conclusion; a reference can point to the wrong test. Therefore, request that each useful statement refers to a verifiable entry, and that a lack of result be reported rather than filled in with a guess.
A structured result here means that the output distinguishes observation, source, and limitation. This contract facilitates independent verification: another tool or another reader can compare the sections to the input files. It does not turn sentences into evidence.
The documentation of dynamic workflows remains the reference for an implementation. Check its version at the time of coding. An orchestration prototype should not reuse an assumed SDK signature from a simple educational diagram.
Place the review before the effect
The proper boundary is just before the change that commits the team. In the pilot, the draft can be prepared automatically, then the review must show the complete document, the sources used, and the planned action. Showing only ‘continue?’ does not allow a proper decision to be made.
Approval must relate to a defined object. If the content, the recipient, or the location changes after the review, the previous decision no longer exactly covers the operation. In that case, provide a new submission. This principle is part of our qualification method; it does not imply that all Copilot interfaces apply it automatically.
Also organize the stop. What remains when you cancel a session? Where can you find the draft? How can you know if an operation has already been carried out? A blind restart risks repeating an action. Before restarting, check the actual state of the output and the step reached.
The demonstration environment must make errors observable without using your usual accounts. Use dummy files and a test application, remove unnecessary access, and delegate revocation to an identified person. The pilot requires no purchase, no email, and no actual publication.
Test refusals as much as the expected path
Our qualification protocol begins with the authorized case: the inputs are present, the document is prepared, and the process stops at the expected point. Record the observed result without labeling it as an overall success. This first test checks only a single path.
Then add a missing entry, an out-of-scope file, and an unauthorized sharing request. The goal is to see if the system stops by indicating what is missing, rather than expanding its task. Also examine an external document containing a misleading instruction, for example asking to change the recipient. The document should remain data to be analyzed; it does not become a new authorization.
The minimal trace must allow the reconstruction of entries, decisions, and effects. Avoid indiscriminately collecting the contents of all documents. Define the people who can access these traces and their retention period within your existing process.
Our article on the sandbox and Copilot app traces explains the September announcements. It provides useful context, but its mechanisms do not automatically prove the coverage of desktop interactions announced on October 1.
Decide to proceed when the team can explain the authorized scope, check the draft, stop the process, and restore a reliable recovery state. If any of these elements are missing, adjust the pilot before adding applications. The new capability becomes useful when the delegation boundary remains visible.
Sources and verification date
GitHub sources reopened on October 6, 2026: interaction with the desktop, dynamic workflows and conceptual documentation. Previews can evolve. Matrix, scenario, and pseudocode are original Partitech proposals, without any claimed execution result.