Hi @N962908,
I would treat these as three separate problems rather than one overall “large data” issue.
1. ContextTokenLimitExceeded in Teams
The fact that the agent works from Copilot Studio/Copilot but fails in Teams is important. There has also been a recent Microsoft Q&A report of ContextTokenLimitExceeded getting stuck in a Teams conversation while the same agent continued to work in the Copilot Studio test pane.
I would first test with a new Teams conversation/session, rather than assuming the agent itself is broken.
From the agent side, I would also reduce unnecessary context:
- Keep global instructions concise and move detailed business logic into topics/tools where possible.
- Avoid adding large documents or overlapping knowledge sources just because they are available.
- Give knowledge sources clear descriptions so the orchestration layer can select the relevant source.
- Test the same prompt with some knowledge sources temporarily disabled to identify whether one source is contributing excessive context.
- Compare a fresh Teams session with the Copilot Studio test pane.
Microsoft's current orchestration guidance specifically recommends keeping instructions, inputs/outputs, tools and knowledge sources well designed rather than putting all logic into one large instruction set.
So I wouldn't immediately conclude that “more knowledge sources = token limit.” The Teams-specific reproduction is worth isolating separately.
2. The 2–5 minute flow timeout is expected for a synchronous response
This part has a much clearer answer.
For an agent flow/tool using Respond to the agent, Microsoft currently documents a 100-second action limit for the response. The flow itself can continue running much longer, but the agent should not wait synchronously for a 2–5 minute operation to finish.
That explains the behavior you're seeing:
Flow completes successfully → result is generated → agent has already timed out waiting for the response.
For a long-running operation, the better pattern is asynchronous response.
In the Respond to the agent action, open Settings → Asynchronous response and enable it. Microsoft documents that asynchronous agent flows can continue beyond the normal two-minute limit and return a callback response when the flow finishes. This is explicitly supported in Microsoft Teams, which is particularly relevant to this scenario.
Architecturally, I would use:
User
↓
Copilot Studio agent
↓
Start flow
↓
Immediate acknowledgement
"I've started processing this. I'll return the result when it's ready."
↓
Power Automate continues processing
↓
Callback / asynchronous response
↓
Agent → Teams
↓
Final result
If the result genuinely takes several minutes, I would not try to make the agent synchronously wait for it.
3. Don't return 2,000+ SharePoint rows to the agent
This is probably the biggest architectural issue.
The agent doesn't need the entire dataset in its context just because the flow can retrieve it.
Instead of:
SharePoint
↓
Get 2,000 rows
↓
Return all rows to Copilot
↓
LLM processes everything
I would use:
User question
↓
Determine required filters/criteria
↓
SharePoint query
↓
Filter / Select / Top
↓
Return only relevant records
↓
Agent summarizes
For example, if the user asks:
"Which projects are over budget?"
don't return all 2,000 projects. Have the flow calculate/filter the relevant records and return something like:
{
"count": 17,
"projects": [
{
"project": "PC0001",
"status": "Over Budget",
"variance": 12500000
}
]
}
There is also a documented 500 KB response limit for Copilot Studio connector responses. Microsoft specifically recommends filtering connector responses when the returned payload exceeds that limit.
So the important limit isn't simply “2,000 rows.” It depends heavily on the number of columns and the size of each record.
For large-data scenarios, I would consider:
$filter to reduce rows$select to reduce columns$top/pagination where appropriate- aggregation in the flow instead of returning raw records
- returning a summary plus only the records relevant to the question
- storing the full result externally and returning a reference/result ID when appropriate
Interestingly, Microsoft now also has SharePoint list knowledge support designed for analytical reasoning over lists, including preview support up to 120,000 rows, although quality/latency can degrade at large scale. That can be a better fit for some read/analysis scenarios than pulling thousands of rows through a Power Automate response.
One other point: I wouldn't automatically enable Express mode for a data-heavy flow. Microsoft's guidance specifically says Express mode is intended for logic-heavy flows and is not recommended when the flow moves large amounts of data, such as thousands of rows/large tables.
So my general pattern would be:
Small/fast operation
Agent → Flow → Filter/query → Small response → Agent
Long-running operation
Agent → Async Flow → Immediate acknowledgement
↓
Background processing
↓
Callback/result
Large dataset
Agent
↓
Interpret question
↓
Filtered/aggregated query
↓
Small structured response
↓
Agent generates final answer
The main thing I would avoid is using the flow as a mechanism to dump an entire SharePoint list into the agent's context. Let the data source do the filtering/aggregation first, and let Copilot Studio reason over the smallest useful result.
