The details you've provided make this look less like an agent execution failure and more like a response handoff problem between the called agent and the agent node.
The strongest evidence is:
- Copilot Studio History shows the called agent as Completed.
- The expected JSON is present in that session.
- The calling agent node remains Running instead of receiving the response.
- The same task works in the Preview/Test channel.
- Shorter/easier reasoning succeeds more often.
- Both agent nodes show the same behavior.
- There was no flow change before the issue started.
1. Text response is not expecting you to manually select one of several messages
The current agent-node documentation describes Text response as a single string returned by the agent. Structured and Custom structured output are intended for cases where the workflow needs predictable machine-readable fields.
So I wouldn't expect the node to hang simply because the agent internally produces several reasoning/messages before its final answer.
That said, given your symptoms, I would absolutely test Custom structured output because your downstream contract is JSON anyway.
For example, instead of asking the agent to generate free-form text containing JSON:
"Return the result as JSON..."
define an explicit schema such as:
{
"status": "string",
"summary": "string",
"items": []
}
Then let the agent node return the structured object directly.
If Custom structured output succeeds consistently where Text response hangs, that would be very useful evidence that the problem is in the response serialization/transport path rather than the agent's reasoning.
2. The input-size threshold is interesting, but I wouldn't call 6,509 characters a documented limit
Your 5,700-character success / 6,509-character failure is a useful diagnostic observation, but I wouldn't conclude that 6,509 is the actual Copilot Studio limit.
The more interesting correlation is:
larger input → more reasoning → higher probability that the response never resolves in the Autonomous agent node.
I'd therefore test a matrix such as:
5,000 chars + simple reasoning
5,000 chars + complex reasoning
6,500 chars + simple reasoning
6,500 chars + complex reasoning
If complexity is the determining factor rather than raw characters, that points even more strongly toward a runtime/response-handling issue.
3. I don't see a documented per-agent-node timeout setting
The current Agent Node documentation says the workflow waits for the agent to complete, and then exposes the agent response to subsequent workflow steps. It doesn't document a configurable timeout property for the node.
So I wouldn't expect the Moderation setting to control this.
The fact that you can get 15–16 hour runs is particularly abnormal. Even if the underlying agent runtime is slow, an orchestration call remaining Running for that long without either a response or a failure is not something I'd treat as normal expected behavior.
4. Be careful not to confuse this with the 100-second flow limit
There is a separate documented 100-second limit for an agent flow that is called as a tool by an agent and uses a synchronous Respond to the agent action.
That's not necessarily the same scenario as your Run an agent / Agent node.
For the Agent Node itself, Microsoft's documentation describes the workflow as waiting for the agent to complete and then consuming its response.
So I would not use the 100-second limit alone to explain a node that remains Running for 16 hours.
5. Your Autonomous vs Preview comparison is probably the most valuable clue
I'd make this the core of a Microsoft support ticket:
Same agent
│
├── Preview/Test → succeeds
│
└── Autonomous → frequently remains Running
│
└── Called agent History = Completed
Response = valid JSON
That indicates the called agent is capable of completing the work, but the autonomous workflow isn't consistently receiving/settling the resulting response.
I'd capture the following from both a successful and failed run:
- parent workflow run ID
- called-agent session/conversation ID
- timestamps for both
- agent node input size
- output mode
- whether the called agent shows Completed
- exact response visible in agent History
- time at which the parent node entered
Running
- environment ID
- agent IDs
- whether the failing runs are always Autonomous
One experiment I'd definitely run
Create a minimal copy of the called agent with:
No knowledge sources
No tools
Very short instructions
One simple prompt
Custom structured output
Then call it from the same Autonomous agent node.
If that succeeds 100% of the time, add the complexity back in this order:
Simple agent
↓
+ structured output
↓
+ knowledge
↓
+ larger input
↓
+ complex reasoning
The step where the failure starts should give you a much better signal than rebuilding the entire flow again.
Also, Microsoft explicitly documents that the agent node's output can be consumed as either a single text response or structured fields, so moving to Custom structured output is a sensible diagnostic test, not just a workaround.
Given that this changed around 7 September 2026 without a flow change, and the backend agent itself is completing successfully, I'd be hesitant to make more architectural changes until that minimal reproduction is tested. If the minimal Autonomous agent still produces Completed in History but leaves the calling node Running, I'd escalate that as a platform/runtime regression in Autonomous agent-node response handoff rather than an agent prompt or SharePoint problem.
