Forem: Bala Madhusoodhanan

Stop the Awkward Silence: Signals to Classic Orchestration

Bala Madhusoodhanan — Mon, 30 Mar 2026 06:30:30 +0000

Intro:
If you’ve used generative orchestration in Copilot Studio, you’ve seen the comforting “thinking” animation while the copilot works. Classic orchestration doesn’t do that out of the box. So when you kick off a longer task—like a RAG lookup or a flow call—the chat can look empty. No typing dots. Just silence.
That silence is a UX bug, not a feature. The fix is quick: send a Typing event immediately before the slow step, then add a short acknowledgement message to set expectations.

Configuration:

Locate the slow step or Topic where you have user feedback on the poor UX expereince (May be based on the user activity we might have logic where the heavy work starts: Create generative answers, a flow, or an HTTP/API call.)
Set Event type to Typing.

The example below the timer is set as 2100 ( milliseconds)

Add a brief acknowledgement message Right after the Typing event, add a normal message to set expectations. Keep it human and specific:

“Got it — searching our knowledge base. This may take a few seconds.”
“Working on your request — I’ll be right back with the details.”

Good UX patterns to include:

Time cue: “This usually takes ~5–10 seconds.” It sets expectations and reduces anxiety.
Specific context: “Checking SAP invoices…” feels more reassuring than generic “Working…”
Channel-aware: Typing events are short-lived (around 2-4 seconds). Always send an acknowledgement text so users see something even if the channel ignores Typing.

Closing Notes:
A great bot isn’t just smart — it’s considerate. In classic orchestration, adding a Typing event plus a short acknowledgement transforms a “silent” wait into a clear, reassuring experience. It takes less than a minute to wire up and pays off immediately in user confidence and perceived speed.

The Digital Paralegal: Amplifying Legal Teams with a Copilot Co-Worker

Bala Madhusoodhanan — Mon, 23 Mar 2026 04:42:42 +0000

Intro:
In the modern legal field, the workload is immense. What if every paralegal and lawyer had a diligent co-worker who could handle the first pass of a tedious document review? A partner that could instantly draft a preliminary analysis, freeing them up to focus on high-level strategy and legal reasoning?. Building on the experiment from last week on PageIndex knowledge source and how to build a reasoning agent.

Bala Madhusoodhanan

Mar 17

Beyond Vector Search: Building a "Reasoning Engine" in Copilot Studio

#copilotstudio #powerfuldevs #systemdesign #powerplatform

Comments

32 min read

'Digital Paralegal'—an AI agent that functions as a true co-worker. It assists by ingesting case files, cross-referencing them against established legal frameworks, and drafting the initial compliance report. The goal isn't to replace human expertise but to amplify it."

The Engine Room: Two Key Techniques Driving the Digital Paralegal
In this concept , couple of powerful techniques within Copilot Studio that allow it to move beyond simple Q&A and perform genuine, multi-step tasks
By combining them, we transform the Copilot into a true digital co-worker.

Technique 1: Intelligent Structuring with an AI Builder Prompt
The first trick is to treat the AI Builder model not just as a file reader, but as a data structuring specialist. Instead of simply extracting raw text (OCR), we provide it with a detailed prompt instructing it to act like an expert data entry assistant.

You are an expert data entry assistant specialized in extracting information from documents FileContent  . Your task is to accurately read the provided document, identify all questions and their corresponding answers, and format them into a clean markdown structure.

**Instructions:**

1.  **Analyze the Document:** Carefully examine the content of the AI Pre-Assessment App form.
2.  **Extract Key-Value Pairs:** Identify all explicit questions and the answers provided for them. Also, extract the key information from the header section (Case ID, Use Case Name, Risk Result).
3.  **Handle Numbering:** Preserve the original numbering of the questions (e.g., 1, 1.1, 2, 3).
4.  **Format the Output:** Structure the extracted information in markdown as follows:
    *   Use a top-level heading (`#`) for the main title of the document.
    *   Use a blockquote (`>`) for the header information.
    *   Use a second-level heading (`##`) for major sections like "Case Ownership."
    *   For each question-answer pair, format it as:
        *   **[Question Number]. [Question Text]**
        *   [Answer Text]

This forces the AI Builder to parse the unstructured content of the uploaded PDF or document and transform it into a predictable, well-formatted Markdown file. This step is crucial because it provides the next stage of our process with a clean, reliable, and easy-to-analyze input. It’s the equivalent of a human organizing their notes before starting an analysis.

We enable the "Enable code interpreter" on the AI prompt builder

Technique 2: Creating a Reasoning Engine with Generative Answers
The second, and most innovative, trick is how we use the Generative Answers node. Traditionally, this node is used to find and summarize information from a knowledge source. Here, we turn it into a powerful reasoning engine. Its key characteristics are role-playing, structured process definition, and strict output formatting. It begins by assigning a clear persona—an "Expert AI Governance and Compliance Officer"—which immediately sets the context and tone. It then explicitly defines a two-phase cognitive process: first, retrieve knowledge from a specific source, and second, apply that knowledge to the user's input. Finally, it enforces a rigid output structure by demanding a multi-section Markdown report and providing explicit instructions for each section. This highly prescriptive and procedural nature is what elevates the prompt from a mere query to a complete job description, enabling the AI to perform a complex, repeatable analytical task rather than just answering a question

You are an expert AI Governance and Compliance Officer. Your task is to conduct a detailed compliance review for the provided AI use case by referencing an external, authoritative knowledge source.
Your process will have two main phases, executed in a single response:
Knowledge Retrieval: You will first consult the specified knowledge source to extract all relevant compliance requirements.
Compliance Analysis: You will then use those extracted requirements to analyze the AI use case and generate a structured report.


Input 1: AI Use Case Details
You are provided with the following AI use case information:



Input 2: Knowledge Source
The authoritative compliance framework is located at the specified source: [Here, you would insert the pointer, e.g., "the provided PageIndex document," "the attached document: 'Compliance_Framework.pdf'", or "the content at API endpoint 'getComplianceDocs'"].
This source contains two critical sections you must locate and use:

"MEASURES REQUIRED TO BUILD TRUST": A set of rules and controls for AI projects (e.g., rules on transparency, data, training, and neutrality).
"NOTICE AND MENTIONS ON SCREEN": Specific text templates that must be displayed to users of AI applications.


Your Task: Generate a Comprehensive Compliance Report
Based on the rules retrieved from the knowledge source and the details of the AI use case, you must generate a single, structured markdown report.
The report must contain the following four sections:
AI Compliance Review: [Use Case Name]
Begin with a top-level summary of the project being reviewed.
Compliance Assessment
For each and every measure found in the "MEASURES REQUIRED TO BUILD TRUST" section of the knowledge source:
State the Requirement: Clearly list the compliance measure (e.g., "Clear purpose and data").
Provide Your Assessment: Analyze the "Remesh AI" use case against this rule and state your finding (e.g., "Action Required," "Compliant," "Needs Verification").
List Specific Recommendations: Justify your assessment and provide clear, actionable steps the project team must take to achieve compliance.
Required User-Facing Notices
Locate the template text in the "NOTICE AND MENTIONS" section of the knowledge source.
Draft the exact, customized text that must be implemented in the "Remesh AI" application's user interface.
Final Recommendation Summary
Conclude with a high-level, bulleted summary of the most critical actions the project team must take to address the findings of your review.
CRITICAL RULES:
Your analysis must be based exclusively on the information retrieved from the specified knowledge source. Do not use any prior knowledge.
Your output must be a single, complete markdown report. Do not provide commentary outside of this structure.
The analysis must be thorough, addressing every compliance measure from the source document.

Draft Output:
The generated output is a highly structured, actionable, and evidence-based compliance report, formatted as a professional Markdown document. Its primary characteristic is its methodical, checklist-style approach, where it systematically addresses each compliance requirement one by one. For every rule, it provides a clear three-part analysis: the Requirement itself, a decisive Assessment ("Compliant," "Needs Verification"), and concrete Recommendations, making the findings easy to digest and act upon. The output is not just a summary but a practical work plan, culminating in a "Final Recommendation Summary" that serves as an executive brief for the project team.

Furthermore, by drafting the exact "Required User-Facing Notices," the AI moves beyond analysis to content creation, delivering a tangible asset that can be directly implemented. This structure transforms the complex task of a compliance review into a clear, organized, and immediately useful document.

Beyond Vector Search: Building a "Reasoning Engine" in Copilot Studio

Bala Madhusoodhanan — Tue, 17 Mar 2026 07:56:53 +0000

Intro:
We've all been there. You build a powerful RAG copilot, feed it a dense, 100-page document, and ask a specific, nuanced question... only to get a vague, incomplete, or just plain wrong answer. Why does this happen?

The culprit is often our reliance on traditional vector search, which excels at finding "semantically similar" text but struggles to understand context, nuance, and structure. It finds words that sound like the answer, but it can't reason about the document to find the truth.

One of my work colleage shared about PageIndex which made me curious to explore.

The Experimental Setup:

To create a fair and direct comparison, I used a single Microsoft Copilot Studio instance and one source document: the official EU AI ACT .pdf. From this document, I generated two distinct knowledge sources. The first was a standard embeddings.json file, created by chunking the document and generating vector embeddings—the foundation for a traditional RAG approach. The second was a structured document-structure-pi.json file, which acts as a hierarchical "Table of Contents" or PageIndex, enabling a reasoning-based retrieval method. Within a single adaptive dialog, I configured two parallel SearchAndSummarizeContent actions. When a user asks a question, the first action queries only the embedding file, while the second action queries only the PageIndex file, each with specific instructions tailored to its method. This setup ensures that for the exact same user query, we can execute both retrieval strategies sequentially, allowing us to directly compare the quality of the generated answer and the runtime performance of each approach.

Feature	Vector Embedding File (embeddings.json)	PageIndex File (document-structure.json)
Structure	Flat List. A simple array of independent objects.	Hierarchical Tree. Nested JSON objects (nodes within nodes).
Core Unit	Text Chunk. An arbitrary segment of text (e.g., 512 tokens).	Logical Node. A section representing a chapter, paragraph, or heading.
Content	Raw, fragmented text content for each chunk.	Metadata. Each node contains a title and a summary, not the full text.
Relationships	None. Each chunk is disconnected from the others.	Explicit. Parent-child relationships are defined by the sub_nodes array.
Navigation	Semantic Search. You find content by vector similarity.	Structural Traversal. You navigate from parent nodes to child nodes.
Analogy	A stack of shuffled index cards.	A fully interactive Table of Contents.

The PageIndex output would look something like this

The setup in MCS was something like this

Prompt for LLM to navigate and create response for TextEmbedding data

You are an AI assistant. Your task is to answer questions about the provided document, the 'EU AI Act', using a retrieval-augmented generation (RAG) system.
1. Your Knowledge Source
Your knowledge is limited to a set of pre-processed text chunks extracted from the document. You do not have access to the full document or its structure.
2. Your Process
You must follow this specific process to answer user questions. Do not answer from your general knowledge.
Step 1: Receive a Query. When a user asks a question, your underlying system will convert it into a numerical representation (an embedding).
Step 2: Retrieve Relevant Chunks. The system will search a vector database to find text chunks from the document that are semantically similar to the user's question. These top-matching chunks will be provided to you as your sole source of context.
Step 3: Synthesize an Answer. You must carefully analyze the provided text chunks and synthesize them into a single, coherent answer.If the chunks contain enough information, formulate a direct and comprehensive response to the user's question. Base your entire answer on the information present in these chunks.
If the chunks are insufficient or irrelevant, you must explicitly state that you could not find a precise answer based on the information retrieved. Do not attempt to guess or fill in gaps with prior knowledge.

3. Your Response Format
Base your answer only on the information given to you in the retrieved chunks for each query.
Each query is independent. You have no memory of past retrievals or questions.
Your goal is to accurately represent the information contained within the specific text chunks you are given. If the context is fragmented or confusing, reflect that in your response by stating the limitations of the information you found. Begin.

Prompt for LLM to navigate and create response for PageIndex data

You are a sophisticated research assistant. Your task is to answer questions by intelligently navigating a structured document provided in a special JSON format called PageIndex.
1. The Document Structure (PageIndex)
The document is represented as a hierarchical JSON object. This is your in-context index or 'Table of Contents.'
The structure consists of nested nodes.
Each node has:node_id: A unique ID to retrieve the full content of that section.
title: The title of the section.
summary: A concise summary of what the section contains. This is your primary tool for deciding which sections are relevant.
sub_nodes: A list of child nodes, allowing you to traverse the document's hierarchy.

2. Your Reasoning Process
Do not try to answer the user's question from your own knowledge. You must follow this iterative, reasoning-based retrieval process:
Step 1: Analyze the Query & Scan the Index. First, carefully understand the user's query. Then, examine the top-level nodes of the PageIndex JSON. Read the title and summary of each node to identify which sections are most likely to contain the answer.
Step 2: Traverse and Select. If the top-level nodes are too broad, navigate down into the sub_nodes to find more specific sections. Formulate a plan by selecting one or more node_ids that seem most promising. Think out loud, explaining why you are choosing a particular section (e.g., "The user is asking about financial vulnerabilities, so I will start by examining node_id: '0007' titled 'Monitoring Financial Vulnerabilities'").
Step 3: Retrieve Content. Once you have selected a node_id, you will be given the full text content associated with that node.
Step 4: Synthesize and Evaluate. Read the retrieved content.If the content is sufficient to answer the user's question, formulate a comprehensive answer. Be sure to cite the title or node_id of the source section.
If the content is insufficient or only provides partial information, state what you've learned and what is still missing. Then, return to Step 1 to re-evaluate the PageIndex and select a new node to explore. You may need to do this multiple times to build a complete answer.
Step 5: Handle References. If the text mentions a reference (e.g., "as mentioned in the introduction" or "see table 5"), use the PageIndex to locate that section and retrieve its content to build a more complete context.
3. Your Response Format
Always think step-by-step.
When you decide to explore a section, state the node_id and your reasoning.
When you have gathered enough information, present the final answer clearly to the user.

Summary of Test Question Characteristics
The questions you used were not simple, fact-retrieval queries. They were specifically crafted to probe the architectural limits of different RAG systems. Their shared characteristics fall into five key categories:

Deep Specificity & Nuance:

Many questions required finding precise details buried within dense, legalistic text (e.g., "specific requirements for training data," "exceptions to the social scoring prohibition"). These "needle-in-a-haystack" queries test whether a system can go beyond high-level summaries to retrieve exact, granular information.
Cross-Sectional Reasoning:

Several questions required connecting information from different parts of the document (e.g., comparing 'high-risk' vs. 'prohibited' practices, or applying the definition of 'emotion recognition' to a high-risk classification). This tests the system's ability to synthesize answers, not just retrieve a single chunk of text.
Procedural & Sequential Understanding:

You asked about multi-step procedures (e.g., "what is the exact procedure... for non-compliant systems?"). These questions are challenging for systems that retrieve disconnected text chunks, as they test the ability to understand and present information in a correct, logical sequence.
Implicit Intent & Abstraction:

Some queries were based on user intent rather than explicit keywords (e.g., "My company is developing an AI to help doctors... What should I be concerned about?"). This tests the model's ability to infer the relevant sections (like "Medical Devices" or "High-Risk Systems") even if the exact query terms aren't in the text.
Handling of Legal and Conditional Language:

The questions consistently involved understanding the complex language of a legal document, including exceptions, conditions, and future-looking roles (e.g., the AI Board's role in amending the list). This pushes the system beyond simple fact-finding into genuine comprehension of conditional logic.

Testing output:
Testing the configuration to validate the quality of the knowledge source

Sl No	Question	TextEmbedding Data	Text Embedding Runtime Duration	PageIndex Data	PageIndex Runtime Duration
1	According to the AI Act, what are the specific requirements for the training, validation, and testing data sets for high-risk AI systems?	Requirements for Training, Validation, and Testing Data Sets in High-Risk AI Systems under the EU AI Act 1. Data Quality and Governance Data sets used for training, validation, and testing must meet specific quality criteria, including being relevant, sufficiently representative, and, to the best extent possible, free of errors and complete for the intended purpose of the high-risk AI system. Data governance and management practices must be appropriate for the intended purpose and should address: Design choices Data collection processes and origin, including the original purpose for personal data Data preparation operations (annotation, labelling, cleaning, updating, enrichment, aggregation) Assumptions about what the data measures or represents Assessment of data availability, quantity, and suitability Examination and mitigation of possible biases, especially those affecting health, safety, fundamental rights, or leading to discrimination Identification and addressing of data gaps or shortcomings that prevent compliance with the regulation12. 2. Statistical Properties and Representativeness Data sets must have appropriate statistical properties, especially regarding the persons or groups for whom the high-risk AI system is intended. These characteristics can be met at the level of individual data sets or through a combination of data sets12. 3. Contextual Relevance Data sets should consider, as required by the intended purpose, characteristics or elements specific to the geographical, contextual, behavioral, or functional setting in which the high-risk AI system will be used12. 4. Bias Mitigation There must be measures to detect, prevent, and mitigate possible biases in the data sets, particularly those that could negatively impact health, safety, fundamental rights, or lead to prohibited discrimination. Special attention is required for biases that may affect vulnerable groups, including racial or ethnic groups12. 5. Transparency and Compliance For personal data, transparency about the original purpose of data collection is required to facilitate compliance with Union data protection law. The use of privacy-preserving techniques is allowed, provided data quality requirements are still met2. 6. Use of Certified Third Parties Compliance with data governance requirements can be achieved by using certified third parties for verification of data governance, data set integrity, and data practices, as long as the regulation’s requirements are met2. 7. Access to High-Quality Data Sets Certain actors (providers, notified bodies, researchers, etc.) should be able to access and use high-quality data sets for the development and assessment of high-risk AI systems within their fields of activity2. These requirements are designed to ensure that high-risk AI systems are developed and evaluated using data that is robust, fair, and appropriate for their intended use, minimizing risks to individuals and society	12672	Requirements for Training, Validation, and Testing Data Sets in High-Risk AI Systems (EU AI Act) 1. Data Quality and Governance High-risk AI systems that use AI model training must be developed using training, validation, and testing data sets that meet specific quality criteria. Data governance and management practices must be appropriate for the intended purpose of the AI system 1. 2. Data Set Characteristics Data sets must be: Relevant and sufficiently representative for the intended purpose. As free of errors and as complete as possible. Possess appropriate statistical properties, especially regarding the persons or groups the AI system is intended to be used with. These characteristics can be met at the level of individual data sets or through a combination of data sets 2. 3. Data Collection and Processing Practices must address: Design choices. Data collection processes and the origin of data, including the original purpose for personal data. Data preparation operations (annotation, labelling, cleaning, updating, enrichment, aggregation). Assumptions about what the data is supposed to measure or represent. Assessment of data availability, quantity, and suitability. Examination and mitigation of possible biases that could affect health, safety, or fundamental rights, or lead to discrimination. Identification and addressing of data gaps or shortcomings 2. 4. Contextual Relevance Data sets should consider features, characteristics, or elements specific to the geographical, contextual, behavioural, or functional setting where the AI system will be used 32. 5. Bias Detection and Special Categories of Data Providers may process special categories of personal data (e.g., sensitive data) only if strictly necessary for bias detection and correction, and only if: Bias cannot be addressed using other data. Technical and privacy-preserving measures (like pseudonymisation) are in place. Access is strictly controlled and documented. Data is deleted once bias is corrected or at the end of its retention period. Processing activities are recorded with justifications for necessity 2. 6. Data Minimisation and Privacy The right to privacy and data protection must be guaranteed throughout the AI system’s lifecycle. Principles of data minimisation and data protection by design and by default apply. Measures may include anonymisation, encryption, and privacy-preserving technologies 3. 7. Documentation and Traceability Comprehensive records and technical documentation must be maintained, including information on data, algorithms, training, testing, validation processes, and risk management. High-risk AI systems should allow for automatic event logging throughout their lifetime 3. 8. Applicability For high-risk AI systems not using model training techniques, these requirements apply only to testing data sets 2. These requirements are designed to ensure that high-risk AI systems are developed and evaluated using data that is robust, fair, and respects fundamental rights, with strong safeguards for privacy and non-discrimination	12032
2	Summarize the AI Act's approach to regulating generative AI, including its classification, transparency obligations, and any specific rules for foundation models.	Summary of the EU AI Act’s Approach to Regulating Generative AI 1. Classification of Generative AI The Act refers to "general-purpose AI models," which include generative AI systems, and sets out classification rules for identifying those with "systemic risk" 1. 2. Transparency Obligations Deployers of AI systems that generate or manipulate image, audio, or video content (such as deepfakes) must disclose that the content has been artificially generated or manipulated. This disclosure requirement does not apply if the use is authorized by law for purposes such as detecting, preventing, investigating, or prosecuting criminal offenses. For content that is evidently artistic, creative, satirical, or fictional, the transparency obligation is limited to disclosing the existence of such generated or manipulated content in a way that does not hinder the enjoyment of the work. If AI-generated text is published to inform the public on matters of public interest, it must be disclosed as artificially generated or manipulated, unless it has undergone human editorial review and responsibility is held by a natural or legal person. All required information must be provided clearly and accessibly at the time of first interaction or exposure 1. 3. Specific Rules for Foundation Models (General-Purpose AI Models) Providers of general-purpose AI models must comply with EU copyright law, especially regarding text and data mining. If rightsholders have reserved their rights, providers must obtain authorization before using such works for training. Providers must publish a sufficiently detailed summary of the content used for training the model, including main data collections or sets, to increase transparency. This summary should be comprehensive but not technically detailed, balancing transparency with protection of trade secrets and confidential business information 2. The Act also sets harmonized rules for the placing on the market, use, and monitoring of general-purpose AI models, and requires codes of practice to facilitate effective implementation of detection and labeling obligations for AI-generated content 123. 4. Implementation and Enforcement Obligations for providers of general-purpose AI models will apply from August 2025, with codes of practice expected by May 2025. Member States must establish and notify rules on penalties and ensure effective enforcement by the date of application 3. Key Points Generative AI is regulated through classification, transparency, and specific obligations for foundation models. Transparency is a central requirement, especially for content that could mislead or inform the public. Foundation model providers face additional requirements regarding copyright compliance and data transparency. Enforcement timelines and governance structures are clearly defined to ensure compliance and market fairness	12516	AI Act’s Approach to Regulating Generative AI 1. Classification of Generative AI Generative AI models are considered a typical example of general-purpose AI models, as they can generate various types of content (text, audio, images, video) and perform a wide range of tasks. A general-purpose AI model is classified as having “systemic risk” if it: Has high impact capabilities, evaluated using technical tools, indicators, and benchmarks. Exceeds a computational threshold for training (specifically, more than 10²⁵ floating point operations). Is designated by the Commission based on equivalent impact or capabilities, even if not meeting the above criteria directly. Providers can argue that their model, despite meeting the threshold, does not present systemic risk due to specific characteristics, but the Commission has the final say on classification12. 2. Transparency Obligations Providers of general-purpose AI models must: Prepare and maintain up-to-date technical documentation. Provide information about the model to downstream providers to enable integration and compliance. Make documentation available to the AI Office and national authorities upon request. For models released under free and open-source licenses, transparency and openness are ensured if parameters (including weights), model architecture, and usage information are made public. Exceptions to transparency requirements exist for open-source models unless they present systemic risk2. For generative AI systems that interact with people or generate content: Users must be notified when interacting with an AI system, unless it is obvious. Special consideration is given to vulnerable groups (e.g., by age or disability). When AI systems process biometric data to infer emotions or assign categories, notification must be accessible to persons with disabilities3. 3. Specific Rules for Foundation Models (General-Purpose AI Models) Providers of general-purpose AI models (foundation models) have additional responsibilities: Maintain and update technical documentation. Provide information to downstream users. Comply with copyright law and publish summaries of training data. Enhanced obligations for models with systemic risk, including: Rigorous evaluation and risk mitigation. Incident reporting and cybersecurity measures. Open-source models are generally exempt from some transparency requirements unless they pose systemic risk12. Providers and deployers must implement technical solutions (e.g., watermarks, metadata, cryptographic methods) to mark and detect AI-generated or manipulated content, especially for synthetic content that could be mistaken for authentic (e.g., deepfakes). Deployers must clearly label AI-generated or manipulated content to disclose its artificial origin, with exceptions for creative, artistic, or satirical works, provided rights and freedoms are safeguarded3. Summary Table Aspect Requirement/Rule Classification Based on generality, computational thresholds, and systemic risk criteria Transparency Documentation, disclosure to users, marking AI-generated content, special rules for open-source Foundation Models Additional documentation, risk management, copyright compliance, enhanced rules for systemic risk All these measures aim to ensure responsible development, deployment, and use of generative AI, balancing innovation with transparency, safety, and accountability	13951
3	Article 9 mentions that the list of high-risk AI systems in Annex III can be amended. What is the process for amending this Annex?	Process for Amending Annex III (List of High-Risk AI Systems) under Article 9 Empowerment of the Commission: The European Commission is empowered to adopt delegated acts to amend Annex III. This includes adding or modifying use-cases of high-risk AI systems. Conditions for Amendment: Amendments can be made where both of the following conditions are fulfilled: The AI systems are intended to be used in any of the areas listed in Annex III. The AI systems pose a risk of harm to health and safety, or an adverse impact on fundamental rights, and that risk is equivalent to, or greater than, the risk posed by the high-risk AI systems already referred to in Annex III. Removal of High-Risk AI Systems: The Commission can also remove high-risk AI systems from the list if: The system no longer poses significant risks to fundamental rights, health, or safety. The deletion does not decrease the overall level of protection provided by the regulation. Consistency and Protection: Any amendment must not decrease the overall level of protection of health, safety, and fundamental rights and must ensure consistency with other delegated acts and take into account market and technological developments. Consultation and Evidence: Amendments are based on concrete and reliable evidence and may involve consultation with the European Artificial Intelligence Board. Procedure: The process follows the adoption of delegated acts in accordance with Article 97 of the regulation	8596	Process for Amending Annex III (List of High-Risk AI Systems) The Commission is empowered to adopt delegated acts to amend Annex III by adding or modifying use-cases of high-risk AI systems. Two main conditions must be fulfilled for such amendments: The AI systems must be intended for use in any of the areas listed in Annex III. The AI systems must pose a risk of harm to health and safety, or an adverse impact on fundamental rights, and that risk must be equivalent to or greater than the risk posed by the high-risk AI systems already listed in Annex III. The Commission can also remove high-risk AI systems from Annex III if: The system no longer poses significant risks to fundamental rights, health, or safety, considering specific criteria. The removal does not decrease the overall level of protection of health, safety, and fundamental rights under Union law. The Commission may consult the European Artificial Intelligence Board and is required to ensure that any amendments do not decrease the overall level of protection provided by the Regulation. The process includes the possibility of adding new conditions or modifying existing ones if there is concrete and reliable evidence regarding the risk profile of AI systems. Any amendments must ensure consistency with other delegated acts and take into account market and technological development	6668
4	What is the difference between a 'high-risk AI system' and a 'prohibited AI practice' under the regulation?	Difference Between 'High-Risk AI System' and 'Prohibited AI Practice' Under the EU AI Act High-Risk AI System: These are AI systems that, due to their intended purpose and context of use, present significant risks to health, safety, or fundamental rights. High-risk AI systems are subject to strict mandatory requirements to mitigate risks and ensure trustworthiness. These requirements include risk management, conformity assessments, and compliance with applicable EU harmonisation legislation. Examples include AI systems used to influence election outcomes, unless their output is not directly exposed to natural persons (e.g., administrative tools for campaign organization), or systems listed in Annex I and III of the regulation. Some AI systems may be excluded from the high-risk category if they only perform narrow procedural tasks, improve results of completed human activities, detect decision-making patterns without influencing human assessment, or perform preparatory tasks. However, if the system performs profiling of natural persons, it is always considered high-risk123. Prohibited AI Practice: The provided extracts do not explicitly define or list 'prohibited AI practices.' However, it is implied that certain AI practices are outright banned if they infringe upon other Union laws or pose unacceptable risks, such as violating fundamental rights or being used in ways that are not lawful under other acts of Union or national law. The regulation states that the classification of an AI system as high-risk does not mean its use is lawful under all circumstances, and prohibitions may apply if the AI practice infringes other Union law2. Summary Table: Aspect High-Risk AI System Prohibited AI Practice Definition Significant risk, subject to strict requirements Outright banned, not allowed under any terms Regulation Approach Regulated, not banned; must comply with requirements Not regulated, simply forbidden Examples Election-influencing AI, profiling systems Not explicitly listed in provided extracts Lawfulness May be lawful if compliant Always unlawful if prohibited In summary, high-risk AI systems are regulated with mandatory requirements to mitigate risks, while prohibited AI practices are not allowed at all under the regulation. The distinction is that high-risk systems can be used if compliant, whereas prohibited practices are banned outright	11091	Understanding 'High-Risk AI Systems' vs. 'Prohibited AI Practices' under the EU AI Act Prohibited AI Practices These are AI systems and uses that are outright banned under the EU AI Act due to their unacceptable risk to fundamental rights, safety, or democratic values. Examples include: Manipulating or exploiting vulnerabilities of individuals. Inferring sensitive personal data from biometrics (such as deducing political opinions or sexual orientation from facial data). Social scoring of individuals or groups, which can lead to discrimination or exclusion. 'Real-time' remote biometric identification in public spaces for law enforcement, except in narrowly defined and strictly necessary situations. Creating or expanding facial recognition databases through untargeted scraping of images from the internet or CCTV. AI systems predicting criminal behavior based solely on profiling. Detecting emotions in workplace or educational settings (except for medical or safety reasons). These practices are not allowed under any circumstances, except for very limited exceptions (e.g., certain law enforcement needs with strict oversight) 12. High-Risk AI Systems These are AI systems that are not banned but are considered to pose significant risks to health, safety, or fundamental rights. High-risk systems are allowed on the market but must comply with strict requirements and oversight. Examples include: AI systems used to influence the outcome of elections or referenda. AI used in critical infrastructure, education, employment, law enforcement (outside the prohibited practices), migration, and access to essential services. High-risk systems must meet mandatory requirements such as risk management, data governance, transparency, human oversight, and compliance with existing product safety legislation. The classification as high-risk does not automatically make the system lawful under all other EU laws; it must also comply with data protection and other relevant regulations 123. Key Differences Prohibited AI practices are banned outright due to their unacceptable risk, while high-risk AI systems are permitted but subject to strict regulatory controls. Prohibited practices focus on uses that are fundamentally incompatible with EU values, whereas high-risk systems are those that require careful management and oversight to mitigate potential harms	10723
5	The AI Act prohibits social scoring by public authorities. Are there any specific, explicitly mentioned exceptions to this prohibition	Prohibition of Social Scoring and Exceptions in the EU AI Act The EU AI Act explicitly prohibits the use of AI systems for the evaluation or classification of natural persons or groups over a certain period based on their social behavior or inferred/predicted personal or personality characteristics, when the resulting social score leads to: Detrimental or unfavorable treatment in social contexts unrelated to the context in which the data was originally generated or collected. Detrimental or unfavorable treatment that is unjustified or disproportionate to the gravity of their social behavior. Based on the provided information, there are no specific, explicitly mentioned exceptions to this prohibition on social scoring by public authorities. The prohibition is stated in clear terms, and no carve-outs or exceptions are detailed in the retrieved text regarding this practice	5757	Prohibition of Social Scoring by Public Authorities under the AI Act The AI Act explicitly prohibits AI systems that provide social scoring of natural persons by public or private actors. This prohibition is based on concerns that such systems may lead to discriminatory outcomes, exclusion of certain groups, and violations of dignity, equality, and justice. The Act describes social scoring as evaluating or classifying individuals or groups based on multiple data points related to their social behavior in various contexts, or on known, inferred, or predicted personal or personality characteristics over certain periods. The resulting social score may lead to detrimental or unfavorable treatment in contexts unrelated to the original data collection or to disproportionate or unjustified consequences. Exceptions to the Prohibition The only exception mentioned is for lawful evaluation practices of natural persons that are carried out for a specific purpose in accordance with Union and national law. This means that while general social scoring is prohibited, evaluations for specific, lawful purposes that comply with existing legal frameworks are not affected by this prohibition. Summary Table General Rule: Social scoring by public or private actors is prohibited. Explicit Exception: Lawful evaluation practices for a specific purpose, in accordance with Union and national law, are not affected by the prohibition. There are no other specific, explicitly mentioned exceptions to this prohibition beyond lawful evaluation for a specific purpose under existing laws	8489
6	If a high-risk AI system is found to be non-compliant after it has been placed on the market, what is the exact procedure that national market surveillance authorities must follow?	Procedure for Handling Non-Compliant High-Risk AI Systems under the EU AI Act 1. Evaluation and Initial Action If a national market surveillance authority finds that a high-risk AI system does not comply with the requirements and obligations of the EU AI Act, it must require the relevant operator to take all appropriate corrective actions. These actions may include bringing the AI system into compliance, withdrawing it from the market, or recalling it within a period prescribed by the authority, but in any event within the shorter of 15 working days or as provided for in relevant Union harmonisation legislation. The authority must inform the relevant notified body accordingly. 2. Notification Beyond National Territory If the non-compliance is not restricted to the national territory, the authority must inform the European Commission and other Member States without undue delay about the evaluation results and the actions required of the operator. 3. Operator’s Responsibility The operator must ensure that all appropriate corrective action is taken for all concerned AI systems made available on the Union market. 4. Failure to Act If the operator does not take adequate corrective action within the specified period, the market surveillance authority must take all appropriate provisional measures. These may include prohibiting or restricting the AI system from being made available or put into service, withdrawing the product or standalone AI system from the market, or recalling it. The authority must notify the Commission and other Member States of these measures without undue delay, including all available details such as identification of the non-compliant AI system, its origin, supply chain, nature of non-compliance, risk involved, and the nature and duration of national measures taken. 5. Fines and Further Measures If the provider does not bring the AI system into compliance within the required period, they may be subject to fines in accordance with Article 99. If the system was misclassified as non-high-risk to circumvent requirements, the provider is also subject to fines. Market surveillance authorities may perform appropriate checks, especially using information stored in the EU database referred to in Article 71. 6. Union Safeguard Procedure If objections are raised by another Member State’s authority or the Commission regarding a national measure, the Commission will consult with the relevant parties and evaluate the measure. The Commission will then decide whether the national measure is justified and notify all relevant authorities of its decision. This process ensures a coordinated and transparent approach to addressing non-compliance of high-risk AI systems across the EU, with clear responsibilities for both operators and authorities, and mechanisms for escalation and enforcement at the Union level	13950	Procedure for Handling Non-Compliant High-Risk AI Systems by National Market Surveillance Authorities under the EU AI Act 1. Evaluation of the AI System If a market surveillance authority has sufficient reason to consider a high-risk AI system as non-compliant (posing risks to health, safety, or fundamental rights), it must evaluate the system for compliance with all regulatory requirements, giving special attention to risks affecting vulnerable groups. If risks to fundamental rights are identified, the authority must inform and cooperate with relevant national public authorities or bodies. 2. Corrective Actions If non-compliance is confirmed, the authority must, without undue delay, require the operator to: Take all appropriate corrective actions to bring the AI system into compliance, Withdraw the AI system from the market, or Recall it within a prescribed period, which must not exceed 15 working days or as specified by relevant Union harmonisation legislation. The authority must inform the relevant notified body about these actions. 3. Notification and Cooperation If the non-compliance is not limited to the national territory, the authority must inform the European Commission and other Member States without undue delay about the evaluation results and required actions. 4. Operator’s Responsibility The operator must ensure that all appropriate corrective actions are taken for all affected AI systems made available on the Union market. 5. Provisional Measures If the operator fails to take adequate corrective action within the prescribed period, the authority must take all appropriate provisional measures, such as: Prohibiting or restricting the AI system from being made available or put into service, Withdrawing or recalling the product from the market. The authority must notify the Commission and other Member States of these measures without undue delay. 6. Notification Details The notification must include all available details, such as: Identification of the non-compliant AI system, Its origin and supply chain, Nature of the non-compliance and risk, Nature and duration of national measures taken, Arguments from the relevant operator, Whether non-compliance is due to prohibited practices, failure to meet high-risk requirements, shortcomings in standards, or other regulatory breaches. 7. Response from Other Authorities Other market surveillance authorities must inform the Commission and Member States of any measures they adopt and any additional information about the non-compliance. If they disagree with the notified national measure, they must state their objections. 8. Justification and Restrictive Measures If no objection is raised within three months (or 30 days for prohibited practices), the provisional measure is deemed justified, and appropriate restrictive measures (such as withdrawal from the market) must be taken without undue delay. 9. Union Safeguard Procedure If objections are raised or the Commission finds the measure contrary to Union law, the Commission consults with the relevant parties and evaluates the national measure. Within six months (or 60 days for prohibited practices), the Commission decides whether the measure is justified and notifies all relevant authorities and operators. 10. Final Actions If the Commission deems the measure justified, all Member States must take appropriate restrictive measures and inform the Commission. If unjustified, the Member State must withdraw the measure and inform the Commission accordingly	13577
7	The act defines an 'emotion recognition system.' Based on that definition, would an AI system used by a company to analyze customer facial expressions for product feedback be considered high-risk?	Definition of 'Emotion Recognition System' The EU AI Act defines an 'emotion recognition system' as an AI system designed to identify or infer emotions or intentions of natural persons based on their biometric data. This includes emotions such as happiness, sadness, anger, surprise, disgust, embarrassment, excitement, shame, contempt, satisfaction, and amusement. The definition specifically excludes physical states like pain or fatigue and the mere detection of obvious expressions, gestures, or movements unless these are used to infer emotions 1. High-Risk Classification According to the Act, AI systems intended to be used for emotion recognition are explicitly listed as high-risk in the context of biometrics, provided their use is permitted under relevant Union or national law 2. Application to Customer Feedback Analysis If a company uses an AI system to analyze customer facial expressions for the purpose of inferring emotions (such as satisfaction or amusement) as product feedback, this system would fall under the definition of an emotion recognition system. Since emotion recognition systems are classified as high-risk AI systems under the Act, such a use case would be considered high-risk, subject to the Act’s requirements for high-risk AI systems 2. Summary An AI system used by a company to analyze customer facial expressions for product feedback would be considered a high-risk AI system under the EU AI Act, as it fits the definition of an emotion recognition system and such systems are explicitly listed as high-ris	10609	Definition of 'Emotion Recognition System' An emotion recognition system is defined as an AI system designed to identify or infer emotions or intentions of natural persons based on their biometric data. This includes emotions such as happiness, sadness, anger, surprise, disgust, embarrassment, excitement, shame, contempt, satisfaction, and amusement. The definition specifically excludes physical states like pain or fatigue and the mere detection of obvious expressions, gestures, or movements unless these are used to infer emotions. For example, simply detecting a smile is not enough—if the system uses that smile to infer happiness, it falls under the definition of emotion recognition 1. Application to Customer Feedback Analysis If a company uses an AI system to analyze customer facial expressions specifically to infer their emotional reactions (e.g., satisfaction, amusement, or disappointment) for product feedback, this system would fit the definition of an emotion recognition system as per the regulation 1. High-Risk Classification The regulation expresses serious concerns about the scientific basis and reliability of emotion recognition systems, especially regarding their potential for discriminatory outcomes and intrusiveness. However, it specifically prohibits the use of such systems in the workplace and education settings, except for medical or safety reasons. The prohibition does not explicitly extend to commercial uses such as customer feedback analysis in retail or service environments 2. High-risk AI systems are subject to strict requirements, but the regulation distinguishes between prohibited uses (like in employment or education) and other uses. Unless the customer feedback analysis system is used in a context that falls under the prohibited categories (workplace or education), it would not automatically be classified as high-risk solely based on its function as an emotion recognition system. However, it may still be subject to other requirements if it meets criteria for high-risk AI under the regulation 2. Summary An AI system analyzing customer facial expressions for product feedback is considered an emotion recognition system. It is not automatically classified as high-risk unless used in prohibited contexts (workplace or education). Other regulatory requirements may still apply depending on the specific use case and risk assessment	11416
8	What are the specific obligations of an 'authorised representative' for an AI provider that is not established in the EU?	Obligations of an 'Authorised Representative' for an AI Provider Not Established in the EU under the EU AI Act Mandate and Tasks: The authorised representative must perform tasks specified in a mandate received from the provider. This includes: Verifying that the required technical documentation (as specified in Annex XI) has been prepared and that all obligations referred to in Article 53 and, where applicable, Article 55 have been fulfilled by the provider. Keeping a copy of the technical documentation at the disposal of the AI Office and national competent authorities for 10 years after the general-purpose AI model has been placed on the market, along with the provider’s contact details. Providing the AI Office, upon a reasoned request, with all necessary information and documentation to demonstrate compliance with the obligations in the relevant chapter. Cooperating with the AI Office and competent authorities, upon a reasoned request, in any action related to the general-purpose AI model, including when the model is integrated into AI systems placed on the market or put into service in the Union. Communication and Compliance: The mandate must empower the authorised representative to be addressed, in addition to or instead of the provider, by the AI Office or competent authorities on all issues related to ensuring compliance with the Regulation. Termination of Mandate: If the authorised representative considers or has reason to consider that the provider is acting contrary to its obligations under the Regulation, it must terminate the mandate and immediately inform the AI Office about the termination and the reasons for it. Exemptions: These obligations do not apply to providers of general-purpose AI models released under a free and open-source licence that allows access, usage, modification, and distribution of the model, and whose parameters, architecture, and usage information are made publicly available, unless the models present systemic risks	8217	Obligations of an 'Authorised Representative' for Non-EU AI Providers under the EU AI Act Appointment Requirement: Providers of general-purpose AI models established in third countries (outside the EU) must, by written mandate, appoint an authorised representative established in the Union before placing their models on the EU market. Mandate and Tasks: The authorised representative must be empowered by the provider to: Verify that the technical documentation (as specified in Annex XI) has been prepared and that all obligations under Article 53 and, where applicable, Article 55, have been fulfilled. Keep a copy of the technical documentation and the provider’s contact details available for the AI Office and national competent authorities for 10 years after the model is placed on the market. Provide the AI Office, upon a reasoned request, with all necessary information and documentation to demonstrate compliance. Cooperate with the AI Office and competent authorities in any action related to the general-purpose AI model, including when the model is integrated into AI systems placed on the market or put into service in the Union. Be the contact point for the AI Office or competent authorities on all compliance issues, in addition to or instead of the provider. Termination of Mandate: If the authorised representative believes the provider is acting contrary to its obligations, it must terminate the mandate and immediately inform the AI Office of the termination and the reasons. Exemptions: This obligation does not apply to providers of general-purpose AI models released under a free and open-source licence, provided the model’s parameters, architecture, and usage information are made publicly available, unless the models present systemic risks. Confidentiality: All information or documentation obtained, including trade secrets, must be treated in accordance with the confidentiality obligations set out in Article	8009
9	The regulation establishes an 'AI Board.' What is its role in advising the Commission on the need to amend the list of prohibited AI practices in the future?	Role of the AI Board in Advising on Prohibited AI Practices The AI Board is involved in the evaluation and review process of the regulation, particularly regarding the list of prohibited AI practices. When the European Commission carries out evaluations and reviews of the regulation, it is required to take into account the positions and findings of the Board, among other relevant bodies. The AI Office is tasked with developing an objective and participative methodology for evaluating risk levels, which includes the potential inclusion of new systems in the list of prohibited practices set out in Article 5. This process ensures that the Board's expertise and input are considered when determining whether amendments to the list of prohibited AI practices are necessary, based on technological developments, impacts on health and safety, and fundamental right	7697	Role of the AI Board in Advising on Amendments to the List of Prohibited AI Practices The regulation specifies that the Commission is responsible for assessing the need to amend the list of prohibited AI practices (as laid down in Article 5) once a year following the entry into force of the regulation. In carrying out these evaluations and reviews, the Commission is required to take into account the positions and findings of the AI Board, as well as those of the European Parliament, the Council, and other relevant bodies or sources. The AI Board, therefore, plays an advisory role by providing its positions and findings to the Commission, which the Commission must consider when deciding whether amendments to the list of prohibited AI practices are necessary. This process ensures that the AI Board contributes expert input and oversight to the ongoing evaluation and potential revision of prohibited AI practices, supporting the Commission in maintaining up-to-date and effective regulation in response to technological and societal developments	8650

*My interpretion *:
It's clear that while both systems can retrieve information, the PageIndex method consistently delivers more precise, complete, and contextually aware answers. The TextEmbedding method often provides answers that are either incomplete or miss critical nuances.

Question #	Question Type	Text Embedding RAG Performance	PageIndex RAG Performance	Winner
1	Needle in a Haystack	Good, but less structured. It found most of the requirements but mixed them together.	Excellent. It provided a more structured, comprehensive, and well-organized list of requirements, including key details like bias detection for special data categories.	PageIndex
2	"Big Picture" Synthesis	Decent, but fragmented. It identified the main themes but the information was less cohesive.	Excellent. It gave a more detailed breakdown of "systemic risk" and provided a helpful summary table, showing a superior ability to synthesize information from multiple sections.	PageIndex
3	Navigational / Reference	Good. It correctly identified the process for amending Annex III.	Slightly Better. It provided a similarly correct answer but in a more concise and direct manner, suggesting a more efficient retrieval path.	PageIndex
4	Comparative / Relational	Poor / Incomplete. It failed to find the definition of "prohibited AI practice" in the retrieved chunks, leading to a one-sided and incomplete comparison.	Excellent. It successfully retrieved the definitions for both concepts from their respective sections and provided a clear, accurate comparison with concrete examples.	PageIndex
5	Exception to the Rule	Incorrect / Incomplete. It stated that there are no exceptions to the social scoring prohibition, missing the crucial nuance.	Correct & Nuanced. It correctly identified the general prohibition and the specific exception for lawful evaluations, demonstrating a deeper level of detail.	PageIndex
6	Procedural Deep-Dive	Good. It outlined the main steps for handling non-compliant systems.	Excellent. It provided a much more detailed, 10-step procedure, including timelines and the full Union safeguard process. This shows a more thorough traversal of the relevant chapter.	PageIndex
7	Definition Application	Incorrect. It correctly defined "emotion recognition" but then incorrectly classified the use case as high-risk without considering the context (workplace/education).	Correct & Nuanced. It correctly defined the term and correctly noted that while it is an emotion recognition system, it is not automatically high-risk because the prohibition is specific to workplace/education contexts.	PageIndex
8	Role & Responsibility	Good. It listed the main obligations for an authorized representative.	Slightly Better. The answer was almost identical, but slightly more structured. Both systems performed well here, likely because the answer was contained in a single, well-defined section.	Draw
9	Future-Looking	Vague. It correctly identified that the AI Board has a role but was vague on the specifics of the process.	Excellent. It provided a clear, step-by-step explanation of the AI Board's advisory role in the annual review process, demonstrating a better grasp of procedural details.	PageIndex

The Case for PageIndex: Why It Performed Better
The results speak for themselves. The PageIndex (reasoning-based RAG) approach consistently outperformed the traditional Text Embedding (vector-based RAG) for several key reasons that are evident in your test:

It Overcomes "Semantic Similarity ≠ Relevance" (Questions 4, 5, 7): o The most striking failures of the text embedding model were when it missed crucial context. It couldn't find the definition of "prohibited practices" (Q4), missed the exception for "social scoring" (Q5), and misinterpreted the "emotion recognition" classification (Q7). This is because the most relevant answer wasn't always the most semantically similar text chunk. PageIndex, by navigating the document's logical structure, could find the correct sections and assemble a complete, nuanced picture.
It Avoids Contextual Fragmentation (Questions 2, 6): o On "big picture" and procedural questions, PageIndex delivered far more comprehensive answers. For the non-compliance procedure (Q6), it returned a 10-step process, while the embedding method gave a more general overview. This is because PageIndex can read through an entire chapter logically, whereas the embedding method retrieves a scattered collection of the "most similar" chunks, which are often fragmented and incomplete.
It Understands Intent and Structure (Questions 1, 3, 9): o PageIndex consistently delivered more structured and detailed answers. This shows it doesn't just find keywords; it understands the document's hierarchy. By starting at the "Table of Contents," it can reason: "The user is asking about amending a list. I should look in the chapter on 'Amendments' and cross-reference it with the section on 'Prohibited Practices'." This is a level of reasoning that pure vector search cannot achieve.

Conclusion:
While text embedding is a powerful tool for finding topically related information, your results clearly show its limitations when dealing with complex, structured documents where precision, nuance, and an understanding of the document's internal logic are required.
The PageIndex method is demonstrably superior for tasks that require deep, contextual understanding and reasoning. It moves beyond simple keyword matching to mimic how a human expert would navigate a document, leading to more accurate, complete, and trustworthy answers.

On Vibe and Craft: A Conversation with Jeffrey Snover on the Soul of Software Engineering

Bala Madhusoodhanan — Fri, 06 Mar 2026 09:21:13 +0000

Last week, I had the distinct honor of speaking with Jeffrey Snover, the visionary behind PowerShell and the legendary Monad Manifesto. Our conversation was a profound exploration into the very soul of software development—what I've been calling "vibe coding." It’s that elusive blend of team flow, deep focus, and shared craftsmanship that separates truly great engineering cultures from the rest.

As someone who has spent his career building tools that reshape how we work, Jeffrey’s reflections—now from the vantage point are more relevant than ever. This isn't just about code; it's about the culture, mindset, and rituals that enable teams to build better, more sustainable software. Here are the key insights from our discussion.

My conversation with Jeffrey was a powerful reminder that the tools we build are secondary to the way we think and the culture we cultivate. The pursuit of a better software paradigm is, at its heart, a human endeavor.

RAG Showdown: Why Telling Your Agent Less Gets You More

Bala Madhusoodhanan — Mon, 02 Mar 2026 08:02:27 +0000

Building a RAG agent in copilot studio with sharepoint knowledge could be integrated with file based or sharepoint based. I wrote about this few months back.

Bala Madhusoodhanan

Oct 13 '25

Boost Response Clarity in Copilot Studio

#copilotstudio #powerplatform #powerfuldevs

Comments 2

3 min read

This got me thinking. The file upload method, which uses its own search index in Dataverse, is one of two primary ways to integrate knowledge. The other is the native SharePoint connector, which relies on M365's federated search. Both are valid, but they are not created equal. When should you use one over the other?

Feature	SharePoint (Federated Search)	File Based
Mechanism	Federated search using the M365 stack	Separate search index within Dataverse
Primary Advantage	Freshness. Near real-time indexing.	Quality. More thorough indexing of the full document.
Best For...	Frequently updated content where currency is critical.	Static or less frequently updated documents where response quality is the top priority.
Content Indexing	Indexes snippets and may not cover the entire document, especially for large files.	Indexes the entirety of the document, leading to more comprehensive answers.
Image Understanding	Limited. Focuses primarily on text.	Better. Can understand context from images within documents.
Latency (Speed)	Lower. Faster response times.	Slightly Higher. An extra access check step can add minor delays.
Sync Frequency	Instantaneous / Near Real-Time	4 to 24 hours.
Setup Complexity	Simpler. Just point to a SharePoint URL.	Requires an additional step to upload/sync files to Dataverse.

As you can see, the choice isn't about which is 'better,' but which is 'right' for your specific needs. If your knowledge base is a set of policies that change daily, the freshness of the native SharePoint connector is invaluable. But if you are using detailed, static manuals where comprehensive answers are a must, the quality from the Dataverse file upload method is the clear winner.

Another Tip:

Microsoft Copilot Studio already has its own powerful, hidden 'meta-prompt' specifically designed to handle citations. When you add your own, similar instructions, you create a conflict. The agent's underlying language model gets confused by these competing rules. This confusion leads to a critical failure. The platform has a non-negotiable business rule: if "general knowledge" is turned off, every single answer must have a citation. When your conflicting instructions cause the model to fail at generating a proper citation, this rule kicks in and blocks the response entirely.

Boost Your Productivity: M365 Copilot Makes Language Barriers Disappear

Bala Madhusoodhanan — Mon, 23 Feb 2026 07:31:50 +0000

Intro:
In an increasingly connected world, language can sometimes feel like the ultimate barrier to seamless communication and peak personal productivity. But what if understanding and responding to emails in any language was as simple as a quick setting change? With the powerful M365 Copilot engine, language translation isn't just a feature; it's a productivity superpower. This quick setting within Outlook transforms how you interact with global correspondence, allowing you to effortlessly navigate diverse languages and keep your focus on what truly matters, saving precious time and eliminating communication friction.

Setting Up Your Translation Preferences (One-Time Setup)
Before you start translating, it's a good idea to tell Outlook your preferred translation settings. This is usually a one-time setup, though you can adjust it anytime.

1) Access Translation Preferences:

Open any email in Outlook.
Look for a "Translate" option in the ribbon, or simply right-click on any text within an email.
From the context menu (or ribbon), select "Translation Preferences..." (as shown in your screenshot).
Alternatively, you can go to File > Options > Language and scroll down to the "Translation" section.

2) Choose Your Target Language:

Outlook will open the language options screen.
Under the "Translation" section, find the dropdown menu labeled "Translate messages into" and select your desired language (e.g., "English"). This is the language you want your emails translated to.

3) Define Translation Behavior:
You'll also see options for how Outlook should handle messages received in other languages:

Always translate: Outlook will automatically translate all incoming emails in languages other than your own.
Ask me before translating: Outlook will prompt you each time an email needs translation, giving you control. This is often a good choice for flexibility.
Never translate: Outlook will not offer translation for incoming emails. Select the option that best suits your workflow.

Confirm Settings: Click "OK" to save your translation preferences.

Translating an Incoming Email (Per Email Action)
Now that your preferences are set, translating individual emails is simple. Imagine you receive an important email in German, but you primarily communicate in English:

Open the Email: Navigate to the email you wish to translate in Outlook. You'll often see the foreign language text initially.
Initiate Translation: If you selected "Ask me before translating" in your preferences, Outlook will often present a prompt or a "Translate" button/banner at the top of the email. Click this to proceed.

Alternatively, you can right-click on the text within the email and hover over "Translate," then select "Translate Message."

Instantly, your email content will be translated into your chosen language, making it easy to comprehend the message. What's even cooler is that Outlook remembers this translation! When you open the email again, it will appear in the translated language.

You'll typically see a banner similar to your screenshot, stating, "Translated from: [Original Language]" with options like "Show Original" or "Translation preferences." This intelligent feature means you don't have to translate the same email multiple times—Outlook does the work and keeps it translated for you.

Building Beyond the Basics: 10 Architectural Principles for Power Platform

Bala Madhusoodhanan — Mon, 16 Feb 2026 07:30:31 +0000

Intro:
The Microsoft Power Platform have revolutionized how organizations develop solutions, empowering citizen developers and seasoned pros alike to build rapidly. This low-code/no-code paradigm drives incredible agility, but with great power comes great responsibility. Without a clear set of architectural principles, even the most innovative solutions can quickly become unmanageable, unsecure, or unsustainable.
Over the past few years, I was fortunate to work with some amazing developers and peers in this ecosystem. Here are the things that I have picked up and learned throughout by building systemic capability with varying complexity - The Architecture Principles. Think of architectural principles as your compass – a "North Star" – guiding every design decision to ensure your solutions are not just functional, but also robust, scalable, secure, and maintainable in the long run. Adhering to these will help you build solutions that stand the test of time and truly deliver business value.

Principle	Description	What It Means in Practice
1. Configuration-Driven & Low-Code First	Prioritize out-of-the-box features, declarative configuration, and low-code solutions over custom development. Minimize complexity and maximize maintainability, using custom code only when core platform capabilities are insufficient.	* Use environment variables and parameterized Power Automate flows for flexible deployments. * Leverage template-based app creation (Canvas/Model-Driven) for consistency. * Prefer Dataverse columns, forms, views, and business rules over custom JavaScript for Dynamics 365. * Avoid custom plugins or code where standard configurations (e.g., Flows, Business Process Flows) can achieve the same outcome.
2. Contextual & Purpose-Driven Design	Design solutions based on actual business needs and the unique organizational context. Avoid blindly adopting trends; evaluate patterns and practices for their specific applicability to the current problem, ensuring they add real value.	* Thoroughly understand business processes before solutioning in Power Apps or Dynamics 365. * Challenge "best practices" that don't fit your organization's specific requirements; avoid Cargo Culting. * Don't implement a complex AI Builder model if a simpler Power Automate flow with conditional logic suffices. * Avoid mimicking a previous solution from another project if the underlying business context or platform constraints are different (Domain Allergy).
3. Simplicity, Modularity & Reuse	Strive for the simplest solution. Break down complex problems into manageable, cohesive components with clear responsibilities and minimal dependencies. Actively promote the reuse of existing components, services, and patterns across the organization.	* Design Power Automate flows to perform single, well-defined tasks, and use child flows for common logic. * Create smaller, focused Canvas Apps that can embed other apps or components. * Utilize shared components in Canvas Apps and PCF controls for Dynamics 365 for UI reuse. * Centralize and govern shared Dataverse entities and option sets. * Leverage the Common Data Model where applicable to facilitate interoperability and reuse.
4. Zero Trust & Privacy by Design	Assume no implicit trust for any user or system. Embed user privacy protection, robust security measures, granular access controls, and data protection mechanisms into every aspect of the solution from conception.	* Use Role-Based Access Control (RBAC) with Multi-Factor Authentication (MFA) for all Power Platform access. * Disable telemetry in apps and flows unless explicitly opted-in and necessary. * Anonymise analytics data and strictly enforce Data Loss Prevention (DLP) policies. * Segment environments by sensitivity (e.g., production, development, highly confidential data). * Regularly review sharing settings for Power Apps, Flows, and Dataverse tables. * Apply least privilege access principles to all connections and data sources.
5. Compliance by Design	Embed regulatory, organizational, and ethical compliance considerations into the solution's design and development lifecycle from the very beginning. Proactively identify and address requirements like data residency, accessibility, and responsible AI use.	* Use Responsible AI assessment tools for any AI Builder or Copilot features. * Enforce data protection regulations (e.g., GDPR, HIPAA) in Power Automate flows and Dataverse security. * Automate audit logs and compliance reporting using Dataverse audit history. * Conduct regular security and accessibility assessments (e.g., Power Apps Accessibility Checker). * Ensure data sovereignty requirements are met by choosing appropriate Power Platform regions.
6. Cloud-Native & Green Efficiency	Design for optimal performance, scalability, and resource utilization inherent to cloud platforms, minimizing environmental impact. Leverage serverless capabilities, auto-scaling, and efficient processing.	* Use serverless Power Automate flows (standard or premium) and auto-scaling bots. * Schedule batch processing (e.g., Power Automate scheduled flows, Dataverse bulk operations) during off-peak hours. * Optimise expressions in Power Fx and Power Automate, and implement caching strategies (e.g., for reference data in Canvas Apps). * Design apps to minimize data retrieval and rendering. * Proactively monitor Power Platform consumption analytics to identify inefficiencies.
7. Observability & Resilience	Build solutions with comprehensive monitoring capabilities, and design them to detect, recover from, and gracefully degrade during failures. Implement structured logging, dashboards, and alerting.	* Implement structured logging within Power Automate flows (e.g., to Dataverse, Azure Application Insights). * Utilize Power BI for telemetry and analytics from Power Platform environments. * Build try-catch blocks and fallback logic in Power Automate flows to handle API failures or unexpected data. * Set up alerts for critical errors or performance degradation in Power Apps and Flows (e.g., using Power Platform Admin Center analytics). * Design for graceful degradation, providing users with feedback during outages rather than complete failure.
8. Iterative Evolution & Adaptability	Embrace continuous improvement and design for future changes, avoiding rigid structures that prevent adaptation. Design with loose coupling, well-defined interfaces, and maintainable code/configuration to facilitate easy modifications and updates.	* Design Dataverse solutions with managed solutions and clear component dependencies to facilitate updates and upgrades. * Use environment variables and connection references to easily move solutions between environments. * Avoid hardcoding values that are likely to change. * Architect integrations using well-defined APIs (like OData, Business Events) rather than tightly coupled direct database access. * Adopt an iterative development approach, allowing for continuous feedback and adaptation.
9. Thoughtful Integration Strategy & API-First	Select integration patterns based on specific requirements for real-time needs, data volume, complexity, and bidirectional needs. Understand the strengths and limitations of each pattern. Prioritize an API-first approach, designing APIs that are reusable, well-documented, and consumable by various systems, including Power Platform.	* API-First Approach: Define clear API contracts before implementation. Use Azure API Management to govern and publish APIs. * Use Business Events (F&O): For near real-time, event-driven integration between F&O and Power Platform. * Virtual Entities (Dataverse): For read-only, real-time access to F&O data in Dataverse without duplication. * Custom Connectors (Power Platform): Create for reusable, governed access to external APIs. * DMF (Data Management Framework) (F&O): For high-volume, asynchronous batch data import/export.
10. Structured Change Management	Implement a rigorous, yet agile, change management process for solutions. This includes version control, testing, deployment pipelines, and clear governance for modifications and environment promotions. Prevent ad-hoc changes and ensure stability.	* Utilize Azure DevOps (or similar) for source code control of Power Platform solutions and custom code. * Implement Power Platform ALM (Application Lifecycle Management) with managed solutions and dedicated environments. * Establish clear deployment pipelines for automated solution deployment (e.g., Azure Pipelines or GitHub Actions). * Define a formal process for requesting, reviewing, testing, and deploying changes to Power Apps, Flows, and Dynamics 365 customizations. * Implement regular regression testing to validate stability after changes.

Conclusion:
Adopting a principled approach to architecture is not about stifling innovation; it's about building a solid foundation upon which continuous innovation can flourish safely and efficiently within the Power Platform. By embracing these principles, you'll empower your teams to create solutions that are not only powerful today but also adaptable and resilient for tomorrow.

Querying Dataverse Using AI Builder’s Grounded Prompts

Bala Madhusoodhanan — Mon, 09 Feb 2026 07:03:38 +0000

Intro:
With the latest updates to Power Platform, AI Builder prompts can now be grounded—linked directly to your Dataverse tables. This transforms how you extract, summarize, and automate insights from your business data. In this guide, we’ll walk through creating and using grounded AI prompts to query Dataverse, step by step.

AI Builder Prompt:
This prompt is designed as a semantic search and summarization agent that takes a user's free-text query along with a markdown table of knowledge base articles, cleans and normalizes the data (including stripping HTML and handling duplicate columns), and applies a transparent, rule-based relevance scoring system to identify the most relevant articles. Only articles with a high confidence score (≥ 0.80) are returned, each accompanied by a concise, plain-text answer focused on actionable information. The output is a strictly formatted JSON array containing only the relevant articles, their ServiceNow links, and confidence scores—ensuring clarity, precision, and seamless integration with automated workflows in the Power Platform.


You will receive two distinct inputs:

1) user_query: userQuery A string containing the user's question. User Query 
knowledge_base_articles:  SNOWHEROVIEW.short_descriptionSNOWHEROVIEW.u_kb_article_content     A file containing a markdown table where each row represents a separate knowledge base article. The key columns are Article title, Article content (containing HTML), and ServiceNowLink.
{
  "Agent": {
    "Name": "DVSearch",
    "Role": "Semantic Search & Summarization Agent",
    "Function": "Identify relevant KB articles, extract concise plain-text answers, output high-confidence results as JSON."
  },
  "Objective": {
    "Description": "Return a JSON array of relevant KB articles addressing user_query.",
    "ConfidenceThreshold": ">= 0.80"
  },
  "Inputs": {
    userQuery  {
      "Type": "string",
      "Description": "Free-text question (e.g., 'What is the fix for the product receipt posting error')."
    },
  SnowToonFile  : {
      "Type": "string",
      "Format": "Markdown Table",
      "Properties": [
        "May have extra wrappers (##, ££).",
        "May have duplicate headers ('Article content').",
        "May contain HTML-heavy content."
      ]
    }
  },
  "Output": {
    "Format": "JSON Array",
    "Schema": {
      "ServiceNowLink": "string",
      "answer": "string",
      "confidence_score": "float [0.80-1.00], 2 decimals"
    },
    "EmptyArrayCondition": "If no articles meet >= 0.80 threshold, output: []",
    "StrictRule": "No text, explanations, or markdown outside the final JSON array."
  },
  "ProcessingSteps": [
    {
      "Step": "1. Parse & Preprocess Table",
      "Actions": [
        "Ignore leading/trailing non-table markers (##, ££).",
        "Identify header: first pipe-delimited row + delimiter (|---|).",
        "Normalize headers: trim, lowercase, collapse spaces.",
        "Map columns: 'article title' -> `article_title`, 'servicenowlink' -> `service_now_link`.",
        "Map 'article content' -> `article_content`: use last non-empty cell; if multiple non-empty, use longest.",
        "Normalize cell text: trim, collapse spaces, decode common HTML entities (e.g., &gt; -> >, &#34; -> \").",
        "Strip HTML from `article_content` completely: remove all tags (<p>, <ul>, etc.), data URIs, image-only content (ignore most alt text). Convert lists to plain sentences (periods/semicolons). Result must be plain text."
      ]
    },
    {
      "Step": "2. Understand Query",
      "Actions": [
        "Lowercase and trim `user_query`.",
        "Identify key entities/phrases.",
        "Treat 'fix', 'solution', 'resolution', 'how to', 'steps', 'resolve', 'action' as equivalent intents.",
        "For generic queries (e.g., error family), match articles whose title/content clearly address that family."
      ]
    },
    {
      "Step": "3. Relevance Scoring (0.00-1.00, 2 decimals)",
      "Components": {
        "TitleRelevance": {
          "Max": "+0.70",
          "Rules": [
            "+0.40 if title contains main error/entity (or close paraphrase).",
            "+0.30 if title includes most key query terms (non-stopwords) or exact error string."
          ]
        },
        "ContentRelevance": {
          "Max": "+0.30",
          "Rules": [
            "+0.15 if content provides clear root cause/diagnosis.",
            "+0.15 if content provides concrete, actionable steps (e.g., 'update X')."
          ]
        },
        "Penalties": [
          "-0.10 if article is about different process/module despite keyword overlap.",
          "-0.05 if mentions topic but lacks actionable steps/resolution."
        ]
      },
      "FinalAdjustment": "Clamp score to [0.00, 1.00]."
    },
    {
      "Step": "4. Threshold Filter",
      "Actions": [
        "Discard any article with `confidence_score` < 0.80."
      ]
    },
    {
      "Step": "5. Synthesize Answer (for kept articles)",
      "Actions": [
        "Create 1-3 sentence plain-text answer, directly addressing `user_query` using only cleaned text.",
        "Prefer 'root cause + essential steps'.",
        "Avoid UI fluff, screenshots, irrelevant labels, raw links, base64, image references.",
        "Must be plain text (no HTML)."
      ]
    },
    {
      "Step": "6. Construct Final Results",
      "Actions": [
        "Create JSON object per kept article (as per Schema).",
        "Skip article if `ServiceNowLink` is missing.",
        "Sort final array by `confidence_score` descending. Tie-breaker: more specific title match to query."
      ]
    },
    {
      "Step": "7. Final Output",
      "Actions": [
        "Output only the JSON array. No extra text."
      ]
    }
  ],
  "EdgeCases": [
    "Duplicate 'Article content' columns: Use last non-empty; if multiple non-empty, use longest.",
    "Empty content/strong title: "Score usually < 0.80 if no concrete steps/root cause.\","
    "No qualifying results: Return [].",
    "Language: Same as content; default English for mixed cases.",
    "Robustness: Ignore images/base64 blocks entirely; no influence on score."
  ]
}

Feature	Description
Inputs	User query (string), Knowledge base (Markdown table)
Output	JSON array (ServiceNowLink, answer, confidence_score)
Data Normalization	HTML stripping, column mapping, entity decoding, duplicate handling
Scoring	Deterministic, rules-based, 0.00–1.00, threshold 0.80
Answer Synthesis	1-3 sentences, root cause & steps, plain text only
Robustness	Handles wrappers, duplicates, empty content, images, mixed language
Determinism	Explicit steps, strictly defined output, tie-breaker rules
Security/Best Practice	No extra text, explanation, or markdown; skips articles with missing links
Usability	Designed for integration with Power Platform/AI Builder and flows

*Additional Settings Considerations for AI Builder with Dataverse
*
When configuring AI Builder for querying Dataverse, the settings you choose can significantly affect both the performance and accuracy of your results. Here are some key settings and recommendations based on the configuration options shown above:

Record Retrieval Limit - By default, the Record retrieval setting is set to 30. This means that only the first 30 records from your Dataverse table will be fetched and analyzed by AI Builder. Implication:

If your Dataverse table contains more than 30 records, the AI Builder might not provide comprehensive insights, as it only has visibility into a small subset of your data.
For Dataverse with More Than 1000 Records:

Recommendation: Use FetchXML to define a more targeted query. FetchXML allows you to filter and narrow down the subset of records retrieved, ensuring that AI Builder analyzes only the most relevant data. This approach is especially important for large datasets, as retrieving all records at once is not feasible and may lead to performance issues or incomplete results.
Example Use Case: If you need insights on records from the last quarter, use FetchXML to filter by date, status, or other relevant criteria before passing the data to AI Builder.

Other Important Settings Temperature - Controls the creativity and diversity of AI responses. Lower temperatures yield more predictable, conservative results, while higher temperatures allow for more varied and creative outputs. For enterprise data analysis, a moderate temperature is generally recommended to balance reliability and flexibility.

Include Links in the Response- When enabled, this option includes clickable links to source records in the AI-generated output. This is helpful for users who need to quickly verify or further investigate the data referenced by the AI.

Content Moderation Level - This setting controls the strictness of content filtering in AI responses. Higher moderation reduces the risk of inappropriate or harmful content but may also limit the AI’s ability to deliver certain types of information.

Summary Recommendation:
For large Dataverse tables (over 1000 records), always use FetchXML or similar filtering tools to narrow the dataset before invoking AI Builder. This ensures both efficiency and relevance in your AI-driven analyses. Additionally, adjust the other settings to fit your organization’s needs for reliability, transparency, and compliance.

Why This Matters
With grounded AI prompts, you can:

Query Dataverse tables directly from your prompts
Extract, summarize, and present live business data
Integrate intelligent automation into your apps and flows

Final Thoughts
This capability makes it easier than ever to build smart, data-aware solutions in Power Platform. Grounded prompts in AI Builder make it easier than ever to connect your AI workflows to live Dataverse data. Whether you’re summarizing proposals, checking order statuses, or surfacing knowledge articles, this new feature unlocks smarter, more dynamic automation in your Power Platform solutions.

Vibe or AI Coding: Are We Gaining Speed Only to Lose the Art?

Bala Madhusoodhanan — Mon, 02 Feb 2026 08:15:24 +0000

Everywhere you look, the message is clear: AI is revolutionizing software development. Tools like GitHub Copilot and more autonomous "agentic" AI promise to 10x our productivity, eliminate boilerplate, and turn ideas into code at unprecedented speeds. And in many ways, they deliver.

But as we race to adopt these powerful assistants, we need to pause and ask a critical question: What are we losing in the pursuit of speed?

I recently came across a viral meme (pictured above) that, while humorous, strikes at a profound truth. It shows that when you give AI to a senior developer, you get more high-quality output. Give it to a junior developer, and you get more output and more bugs. Give it to an unskilled user, and you get... well, a mess, just faster and at a larger scale.

This isn’t a critique of the AI. It’s a critique of our approach. We're treating AI as a magic wand, when we should be treating it as a power tool. A master carpenter with a nail gun can build a house in days. A novice with the same tool might just end up with a board full of bent nails.

The true "art of coding" has never been just about writing lines. It's about problem-solving, architectural thinking, and a deep, intuitive understanding of how systems fit together. It's the craft of building solutions that are not just functional, but also elegant, maintainable, and resilient. While AI-generated code is increasing, metrics for code reuse and refactoring are dropping. We're generating more, but we're thinking less about modularity and long-term health. The result? Higher code churn and technical debt that will come due sooner than we think.

This is the digital equivalent of losing our muscle memory. By outsourcing the "how," we risk forgetting the "why."

For Junior Developers: The temptation to accept AI-generated code without deeply understanding it can stunt the growth of critical thinking. Learning to code is about the struggle—the debugging, the refactoring, the "aha!" moments. When AI smooths over these struggles, it can rob us of essential learning experiences.
For Senior Developers: The danger is more subtle. Over-reliance can lead to a gradual decay of "code sense"—that intuitive feel for a system's design. We become reviewers and prompters, not architects and builders.

So, how do we harness the incredible power of AI without losing the soul of our craft? It comes down to shifting our mindset from automation to augmentation.

Treat AI as a Socratic Partner, Not a Vending Machine: Use AI to explore possibilities, not just to get an answer. Ask it for different approaches. Prompt it to explain its own code. Challenge its assumptions. Make it a tool for deeper thinking, not a replacement for it.
Mandate "Explain-Back" Sessions: A practice I love is having developers, especially junior ones, explain the logic behind any significant AI-generated code they commit. If you can't explain it, you don't own it. This forces comprehension over blind acceptance.
Implement "AI-Free" Zones: Consider "AI-Free Fridays" or designating core architectural components as human-only domains. This ensures that the foundational skills of problem-solving and design remain sharp. The goal isn’t to slow down, but to ensure our thinking remains deliberate and deep.
Focus on the "Why," Not Just the "What": The most valuable skill in the age of AI isn't writing code; it's defining the problem. Senior talent will be distinguished by their ability to provide the context, constraints, and high-level direction that guide AI to a successful outcome.

AI coding assistants aren't going away, nor should they. They are a monumental leap forward. But progress shouldn't mean sacrificing craftsmanship for speed. Let's use these tools to make great developers even better, not to create a generation of coders who can only operate on "vibes." The future of software depends on it.

Supercharge Your Emails by Teaching Copilot to Sound Like You in Outlook

Bala Madhusoodhanan — Mon, 26 Jan 2026 06:19:04 +0000

This series I have explored some incredible tools that boost our productivity. One such thing that I started to explore is the new features in Outlook: using Copilot to not only draft emails but to draft them in your unique voice.

Let's be honest, we all have a distinct style. Maybe you're direct and to the point. Maybe you're more formal, or perhaps you like to add a friendly, personal touch. The generic, robotic tone of early AI tools was a major limitation.

Microsoft has rolled out a brilliant feature that does exactly that. It analyzes your sent emails to learn your tone, phrasing, and sign-offs. In this post, we'll walk through how to set it up and use it to draft better, more authentic emails in seconds.

Draft with Copilot provided a email draft but I felt it was not my writing style

To set this up, I first used Copilot to analyse my sent emails and extract personalised style instructions that reflect how I naturally write. Once Copilot generated that guidance, I copied the instruction block and went into Outlook’s Copilot settings, where I enabled personalised drafting and pasted the instructions into the personalisation field. After saving the settings, I tested the setup by drafting a reply using Copilot to see how closely it matched my tone and workflow. If the output didn’t feel right, I refined the instructions and repeated the process until the generated drafts aligned with my communication style.

Here is the Instruction I provided to M365 copilot

Go through the provided email data (from the last 6 months) and identify the following:

Tone of Voice:

What is the typical "mood" or attitude of my messages? (e.g., confident, enthusiastic, formal, direct, friendly, etc.)
How does my tone change depending on the recipient's industry (e.g., finance vs. a creative agency)?
Provide 2-3 examples of phrases or sentences from my emails that best represent my primary tone.
Response Style:

Do I tend to write short, direct sentences or longer, more detailed paragraphs?
Do I mirror the communication style of the person I'm talking to?
Extract a sample of a concise email and a more detailed one to illustrate my range.
Conversational Flow:

How do I make my emails feel more human and less robotic?
Do I use approachable language, ask open-ended questions, or include humor or personal anecdotes?
Identify 1-2 examples of how I build rapport or make the conversation feel more natural.
Persona-Based Messaging:

How do I tailor my emails to different professional roles (e.g., VP of Sales vs. Operations Manager)?
What are the key pain points or value propositions I focus on for each persona?
Opening and Closing Style:

What are my most common opening lines and sign-offs? (e.g., "Hi [Name]," vs. "Dear [Name],", and "Best," vs. "Sincerely,")
Instruction Generation Phase:

Based on your analysis, generate a clear and concise set of instructions for an AI copilot. The instructions should be easy to follow and cover all the key elements of my communication style.

Once you get the output from the M365 copilot , lets update setting for draft with copilot. Navigate to Draft instruction and past the copilot instruction output.

Once the draft instruction is configured, lets explore how it would work with mailbox.

Now, when you generate a draft using the same prompt as before, the output will be tailored to your style.

Why This Matters for Your Workflow:
By mirroring your natural communication style, you maintain consistency and build trust. The recipient feels like they're talking to you, not a machine. This feature is a perfect example of how AI is evolving from a simple tool into a true assistant—one that understands not just what you want to say, but how you want to say it.

One Notebook to Rule Your Project: When Copilot Makes Sense

Bala Madhusoodhanan — Mon, 19 Jan 2026 07:52:21 +0000

Intro:
Today, work information is scattered across emails, slides, and documents, making it hard to stay organized. Microsoft 365 Copilot Notebooks gives you a scoped AI workspace.Instead of the AI giving you general answers from the internet, it provides reliable summaries based strictly on the documents you provided. This makes it much easier to get up to speed, ensures the facts are accurate, and saves you the time of digging through different apps to find the context you need.

*Features *
what you get and why they help

Scoped workspace: add up to 100 references (Word, PPTX, XLSX, PDF, OneNote pages, Copilot chats). Copilot answers are grounded only in these files.

Intelligent file suggestions: Copilot can recommend other relevant files from your Microsoft 365 environment.
Per-notebook custom instructions: define tone, audience, output format and constraints once for consistent outputs.

AI chat inside the notebook: ask questions, request drafts, or generate action lists that reference your files.
Audio overview: generate an AI podcast-style audio summary of the notebook for quick briefings and onboarding.
Cloud-connected and secure: notebooks reference current file versions in Microsoft 365; you control what Copilot can access. Why these matter:

Consistency: per-notebook instructions ensure everyone gets the same style and expectations.
Speed: synthesize hours of reading into one-paragraph briefs or audio recaps.
Traceability: outputs point to the files where facts came from, making verification straightforward.

Example scenario:
Vendor management — RFQ / RFP / Licensing review
Notebook name: VendorEvaluation_ACME_RFP_2026
Goal: Rapidly assess vendor compliance, commercial terms, risks, and produce an executive recommendation + negotiation plan.

Setup (what to add)
Primary references:
RFQ.pdf (requirements, scoring criteria)
RFP_response_vendorA.docx
RFP_response_vendorB.docx
License_terms_vendorA.pdf
License_terms_vendorB.pdf
Pricing_matrix.xlsx
Internal_requirements.docx (security, legal, SLAs)
Meeting_notes.docx (stakeholder comments)
Add only the files relevant to the specific procurement (keeps the notebook scoped and the AI focused).

Role: You are a procurement analyst focused on vendor compliance and negotiation.
Audience: Procurement manager and legal counsel.
Tone: Precise, risk-aware, and actionable.
Output preferences:
 - Executive summary: 3 sentences (decision + top 2 reasons).
 - Compliance checklist: table of requirement -> vendorA/vendorB -> status (Compliant/Partial/Non-compliant) with reference file and page/section.
 - Financial summary: high-level cost comparison and key pricing assumptions.
 - Negotiation plan: 5 action items with suggested owner and target date.
Fact policy:
 - Only use facts from the notebook references. For any claim not supported, respond: "Insufficient evidence — please add [file/section]."
 - When summarizing license terms, quote key clauses and reference file and section.
Risk rules:
 - Highlight contractual or compliance risks and indicate if legal review is required.

Example prompts to run in the notebook chat
a) “Produce a 3-sentence executive recommendation choosing Vendor A or B and list top two reasons (support each reason with a source file and section).”
b) “Create a compliance checklist comparing both vendors against Internal_requirements.docx and mark items Compliant/Partial/Non-compliant. Include file references for each status.”
c) “Summarize key licensing differences between vendorA and vendorB (support each difference with quote and file/section).”
d) “Generate a negotiation plan focusing on price, SLA penalties, and IP/license terms — 5 actions with owners and suggested dates.”

Quick tips & closing

Start small: try Copilot Notebooks on a single real project (e.g., one campaign or client engagement).
Use per-notebook custom instructions to reduce repeated prompts and keep outputs standardized.
Always review AI outputs and link action items to owners for accountability.
Use the audio overview for onboarding — it’s a surprisingly effective way to transfer contextual knowledge quickly.

Avoid the Personal vs. Business Trap: Picking the Right Connector Every Time

Bala Madhusoodhanan — Mon, 12 Jan 2026 07:38:25 +0000

Intro:
Citizen developers often face a subtle but critical challenge in Power Automate: many connectors look almost identical but behave very differently depending on whether they are tied to a personal account or an organizational account. Selecting the wrong connector can lead to Data Loss Prevention (DLP) violations, blocked flows, or compliance risks.

This article explores overlapping connectors, why they matter, and how to apply Design Thinking principles to make the right choice.

Why This Matters

Visual Similarity: Icons and action names often look the same (e.g., OneDrive vs. OneDrive for Business).
Impact of Wrong Choice: Using a personal connector in a corporate flow can break governance rules or expose sensitive data.
Design Thinking Tip: Always start with account type mapping during ideation—ask: Is this data personal or organizational?

*Category*	*Personal Connector*	*Business Connector*	*Learn More (URLs)*	*Typical Use Case*	*Why Business Is Preferred*	*Triggers/Actions Highlights*	*DLP Impact*	*Design Thinking Insight*
File Storage	OneDrive	OneDrive for Business	https://learn.microsoft.com/connectors/onedrive/ ; https://learn.microsoft.com/connectors/onedriveforbusiness/	Personal file automation	Built on SharePoint; enterprise sharing, legal hold, auditing	Advanced link sharing, file versioning	Personal often blocked	Is this file organizational? If yes → use Business connector
Spreadsheets	Excel Online (OneDrive)	Excel Online (Business)	https://learn.microsoft.com/connectors/excelonline/ ; https://learn.microsoft.com/connectors/excelonlinebusiness/	Tables in personal OneDrive	Larger files, robust triggers across SharePoint/Teams	Table triggers, pagination	Personal often blocked	If file is in Teams/SharePoint → use Business connector
Note-Taking	OneNote	OneNote (Business)	https://learn.microsoft.com/connectors/onenote/ ; https://learn.microsoft.com/connectors/onenotebusiness/	Personal notebooks	Shared team notebooks on SharePoint/OneDrive for Business	Page/section CRUD; search	Personal sometimes blocked	Shared notebooks require Business connector
Forms	Forms (Personal)	Microsoft Forms (Business)	https://learn.microsoft.com/connectors/microsoftforms/	Personal surveys	Organizational data routing, governance, storage in SharePoint/Excel	When a new response is submitted; get response details	Personal often blocked	Is the form tied to work account? If yes → Business
Email	Outlook.com	Office 365 Outlook	https://learn.microsoft.com/connectors/outlook/ ; https://learn.microsoft.com/connectors/office365/	Personal mail flows	Enterprise security, DLP, throttling for scale; deep integration	High-volume send limits, Teams hooks	Personal blocked in corporate	Always use Office 365 for work/school accounts
Calendar	Outlook.com Calendar	Office 365 Outlook (Calendar)	https://learn.microsoft.com/connectors/office365/	Personal calendar automation	Teams meeting integration; shared calendars; org controls	Create/update events; get events	Personal often blocked	If Teams integration needed → Business connector
Tasks	Microsoft To Do	Planner / To Do (Business)	https://learn.microsoft.com/connectors/todo/ ; https://learn.microsoft.com/connectors/planner/	Personal task lists	Team boards, assignments, buckets; enterprise auth	Create tasks, assign users, update status	Personal limited	Is the task collaborative? If yes → Planner
Cloud Storage	Dropbox	Dropbox for Business	https://learn.microsoft.com/connectors/dropbox/	Personal file backup	Team folders, audit logs, admin controls	Create/Move files; list folders	Personal may be restricted	Enterprise Dropbox → Business connector
File Sharing	Box	Box for Business	https://learn.microsoft.com/connectors/box/	Personal document sharing	Compliance features, admin policies, enterprise SSO	Upload/download, share links	Personal may be restricted	Use Business for retention/legal holds
Google Mail	Gmail	Gmail (Google Workspace)	https://learn.microsoft.com/connectors/gmail/	Personal automation	Admin-controlled, org directory integration	Send email, read threads	Personal often blocked	Workspace accounts → Business connector
Google Drive	Google Drive	Google Drive (Workspace)	https://learn.microsoft.com/connectors/googledrive/	Personal cloud storage	Shared drives, admin retention, security	Upload/download, list files	Personal may be restricted	Shared drives → Workspace connector
Google Calendar	Google Calendar	Google Workspace Calendar	https://learn.microsoft.com/connectors/googlecalendar/	Personal scheduling	Shared calendars, room resources, admin policies	Create events, list calendars	Personal often blocked	Is calendar shared? If yes → Workspace connector
Contacts	Outlook.com Contacts	Office 365 Contacts	https://learn.microsoft.com/connectors/office365/	Personal contacts	Global address list, Entra ID integration	Create/update contact; search	Personal blocked often	Org directory → Business connector

Closing Recommendations:

Always prefer Business connectors for organizational workflows.
Use DLP policies to enforce connector grouping and prevent accidental data leakage.
Educate citizen developers with visual guides and governance checklists.
Prototype with Design Thinking: Map user needs → Identify data boundaries → Choose connectors accordingly.