2.5 Solution Rules & Constraints for Copilot Studio, Microsoft Foundry & Foundry Tools

Solution Rules & Constraints for Copilot Studio, Microsoft Foundry & Foundry Tools

Quick Answer: An agentic solution design is only credible if it is bounded by the platform's published quotas and hard limits and by the organisation's own written solution rules. Microsoft Copilot Studio enforces concrete ceilings that architects must design around: 500 knowledge sources per agent across all types, 1,000 topics per agent in Dataverse environments, 200 trigger phrases per topic, 100 skills per agent, 8,000 characters of instructions for a Copilot agent, 512 MB per uploaded file, a 5 MB connector payload (450 KB on Government Community Cloud), a maximum of 25 SharePoint site URLs per agent when generative orchestration is used, two Dataverse knowledge sources per agent with 15 tables each, and generative-AI message quotas that start at 50 requests per minute / 1,000 per hour for a small prepaid pack allocation and rise with pack count. Microsoft Foundry adds its own dimension of constraint through model deployment quotas, content-filter policy, region availability, and the declarative prompt agent versus code-first hosted agent boundary. Solution rules are the customer-authored layer on top: which models are permitted, which grounding sources are sanctioned, which actions require human approval, and which channels may ever be published.

A solution architect who cannot state the platform's limits will design an architecture that passes the whiteboard and fails the pilot. The failures are predictable and brutal: an agent that indexes beautifully for 400 documents and silently stops at 500; a connector integration that works for test payloads and throws at 5 MB in production; a customer-facing agent throttled at peak because nobody counted requests per minute against the environment's prepaid pack tier.

Defining solution rules and constraints is an explicit planning-domain skill on the AB-100 blueprint, and it has two halves: the platform constraints Microsoft publishes, and the solution rules the organisation writes for itself.

---

1. Copilot Studio Platform Limits an Architect Must Design Around

1.1 Authoring and Content Limits

1.2 Knowledge-Source Limits by Type

These are the limits most often missed in design reviews:

• SharePoint (integrated knowledge source): a maximum of 25 SharePoint site URLs per agent when the agent uses generative orchestration. Only modern pages are supported; modern pages containing SPFx components are not, and content from classic ASPX pages is not used to generate answers. Supported file types are DOC/DOCX, PPT/PPTX, and PDF.
• SharePoint file size: without a Microsoft 365 Copilot licence in the same tenant, generative answers can only use SharePoint files under 7 MB. With a Microsoft 365 Copilot licence and tenant graph grounding with semantic search enabled, files up to 200 MB are supported. This single sentence decides whether a 40 MB policy manual works or silently returns nothing.
• SharePoint lists: up to 15 lists, up to 35,000 rows across all 15, and list queries only return data from the first 2,048 rows. Lists with more than 12 lookup columns in the default view are unsupported.
• Dataverse: a maximum of two Dataverse sources per agent, each with a maximum of 15 tables.
• OneDrive and uploaded SharePoint: each source includes up to 1,000 files, 50 folders, and 10 levels of subfolders, with a 512 MB per-file ceiling and a synchronisation frequency of four to six hours.
• Sensitivity labels: documents labelled confidential or highly confidential, and password-protected documents, cannot be indexed. They appear as ready but never answer. This is a data-classification dependency, not a bug.
• ALM caveat: for unstructured-data knowledge sources, application lifecycle management is not supported — importing an agent does not reprocess knowledge sources. Grounding content must be re-established per environment.

1.3 Runtime Quotas

Quotas are expressed as requests per minute (RPM) and requests per hour (RPH) per Dataverse environment:

Separately, messages to an agent on a paid plan are capped at 8,000 RPM per Dataverse environment. When a quota is reached, the user simply sees a failure notice — there is no graceful queue. High-volume customer-facing agents, autonomous agents, and agents that fan out into many flows can exceed RPM or RPH even when the monthly message volume looks comfortable, because traffic is never uniformly distributed. Peak-hour modelling, not monthly averages, is the correct sizing input.

Power Platform requests are also bounded: 250,000 every 24 hours on a standard subscription, 6,000 on the Teams plan, and Power Automate flows triggered by agents consume that allocation.

1.4 A Constraint That Breaks Escalations

When Copilot Studio hands a conversation to Dynamics 365 Contact Center, it uses the Azure Communication Services channel, which enforces a 28 KB channel-data message size limit. Passing every topic-local and agent variable as escalation context can exceed it; the transfer then completes with a MessageSizeExceeded failure and no variables attached. Human agents receive a cold transfer. The mitigation is to curate an explicit escalation payload and clear unused variables before the handoff, not to pass the whole conversation state.

---

2. Microsoft Foundry Constraints

Microsoft Foundry (previously branded Azure AI Foundry, with Azure AI Services now presented as Foundry Tools) contributes a different constraint family:

• Agent form factor. Foundry offers declarative prompt agents — instructions, a model, and attached tools, hosted and run by Foundry with no application code or containers to maintain — and code-first hosted agents, where the customer brings a container built on a framework such as Microsoft Agent Framework, LangGraph, or Semantic Kernel and Foundry supplies the managed endpoint, scaling, identity, and observability. Choosing prompt agents caps customisation; choosing hosted agents accepts container lifecycle ownership. The rule must be written down before build starts, not negotiated per team.
• Model availability and quota. Deployment capacity is regional and quota-bound. A solution rule that says "use the newest frontier model" is unimplementable if that model is not deployable in the environment's residency region.
• Content filtering. Filter severity thresholds are a policy decision with measurable false-positive cost in domains such as clinical, legal, and safety content. The permitted configuration must be a stated rule, not a per-project choice.
• Tooling composition. Foundry Tools are attached through the toolbox; each tool added expands the agent's blast radius and its evaluation surface.

---

3. Writing Solution Rules: The Customer-Authored Layer

Platform limits are given. Solution rules are chosen. A complete AB-100-grade rule set answers six questions in writing and publishes them through the AI Center of Excellence:

1. Permitted models. Which Foundry models, at which versions, may be used for which data classifications — and who approves an exception.
2. Sanctioned grounding sources. Which SharePoint sites, Dataverse tables, and external connectors are approved as knowledge, and the explicit prohibition on indexing content above the organisation's sensitivity threshold.
3. Action authority. Which tool categories an agent may invoke autonomously, which require human-in-the-loop approval, and the monetary or record-count thresholds that force escalation.
4. Channel publication. Which channels an agent may be published to, and whether public, unauthenticated web publication is permitted at all.
5. Authentication posture. Whether tools run with the user's credentials or with a managed identity, and the default for each pattern.
6. Evidence obligations. What telemetry, transcript retention, and evaluation results must exist before an agent may be promoted to production.

A rule set that cannot be checked is decoration. Each rule should map to an enforcement mechanism — a Power Platform data policy, a tenant setting, an environment group, a pipeline gate, or a solution-checker rule — so that compliance is observable rather than assumed.

---

4. Common Failure Modes

• Designing to averages. Sizing an agent on monthly message volume and discovering RPM throttling on the first Monday morning peak.
• Attaching knowledge one document at a time. Reaching 500 knowledge sources with 500 PDFs, then having nowhere to grow.
• Stuffing instructions. Pushing reference content into the 8,000-character instruction field instead of into knowledge, crowding out guardrails and routing logic.
• Overlooking the sensitivity-label block. Building a compliance agent on a document library whose most important documents carry a highly confidential label and therefore can never be indexed.
• Assuming ALM carries knowledge. Promoting an agent solution between environments and assuming unstructured knowledge sources travel with it. They do not.
• Unwritten rules. Allowing each delivery team to choose models, thresholds, and channels independently, then discovering at audit that no two agents are governed the same way.

AB-100 Exam Tip: When a scenario states a specific number — 700 documents to index, a 12 MB manual, 40 SharePoint sites, a 6 MB connector response, a 28 KB escalation context — the question is testing whether you recognise a published platform limit. The correct answer restructures the solution to live inside the limit (consolidate, chunk, paginate, split the agent, add the Microsoft 365 Copilot licence, curate the escalation payload). Answers that propose "request a limit increase" as the sole remedy, or that ignore the number entirely, are distractors.