GitHub Copilot harness: agent-created file can’t be passed to an agent-flow tool when the agent runs from a workflow Agent node

Question

GitHub Copilot harness: agent-created file can’t be passed to an agent-flow tool when the agent runs from a workflow Agent node

Rob G 0

We have a Copilot Studio agent on the GitHub Copilot harness with skills that run Python scripts to generate Word documents (.docx). The agent saves each document to SharePoint through an agent-flow tool (“When an agent calls the flow” trigger) with a FILE-type input (contentBytes / name).

Works: in the agent’s test chat, the agent passes the generated file to the tool and it saves correctly.

Fails: when the same published agent is started unattended from an AI workflow (SharePoint trigger → Get file content → Agent node with “An existing agent” → Create file), the agent builds the documents but every save fails with: connector binary parameter $.file.contentBytes is not valid base64; retry with the exact file:// attachment path or complete base64 The agent tried file:///app/workspace/<file>.docx paths. It reports that /app/created and /app/uploads are not writable in this run, so it can’t produce an attachment path.

Question: in an unattended Agent-node run, is there a supported way for file bytes produced by the agent’s code to reach a tool’s file input without the model writing the base64 into the tool arguments? If not, is it on the roadmap? Also, can the Agent node return created files as an output?

Environment: Copilot Studio (default environment), Agent node “An existing agent”, agent published, workflow published.

0 comments

2 answers

Your answer

Answer 1

Hello @Rob G
This looks more like a runtime limitation with unattended Agent-node execution than an issue with the SharePoint connector or your flow.

The key difference is that in the interactive test chat, the GitHub Copilot harness can make an agent-created file available as an attachment and pass its file:// reference to a tool. In the unattended Agent node scenario, that attachment/file context does not appear to be available in the same way. A path such as /app/workspace/file.docx is local to the agent runtime and isn’t automatically converted into valid binary content for the flow’s FILE input.

I also wouldn’t recommend having the model generate and pass the complete DOCX as base64 in the tool arguments. That can run into size, truncation, or encoding issues.

For now, the safer pattern would be to have the agent return the structured document content/parameters, then let the workflow, an Azure Function, custom connector, or another service generate the DOCX and save the binary directly to SharePoint. The resulting SharePoint URL or file ID can then be returned to the agent/workflow.

I’m not aware of a supported configuration that automatically exposes files created inside the agent’s runtime as file outputs from an unattended Agent node. Likewise, I wouldn’t assume this is on the roadmap unless Microsoft Product Engineering has confirmed it.

so we will check with the appropriate team as it is expected behaviour or not and let you know the update.

Answer 2

There is currently no documented supported mechanism for an unattended workflow Agent node to transfer a file created in its code workspace into an agent-flow File input; move file creation and persistence into a workflow/connector operation that owns the bytes rather than asking the model to supply contentBytes.

Current supported boundary

The documented file-to-tool contract applies to user-attached conversation files. The tool input must be populated with a Custom value referencing System.Activity.Attachments; Microsoft explicitly says file inputs do not work through Dynamically fill with AI.^1^

If(
    IsEmpty(System.Activity.Attachments),
    [],
    [{
        contentBytes: First(System.Activity.Attachments).Content,
        name: First(System.Activity.Attachments).Name
    }]
)

That contract does not document any equivalent variable for files generated inside an unattended Agent-node workspace. Consequently:

A workspace path such as file:///app/workspace/report.docx is not documented as a valid Copilot Studio agent-flow file value.
The model should not place a complete base64 document in tool arguments.
The test-chat result does not establish that the same attachment bridge exists in an unattended workflow invocation.
The reported base64 validation error is consistent with the connector receiving a path string where it requires actual base64 content, but Microsoft documentation does not explicitly document that exact error or those workspace directories.

The path-to-base64 substitution documented for Copilot Cowork plugins is specific to the Cowork workspace. Cowork recognizes contentEncoding: base64, resolves workspace paths, and replaces them with bytes before invoking the server.^2^ It should not be treated as an available Copilot Studio Agent-node feature.

Recommended architecture

Keep the Agent node responsible for reasoning and return only the information needed to build the document:

Have the agent return structured document data, such as the filename, sections, tables, and destination folder.
After the Agent node, use a deterministic workflow action, connector, custom API, or flow to generate the DOCX.
Let that same component create the SharePoint file while it still owns the binary content.
Return the SharePoint item ID or URL to subsequent workflow steps.

For a new inline agent, the Agent node supports text, predefined structured output, and custom JSON-schema output. For an existing published agent, its response is exposed to later workflow steps. The documented output types do not include a file or binary output.^3^

If changing the generator is possible, another practical design is for the Python service or custom API to upload the DOCX directly to SharePoint and return only metadata to the agent. This avoids crossing the model/tool boundary with binary data.

Can the Agent node return created files?

Not as a documented Agent-node output. The available downstream outputs are:

a text response; or
fields from structured/custom structured output.^3^

The separate Files the agent creates preview feature surfaces files as downloadable cards in conversational experiences and stores them with the conversation. It documents a 10-MB per-file limit and 28-day conversation retention.^4^ It does not document exposing those files as Agent-node dynamic content, contentBytes, or a workflow file token. Therefore, a created-file card should not currently be relied upon as workflow output.

Roadmap status

No published item in the supplied Microsoft roadmap information explicitly commits to either:

generated-workspace-file to tool-file handoff in unattended Agent-node runs; or
binary/created-file output from an Agent node.

Microsoft directs customers to the Microsoft 365 Roadmap for released and upcoming Copilot Studio capabilities, but an explicit commitment or delivery date is not documented.^5^

For a production blocker, open a Microsoft support case and include:

environment and workflow IDs;
failed run ID, UTC timestamp, and conversation/run correlation ID;
Agent-node configuration showing An existing agent;
the agent-flow input schema;
the exact generated tool arguments with document content removed;
confirmation that interactive test chat succeeds but unattended execution fails.

Ask support to confirm whether generated-file attachment materialization is supported for existing-agent workflow invocations and whether a private roadmap item exists; no public documentation currently confirms either capability.

References