Fixing PR Review issues

Author: Randall-Knapp

learn-pr/wwl/design-overall-ai-strategy-business-solutions/includes/11-develop-use-cases-customized-small-language-models-solution.md

@@ -6,13 +6,13 @@ Recent advances in SLMs such as **Phi3** demonstrate performance previously asso
 
 Customized SLMs allow organizations to:
 
-- Improve accuracy on domain-specific tasks
+- Improve accuracy on domain-specific tasks.
 
-- Embed specialized reasoning safely within enterprise environments
+- Embed specialized reasoning safely within enterprise environments.
 
-- Reduce cost vs. large model fine-tuning
+- Reduce cost vs. large model fine-tuning.
 
-- Enable offline or near-edge operation for compliance or performance
+- Enable offline or near-edge operation for compliance or performance.
 
 SLMs have the advantage with specific factors such as cost, latency, and control. But it's a common misconception that they're always safer than LLMs and always reduce incorrect information. It's important as an architect to determine when an SLM will make more sense than a large model and considerations such as risks of over-using SLMs in an organization. 
 
@@ -50,13 +50,13 @@ SLMs minimize incorrect information by constraining model behavior around enterp
 
 When latency, cost, or compute footprint matters:
 
-- Mobile, IoT, or edge devices
+- Mobile, IoT, or edge devices.
 
-- High-volume inference environments
+- High-volume inference environments.
 
-- Real-time analytics or decision systems
+- Real-time analytics or decision systems.
 
-- Scenarios with intermittent or restricted connectivity
+- Scenarios with intermittent or restricted connectivity.
 
 SLMs reduce memory footprint significantly and ensure inference remains cost-predictable.
 
@@ -94,11 +94,11 @@ SLMs can be tuned to reflect organizational structured knowledge patterns.
 
 SLMs can serve as orchestrators or planners when:
 
-- Low-cost chain-of-thought reasoning is required
+- Low-cost chain-of-thought reasoning is required.
 
-- Multi-agent architectures rely on distributed reasoning
+- Multi-agent architectures rely on distributed reasoning.
 
-- Workflow routing requires domain logic
+- Workflow routing requires domain logic.
 
 SLMs with tuned reasoning outperform larger general-purpose models in specialized environments.
 
@@ -142,11 +142,11 @@ It's important to keep common pitfalls and risks in mind when identifying whethe
 
 ### Data requirements
 
-- High-quality curated datasets
+- High-quality curated datasets.
 
-- Domain-specific terminology and structured examples
+- Domain-specific terminology and structured examples.
 
-- Clean and labeled text corpora
+- Clean and labeled text corpora.
 
 ### Safety & governance requirements
 
@@ -176,7 +176,7 @@ When evaluating an SLM, architects can measure its success through specific metr
 
 - Drift or degradation over time
 
-**References (URLs you provided)**
+**References**
 
 - [Small Language Models for Application Interactions: A Case Study](https://arxiv.org/pdf/2405.20347)
 

learn-pr/wwl/design-overall-ai-strategy-business-solutions/includes/4-design-multi-agent-solution.md

@@ -2,24 +2,24 @@
 
 By the end of this unit, learners will be able to:
 
-- Apply a decision framework to choose **single-agent vs. multi-agent** architectures and justify the tradeoffs in security, scale, latency, cost, and operability
-- Select the **right platform** for each agent role—**Microsoft 365 Copilot (SaaS)**, **Copilot Studio (low-code SaaS)**, or **Microsoft Foundry (pro-code PaaS/IaaS)**—and define clear boundaries and contracts between agents
-- Orchestrate collaborating agents using proven **orchestration patterns** (sequential, concurrent, group chat, handoff, and Magentic) and implement them with the **Microsoft Agent Framework SDK**
-- Design a **connected agents** solution that assigns specialized roles and tools to each agent and validates the design through iterative prototyping
+- Apply a decision framework to choose **single-agent vs. multi-agent** architectures and justify the tradeoffs in security, scale, latency, cost, and operability.
+- Select the **right platform** for each agent role—**Microsoft 365 Copilot (SaaS)**, **Copilot Studio (low-code SaaS)**, or **Microsoft Foundry (pro-code PaaS/IaaS)**—and define clear boundaries and contracts between agents.
+- Orchestrate collaborating agents using proven **orchestration patterns** (sequential, concurrent, group chat, handoff, and Magentic) and implement them with the **Microsoft Agent Framework SDK**.
+- Design a **connected agents** solution that assigns specialized roles and tools to each agent and validates the design through iterative prototyping.
 
 ## When to use multi-agent and when not to
 
 **Start simple, scale when the evidence requires it.** A **single-agent** design consolidates logic, reduces coordination overhead, and simplifies governance—ideal when the domain is bounded, time-to-value is critical, and operating costs must be minimized. In contrast, **multi-agent** systems decompose responsibilities across specialized agents to enforce separation of concerns, align with team boundaries, and scale across domains—at the cost of added orchestration, latency at handoffs, and a larger security surface.
 
 **Choose multi-agent first when at least one of these is true**:
 
-- You must **cross security or compliance boundaries** (for example, strict data classifications or separation of duties)
+- You must **cross security or compliance boundaries** (for example, strict data classifications or separation of duties).
 
-- Multiple teams own distinct knowledge, data, or release cycles that benefit from **decoupled agents**
+- Multiple teams own distinct knowledge, data, or release cycles that benefit from **decoupled agents**.
 
-- The roadmap clearly demands **future expansion** across 3-5+ functions—modularity avoids later refactors
+- The roadmap clearly demands **future expansion** across 3-5+ functions—modularity avoids later refactors.
 
-- The business requirements dictate a series of actions occur with multiple dependencies across two or more workstreams
+- The business requirements dictate a series of actions occur with multiple dependencies across two or more workstreams.
 
 **Otherwise, validate with a single agent** before adding orchestration. Many "multi-agent" needs can be met with **persona switching**, improved retrieval, policy controls, or a larger context window. 
 
@@ -65,15 +65,15 @@ When agents collaborate, adopt **explicit orchestration** rather than ad hoc cha
 
 A robust multi-agent solution in **Foundry** follows these steps: 
 
-- **Define the main agent** (mission, guardrails, success metrics) and its **tooling** (retrieval sources, actions, evaluators)
+- **Define the main agent** (mission, guardrails, success metrics) and its **tooling** (retrieval sources, actions, evaluators).
 
-- **Identify connected agents** by role (for example, _Planner_, _Researcher_, _Reviewer_, _Actuator_), each with a minimal instruction set, scoped permissions, and well-defined inputs/outputs
+- **Identify connected agents** by role (for example, _Planner_, _Researcher_, _Reviewer_, _Actuator_), each with a minimal instruction set, scoped permissions, and well-defined inputs/outputs.
 
-- **Model collaboration**: choose orchestration patterns (above), define interface contracts, and design state handoffs (IDs, evidence, citations)
+- **Model collaboration**: choose orchestration patterns (above), define interface contracts, and design state handoffs (IDs, evidence, citations).
 
-- **Prototype quickly**: build a **connected agents** sample, run scenario tests, and measure latency, cost, accuracy, and alignment
+- **Prototype quickly**: build a **connected agents** sample, run scenario tests, and measure latency, cost, accuracy, and alignment.
 
-- **Iterate**: prune redundant agents, consolidate roles when evidence shows a single agent suffices, and strengthen evaluation gates
+- **Iterate**: prune redundant agents, consolidate roles when evidence shows a single agent suffices, and strengthen evaluation gates.
 
 ### Evaluation checkpoints
 
@@ -87,9 +87,9 @@ A robust multi-agent solution in **Foundry** follows these steps:
 
 - Are **observability hooks** (spans, events, metrics) in place at every handoff?
 
-- Does the main agent use natural language to route tasks, eliminating the need for hardcoded logic
+- Does the main agent use natural language to route tasks, eliminating the need for hardcoded logic?
 
-- Are the agents configured using a no-code interface in the Foundry portal or programmatically via the Python SDK
+- Are the agents configured using a no-code interface in the Foundry portal or programmatically via the Python SDK?
 
 ## Reference architecture
 
@@ -121,11 +121,11 @@ A robust multi-agent solution in **Foundry** follows these steps:
 
 ## Summary
 
-- Prefer **single-agent** for bounded domains and speed; adopt **multi-agent** when **security boundaries**, **team structures**, or **roadmap growth** require modularity
+- Prefer **single-agent** for bounded domains and speed; adopt **multi-agent** when **security boundaries**, **team structures**, or **roadmap growth** require modularity.
 
-- Use **Microsoft 365 Copilot** for inflow value, **Copilot Studio** for rapid business workflows, and **Foundry** for **connected, pro-code** orchestration
+- Use **Microsoft 365 Copilot** for inflow value, **Copilot Studio** for rapid business workflows, and **Foundry** for **connected, pro-code** orchestration.
 
-- Implement explicit **orchestration patterns** with the **Microsoft Agent Framework SDK** for reliability and transparency
+- Implement explicit **orchestration patterns** with the **Microsoft Agent Framework SDK** for reliability and transparency.
 
 ## References
 

learn-pr/wwl/design-overall-ai-strategy-business-solutions/includes/6-define-solution-rules-constraints-building-ai-components.md

@@ -6,11 +6,11 @@ This unit guides solution architects through defining **solution rules and archi
 
 By the end of this unit, learners will be able to:
 
-- Identify how platform differences influence architectural constraints
-- Define required guardrails for data, actions, and tool access
-- Decide how to establish solution-level rules for responsible behavior
-- Decide how to define environment, networking, and operational constraints
-- Decide how to create a unified rule framework across Copilot Studio and Foundry
+- Identify how platform differences influence architectural constraints.
+- Define required guardrails for data, actions, and tool access.
+- Decide how to establish solution-level rules for responsible behavior.
+- Decide how to define environment, networking, and operational constraints.
+- Decide how to create a unified rule framework across Copilot Studio and Foundry.
 
 ## Architectural foundations and platform roles
 
@@ -32,13 +32,13 @@ Copilot Studio provides a **low-code environment** for building task and retriev
 
 #### Solution rules
 
-- Use Copilot Studio for **workflow-bounded**, **task-driven**, or **information retrieval** scenarios
+- Use Copilot Studio for **workflow-bounded**, **task-driven**, or **information retrieval** scenarios.
 
-- Apply strict **connector scoping** to control data exposure
+- Apply strict **connector scoping** to control data exposure.
 
-- Define **task boundaries** that prevent the agent from making high-impact decisions
+- Define **task boundaries** that prevent the agent from making high-impact decisions.
 
-- Ensure prompt instructions reflect organizational policies
+- Ensure prompt instructions reflect organizational policies.
 
 ### Microsoft Foundry
 
@@ -56,35 +56,35 @@ Foundry supports **pro-code, high-complexity AI applications** and multi-agent s
 
 #### Solution rules
 
-- Use Foundry for **complex reasoning**, **multi-agent orchestration**, or **custom tool integration**
+- Use Foundry for **complex reasoning**, **multi-agent orchestration**, or **custom tool integration**.
 
-- Define strict **action boundaries** for tools that modify systems or trigger workflows
+- Define strict **action boundaries** for tools that modify systems or trigger workflows.
 
-- Apply **evaluation pipelines** to audit safety, correctness, and drift
+- Apply **evaluation pipelines** to audit safety, correctness, and drift.
 
-- Use **role separation** so each agent has scoped permissions
+- Use **role separation** so each agent has scoped permissions.
 
 ### Foundry tools
 
 Foundry Tools include model catalogs, tool APIs, agent orchestration frameworks, evaluation utilities, and developer SDKs. They provide a versatile foundation but require carefully defined rules.
 
 #### Key constraints
 
-- Developers must manage memory lifetime, context, and data sensitivity
+- Developers must manage memory lifetime, context, and data sensitivity.
 
-- Agents can call external tools, making permissioning critical
+- Agents can call external tools, making permissioning critical.
 
-- Orchestration complexity increases with multi-agent designs
+- Orchestration complexity increases with multi-agent designs.
 
 #### Solution rules
 
-- Implement **least-privilege** permissions for each tool
+- Implement **least-privilege** permissions for each tool.
 
-- Use evaluation tools to test **failure cases** and **undesirable behavior**
+- Use evaluation tools to test **failure cases** and **undesirable behavior**.
 
-- Define **clear escalation rules** for when an agent must defer to humans
+- Define **clear escalation rules** for when an agent must defer to humans.
 
-- Document all tool integrations with security and auditing considerations
+- Document all tool integrations with security and auditing considerations.
 
 ## Data constraints and governance boundaries
 
@@ -94,29 +94,29 @@ Solution architects must define explicit guardrails around data to avoid overexp
 
 #### Rules
 
-- Provide agents **only the data they require**
+- Provide agents **only the data they require**.
 
-- Mask sensitive fields where retrieval is needed but full data is unnecessary
+- Mask sensitive fields where retrieval is needed but full data is unnecessary.
 
-- Limit grounding sources to curated, authoritative datasets
+- Limit grounding sources to curated, authoritative datasets.
 
-- For generative tasks, enforce constraints on what content agents can produce
+- For generative tasks, enforce constraints on what content agents can produce.
 
 #### Data movement and storage constraints
 
-- Prevent persistent storage of messages unless compliance requires it
+- Prevent persistent storage of messages unless compliance requires it.
 
-- Define memory policy (ephemeral vs. persistent)
+- Define memory policy (ephemeral vs. persistent).
 
-- Restrict cross-domain data access (HR, Finance, Legal)
+- Restrict cross-domain data access (HR, Finance, Legal).
 
 #### Compliance and regulatory constraints
 
-- Agents must conform to organizational regulatory obligations
+- Agents must conform to organizational regulatory obligations.
 
-- High-risk tasks (financial approvals, legal drafting, health decisions) require human review
+- High-risk tasks (financial approvals, legal drafting, health decisions) require human review.
 
-- Enable mandatory auditing for tool invocation
+- Enable mandatory auditing for tool invocation.
 
 ## Behavioral rules and responsible AI constraints
 
@@ -132,45 +132,45 @@ Define what an agent is _allowed_ and _not allowed_ to do.
   - "Agent may not decide"
   - "Agent may not execute financial transactions"
 
-- Include disallowed behaviors aligned to security, privacy, and safety policies
+- Include disallowed behaviors aligned to security, privacy, and safety policies.
 
-- Use structured instructions to prevent unsafe improvisation
+- Use structured instructions to prevent unsafe improvisation.
 
 #### Responsible AI (RAI) controls
 
-- Mandate use of bias and safety evaluation pipelines
+- Mandate use of bias and safety evaluation pipelines.
 
-- Apply strict instructions for citing sources, representing facts, and avoiding incorrect information
+- Apply strict instructions for citing sources, representing facts, and avoiding incorrect information.
 
-- Require human-in-the-loop checkpoints for high-impact actions
+- Require human-in-the-loop checkpoints for high-impact actions.
 
 ## Environment, deployment, and networking constraints
 
 ### Environment rules
 
-- Copilot Studio: Operates inside Microsoft 365 tenant boundary; isolated per environment
+- Copilot Studio: Operates inside Microsoft 365 tenant boundary; isolated per environment.
 
-- Foundry: Requires architected deployment environment (VNet, private endpoints, region constraints)
+- Foundry: Requires architected deployment environment (VNet, private endpoints, region constraints).
 
 - Microsoft 365 Copilot: Operates inside Microsoft 365 tenant boundary; operates within the company tenant.
 
-- Ensure separation of development, testing, and production with dedicated configurations
+- Ensure separation of development, testing, and production with dedicated configurations.
 
 ### Networking constraints
 
-- For Foundry: use private networking for confidential workloads
+- For Foundry: use private networking for confidential workloads.
 
-- Restrict external tool calls to allow domains
+- Restrict external tool calls to allow domains.
 
-- Require API isolation for sensitive system integrations
+- Require API isolation for sensitive system integrations.
 
 ### Operational constraints
 
-- Establish SLOs for reliability, latency, and throughput
+- Establish SLOs for reliability, latency, and throughput.
 
-- Require agent health monitoring and incident response plans
+- Require agent health monitoring and incident response plans.
 
-- Mandate rollback and failsafe procedures
+- Mandate rollback and failsafe procedures.
 
 ## Unified rule framework across platforms