From Writing Scripts to Running a Newsroom: A 24-Hour News Station with Microsoft Copilot Harness
Picture an evening commute. You open a page on your phone and hear two anchors delivering a coherent news bulletin. Headlines and timestamps move across the bottom of the screen. Tap a headline and the audio jumps to that story. Tap its source and the original report opens separately. Switch to English and you hear the same underlying facts—not an unrelated second news selection. That is the idea behind Meridian 24: a half-hourly China and world news podcast, with Chinese and English audio and a single HTML, JavaScript and CSS3 page. At first, it sounds like a simple recipe: search for news, ask a model to write a script, and turn the script into speech. Once we started building, the real challenge became clear. Getting AI to speak was relatively easy. Keeping a small newsroom working responsibly was not. 1. Why Introduce Microsoft Copilot Harness? The first script needed a better process, not prettier sentences Give a model a pile of headlines and it can produce a pile of summaries. The stories may not connect. Some search results contain too little detail, inviting the model to fill space with commentary. One agency may dominate simply because its reporting is easier to retrieve. Another instruction to “sound more professional” does not solve that problem. We needed an editorial method: collect public reporting, consolidate related events, identify missing details, research those gaps, prepare evidence-backed facts, and only then write a coherent two-anchor programme. A model can be a capable editor. A newsroom still needs a workbench, a filing system, task assignments and handovers. Microsoft Copilot Harness supplies a managed execution foundation for that work. Microsoft Foundry operates the agent loop and sandbox, coordinates model and tool steps, and supports native subagents, file operations and reusable skills, among other capabilities.[1][2] Developers can spend less time constructing the newsroom's office equipment and more time teaching it how to do useful work. A 22:30 production job should not lose its progress A bulletin involves retrieval, editorial requests, speech synthesis and audio encoding. If the service stops after ten speech segments have already been synthesized, starting everything again wastes time and money. Two capabilities matter here, and they should not be confused. Microsoft Copilot Harness operates the managed editorial runtime. Long-running resilience for Hosted Agents provides a foundation for restarting interrupted work. The application still decides what progress to save, how to resume and how to prevent duplicate publication.[1] We therefore did not put the entire station into one prompt. Nor did we interpret “managed” as “nothing left to engineer.” 2. How Do We Build the Application with Microsoft Copilot Harness? A managed editor, with a separate audio production room The existing Hosted service already knew how to call WebIQ, invoke speech synthesis, run FFmpeg and write to Blob. Instead of replacing it, we kept those deterministic responsibilities there and created a separate Prompt Agent using Microsoft Copilot Harness for research and editing. Figure 1: The purple boundary contains managed editorial execution. WebIQ and audio production run in external Hosted services. Important results are stored in Blob, not entrusted to a permanently available sandbox. Microsoft Copilot Harness owns the editorial execution: researching, organizing, delegating and drafting. Hosted code owns external API execution, validation, synthesis and publication. That boundary is also a practical preview requirement. You cannot switch an existing agent to a different harness during the initial public preview. We created a new editor and retained the original Hosted Agent's type and responsibilities.[2] Here is an abbreviated excerpt from the project's definition, omitting the full instructions and custom news tools: kind: prompt name: newsradio24-editor model: gpt-6.1-sol harness: type: microsoft_copilot_preview tools: - type: microsoft_copilot_toolset_preview defaultConfig: enabled: false configs: - name: filesystem_read enabled: true - name: filesystem_write enabled: true - name: shell enabled: true - name: subagents enabled: true gpt-6.1-sol is the model deployment name used in this project, not a promise that it is available in every project. Use a supported model already deployed in your own project region. See the full newsroom.yaml, and check official documentation for current preview fields and supported tools. Subagents are backstage editors, not extra presenters The audience still hears just two anchors. Behind the scenes, the work has three logical roles: Subtask role Input Output China research China reporting and evidence IDs Consolidated events, facts and research gaps World research International reporting and agency coverage Topic order, citations and expansion needs Fact verification Expanded evidence, briefs or scripts Citation checks, conflicts and bilingual consistency issues The parent editor delegates bounded tasks and merges their results. This project allows at most three subtasks per editorial request. These are not three separately deployed, permanently running services, nor an identical fixed trio instantiated in every phase. The sandbox acts as an editor's workbench: shell and file tools help organize JSON and inspect evidence IDs and topic order. Each conversation has a separate workspace, but that workspace is not a durable archive. Important outputs belong in durable storage.[2] The station currently describes its method through version-controlled instructions and request-level procedures. It has not published those procedures as separate Foundry Skills. Reusable skills are a supported extension opportunity, not something we should claim this implementation already uses. Let tools bring evidence, not credentials The editor requests discovery and expansion through collect_news and expand_news. Both accept an empty object. The server binds the news window and context, and the WebIQ key remains in the Hosted service. When an external function call arrives, Hosted code executes the search and returns a function_call_output with the matching call_id in the same conversation. The editor can continue without receiving credentials. This excerpt shows only the editorial request entry point—not the full tool-execution loop. payload carries the phase's procedure, evidence and output contract: import json import os from azure.ai.projects.aio import AIProjectClient from azure.identity.aio import DefaultAzureCredential async def request_editor(payload): async with ( DefaultAzureCredential() as credential, AIProjectClient( endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"], credential=credential, allow_preview=True, ) as project, project.get_openai_client( agent_name="newsradio24-editor", timeout=900, max_retries=2, ) as client, ): conversation = await client.conversations.create() return await client.responses.create( conversation=conversation.id, input=json.dumps(payload, ensure_ascii=False), ) The project uses azure-ai-projects 2.9.0. Read your own project endpoint from a server-side environment. Never put keys, real resource-group names or complete environment files into an article, browser code or sandbox. The complete adapter is in harness.py. 3. Where does it offer an advantage over a typical self-built agent harness? As a technical evangelist, I prefer describing the responsibility it removes rather than implying that nobody else can implement these capabilities. Open-source frameworks and custom systems can also support tools, delegation, state management and sandboxes. The distinction is that Microsoft Copilot Harness delegates part of that execution infrastructure to Foundry and connects it with the platform's agent definitions, identity and tool configuration. Question Typical self-built approach Microsoft Copilot Harness Who maintains the internal model/tool loop? Your team builds it or operates a framework runtime Foundry operates that runtime How are files, commands and subtasks integrated? Your team assembles execution and delegation mechanisms Use supported native capabilities How are agent definitions delivered? Establish your own configuration and release conventions Version declarative definitions alongside application code How is tool access governed? Depends on your framework and integrations Connect with Foundry roles, agent identity and connections How much runtime control is available? Greater control, with greater maintenance responsibility Less runtime operation, within supported capabilities and preview limits For a news station, that trade-off leaves more engineering time for evidence quality, editorial coherence and listening experience. It does not make reporting automatically true, remove permission configuration or support arbitrary models and tools. If you need to control the framework, dependencies, process model or specialized middleware, a Hosted Agent remains a sensible choice.[1][2] Costs do not disappear either. Inference, speech, retrieval, storage, traffic and runtime usage require a budget. Consult current regional service pricing and your agreement. The advantage is not “all engineering done for you.” It is a clearer opportunity to spend engineering effort on what makes your application different. 4. What Techniques Matter Most When Building a 24-Hour News Station? Turn reporting into facts before turning facts into sound Our production flow does not send raw search results directly to speech synthesis. It produces explicit intermediate deliverables: Figure 2: Each blue node has an inspectable data shape. Research gaps trigger an expansion loop. Editorial execution and audio production have separate validation gates. WebIQ searches public reporting from Xinhua, AP, AFP and Bloomberg. We check sources and dates. Homepages, advisories and headline-only results are discovery leads, not sufficient factual evidence. Related reports become topics. Missing details become targeted searches. If expansion still does not find enough evidence, shorten or omit the story rather than fill the silence with opinions. A section without sufficient facts should prevent publication. “Trending” also needs an honest definition: this implementation selects using relevance, recency and cross-source coverage. It does not possess a measured audience-popularity leaderboard. Agency balance must come from evidence, not relabeling Early programmes leaned toward Xinhua because more usable reporting was available. The answer was not to label those stories “AP.” We reserved candidate space for underrepresented agencies and added bounded expansion searches. Final selection keeps at most two China topics and four world topics. When at least two reliable non-Xinhua topics are selected, Xinhua is capped at half the programme. Sparse evidence may still produce an uneven mix. The page reports actual sources rather than inventing four-agency coverage. Neutrality is not achieved by asking the male and female anchors to exchange opposing opinions. They complement each other with cited facts and background, finish one story before moving on, and use transitions without manufacturing debate. Two languages should share one factual foundation If Chinese and English select stories independently, they can become different programmes. We prepare an ordered factual brief, draft the Chinese body, and adapt the English version from the same brief and Chinese content. Deterministic code adds introductions, AI-voice disclosure, greetings and polite sign-offs rather than hoping the model remembers every time. The Chinese anchors use MAI Voice 2.1's Wei and Mei; English uses Grant and Harper. The station has no sports section or third anchor.[3] “The voice is too slow” turned out to be a timing problem too Wei's Chinese delivery needed more pace. Instead of accelerating the entire programme in the browser, we applied pitch-preserving 1.25x tempo to Wei's synthesized tracks on the server. Mei and both English anchors remain at 1.0x. That decision requires measuring the processed tracks again before calculating story starts, assembling audio and encoding it. Otherwise, a “jump to story two” button may land in the wrong sentence. WAVs are working files. The final MP4 contains real AAC audio; it is not an MP3 with a different extension. The complete bulletin and every section must remain within 1,200 seconds, measured from actual audio. Oversized output is rejected, not cut in the middle of a sentence. Inspect the handover sheet, not the AI's claim of completion The station stores records for collection, topic organization, expansion, final briefs, Chinese scripts and English scripts. All four editorial phases must actually execute native subtasks and shell operations. A response saying “I checked it” is not sufficient. Here is an abbreviated illustration of two gates. Production checks runtime records per phase and duration after audio production: observed = harness.native_tools(response_outputs) if not {"task", "shell"} <= observed: raise RuntimeError("Missing native editorial execution") audio.check_duration(chapters, total_seconds) Native subtasks and shell operations run through the platform. They must not be mistaken for unresolved external functions that Hosted code still needs to execute. The implementation uses actual response events and call_id pairing, not the model's self-assessment. In one completed end-to-end run, Chinese audio measured 268.1 seconds and English 271.0 seconds. Verification covered all six phase records and story starts derived from actual WAVs. Those are results for one particular edition—not guarantees of future latency, quality or availability. Passing these gates establishes structural, citation and execution conditions. It is not proof of truth or semantic neutrality. Human editorial review still matters. Put recovery into the data and publication into a handover Completed evidence, scripts, WAVs and status live in private Blob storage. A resumed task reads checkpoints and reuses synthesized tracks rather than repeating every completed action. Only after Chinese and English are complete does a publication lease protect the catalogue update. One write reveals both outputs. Scheduled editions and manual extras have separate catalogues, so a manual success cannot be passed off as proof of a successful scheduled run. We also encountered a very practical deployment hurdle: the Hosted service's instance identity lacked project permission to create managed editorial conversations. Assigning Foundry User at the project scope to the correct calling identity, then allowing propagation, resolved it. Your user account having permission does not imply that the running agent has it.[2] Midnight is a real handover, not another replay “Keep one day” requires a shared definition of the day. We use the current Asia/Shanghai calendar date—not a rolling 24 hours, and not each visitor's local day for deleting shared Blob content. A separate task runs at Beijing midnight to prune expired catalogues, public/private audio, evidence, scripts, WAVs and runtime records, including snapshots and stored versions. Each production also sweeps to catch missed cleanup. Dated writes and cleanup share the publication lease, so an old job cannot recreate yesterday's files after deletion. The browser stops expired audio at rollover even if catalogue refresh fails. If today's first programme is not ready, it waits. Repeating the latest completed programme is allowed only within the current station day. Cleanup does not silently disable account-wide Azure soft-delete protection. If enabled, recoverable copies remain subject to that policy. Previously downloaded files cannot be recalled. The final details live on a phone screen The frontend needs no elaborate framework: a lightweight single page can offer a persistent player, headline ticker, source links, language switching and current-day listening on demand. A headline seeks the audio; a source link opens the report. Keeping those actions separate avoids an ambiguous click. Display all times in the listener's browser timezone while retaining Beijing time for paths and cleanup. Refresh catalogues every 45 seconds. Expect browser autoplay restrictions to require an initial tap. A desktop demonstration is not enough: exercise mobile playback, scrolling, seeking and timezone conversion. Closing Thought: A Useful Agent Is More than a Beautiful Answer The takeaway is not simply that AI can generate a podcast. It is that we gave the station understandable responsibilities, durable data and inspectable handovers. Microsoft Copilot Harness gives the managed editor tools, a workbench and delegation. Application code protects evidence, permissions, duration, publication and lifecycle boundaries. That is the agent story I want to tell as a technical evangelist: bring intelligence into a real workflow, rather than hide the workflow inside a prompt. Explore the current programme and interactive data-node diagram on the Meridian 24 page. The page retains only the current station day's content; it is not a permanent episode archive. Source Code Repo - https://github.com/kinfey/MSCopilotHarness.NewsPodcast References Microsoft announcement: Microsoft Copilot Harness and Hosted Agent long-running resilience Microsoft Learn: Microsoft Copilot Harness, including identity, workspaces and preview limitations Microsoft Learn: MAI Voice 2.1 and MAI Voice 2.1 Flash Project implementation and documentation Source Code RepoLand Your Offer - Anatomy of Revenue Generating Partner Offer - Part 4 - Cowork
So far this series has followed Copilot from a first trial (Part 1), through funded envisioning (Part 2), to a full rollout (Part 3). Part 4 turns to the newest step on that path: getting people to hand real, multi-step work to Copilot Cowork. This motion is different from the first three. There are no engagement hours to log and no T-shirt sizes to choose. Everything rides on one number: how many more people are using Cowork after three months. Grow that number and the rest follows. Microsoft has also announced that usage-based billing will be on by default for new Microsoft 365 Copilot Business licences bought through CSP from 1 December 2026, which removes a setup step between a customer and their first Cowork task. When what counts is the outcome rather than the effort, the winning approach is a fixed sequence you can run the same way for every customer. Where Cowork Fits Among the Copilot Experiences Every activation begins with the same conversation. Customers now have four ways to work with Copilot, and the first step is knowing which one suits which job. Chat Cowork Code Autopilot What it does Secure, fast AI for everyday questions, drafts and ideas Plans and carries out multi-step work across apps, files and systems Turns ideas into dashboards, trackers and apps An always-on personal agent with a name, a role and a goal Best for Quick, focused tasks in one conversation Complex jobs that pull several sources together into a finished result Reusable working solutions people return to Work that unfolds over days, such as chasing decisions and commitments How long it runs Seconds to minutes Minutes to hours, on its own Depends on what is being built Continuously, in the background Typical uses Daily briefing, project summary, content drafts Board preparation, financial close, contract review, campaign launch Team dashboards, recurring-task tools Flagging stalled decisions, resolving calendar clashes Cowork is the right home for work that takes multiple steps, spans two or more apps, and ends in an action such as an update, an approval or a routed request. Purely informational tasks stay in Chat. Built to Repeat: Why This Motion Scales Helping customers move that kind of work into Cowork looks much the same from one tenant to the next, and that is what makes this motion worth building. Design it once, and every new tenant reuses the same steps: The same lead-in. Readiness, licensing and billing checks take about four weeks and follow one checklist. The same assessment. Every pilot user runs one prompt that reads their recent work and tells you whether Cowork fits. The same sixty scenarios. Ten proven scenarios in each of six business functions, landed in the same order over three weeks. The same milestones. 50 active users and $2,500 of monthly Cowork usage in Month 1, held through Month 3. Reuse that compounds. Scenarios that work become shared Cowork skills, so each new tenant starts further ahead than the last. That consistency is what makes the motion predictable. The twelve-week activation does not need to carry a customer fee: Microsoft's partner programs reward the growth it creates, and what you realise rises as the customer brings more users on board. The monthly service that follows adds a further layer on top of that, one that keeps building long after the activation window closes. Package and sell it through whichever route your customers already use, whether directly, through your distributor, as a private offer, or as a listing in Microsoft Marketplace. The packaging is the easy part once the activities are the same every time. Sixty Scenarios Across Six Functions The most reusable of those activities is the scenario library: ten scenarios per function across all six, landed during Month 1. Each one is real delegated work, not a single prompt. Function Ten scenarios to land Executives Executive command centre; inbox triage at scale; board pre-reads; cross-org leadership briefs; weekly meeting synthesis; decision briefings; delegated memo and deck; performance analytics; relationship briefings; out-of-office handoffs Sales Meeting prep and follow-up; RFP responses; branded pitch and proposal; account research briefs; pipeline gap analysis; pipeline risk reviews; renewal and QBR prep; expansion identification; customer onboarding; ROI value stories Marketing Branded asset sets; launch activation kits; messaging and positioning docs; performance readouts; content drift audits; campaign kickoff; event command centre; customer-signal synthesis; competitive response; post-launch optimisation Customer Service Case-intake briefs; root-cause diagnosis; knowledge-cited replies; SLA-risk triage; stalled-case outreach; manager interventions; escalation handoffs; voice-of-customer synthesis; service operations review; coaching and training Finance and Operations Close and variance packages; weekly business review; reconciliation reviews; audit evidence packages; RFQ response builder; procurement bid-to-award; regulatory response; master-data automation; expense itemisation; market intelligence reports Legal Playbook contract review; draft from precedent; portfolio key terms extraction; playbook from precedents; map how contracts fit together; tracked-change editing; obligations and deadlines tracker; final draft check; case chronology; regulatory gaps Add Each User's Own Workflows with the Cowork Investment Advisor The sixty scenarios are a proven starting list. The Cowork Investment Advisor, the agent behind the Cowork Investment Assessment used throughout this playbook, finds the work that is specific to each person. It reads their Work IQ signals (emails, meetings, documents, chats and collaboration patterns) and returns: Persona: the role their work patterns point to, so you know which of the six functions to draw scenarios from. Top three workflows: the user's own tasks that qualify for Cowork, each rated Light, Medium or Heavy. Cost and return: estimated credits, pay-as-you-go and pre-purchase cost, and the return on that spend. Verdict: Yes (two or more qualifying workflows across two or more teams), Yes with a pilot (one workflow) or Not yet (none). A workflow only qualifies when it runs multiple steps, moves data between two or more apps, ends in a business action, includes decision points and tracks its own progress. Purely informational work is pointed to Copilot Chat, Copilot Pages or scheduled prompts instead. Choose the format that fits who is running it: a prompt any Copilot user can paste into Copilot Chat, an Agent Builder version a team lead can share, or a pre-built agent IT can deploy across the organisation. Run it alongside the scenario rollout, not ahead of it, and feed its results into the Customer Cowork Estimator to size credit spend. The Rules of the Window, Made Simple Scenarios and the assessment build the usage. A short set of rules decides when that usage counts. Which customers fit: at the August 2026 baseline, the customer has Microsoft 365 Copilot with Cowork enabled, fewer than 50 Cowork monthly active users and less than $2,500 of monthly Cowork consumption. At least half of their Copilot licences and Cowork consumption must come through CSP. Strategic 500 customers are excluded. What starts the clock: the first month the customer reaches at least 50 Cowork monthly active users and at least $2,500 of monthly Cowork consumption becomes Month 1 of a three-month window. What decides the payment: both thresholds must still be met in Month 3. Month 2 does not count towards qualifying, but it builds the usage Month 3 is measured on. How much: $50 for each qualified new user. Qualified new users are the lower of two numbers: Month 3 users minus August users, or extra monthly consumption divided by $50. The payment is at least $200 and at most $12,500 per tenant, which is 250 new users. When: 45 days after the window closes, paid as a rebate. It comes on top of your CSP consumption earnings. How often: once per customer tenant for the life of the incentive. If Month 3 falls short, the window lapses and a new one can start the next month both thresholds are met. June 2027 is the last month a window can start. Who can claim: partners with a Solutions Partner designation in Modern Work, Business Applications, Infrastructure, Data & AI or Digital & App Innovation, plus $1M (direct bill) or $25K (indirect reseller) of trailing 12-month revenue. Indirect resellers can qualify with 25 capability points instead of a designation. No Copilot specialization is needed. Attribution: the same partner must be transacting partner of record for both the Copilot licences and the Azure subscription that carries the Cowork consumption. Term: 1 September 2026 to 30 June 2027. What You Do in Each Stage Those rules shape a motion with four stages: Qualify, Activate, Sustain and Reward. Qualify (four weeks before Month 1): confirm you meet the partner requirements and finish your Partner Center setup. Find customers who meet the August baseline. Set yourself as transacting partner of record for licences and consumption. Move Cowork billing onto a CSP Azure plan with Owner or Contributor access, so Partner Earned Credit applies, and switch on the default spending policy. Activate (Month 1): two independent tracks run side by side; the assessment can start in the lead-in, and neither waits for the other. Assess the work: ask each pilot user to run the Cowork Investment Assessment, either as an agent or by pasting its prompt into Copilot Chat. It reviews three to six months of their work and answers Yes, Yes with a pilot, or Not yet, showing where Cowork adds the most value. Land the scenarios: roll out the six functions on a weekly rhythm: Executives and Sales in week 1, Marketing and Customer Service in week 2, then Finance and Operations and Legal in week 3. Keep usage unblocked: budget about $50 per user a month (roughly 5,000 credits) and set a Cowork spending limit of 250,000 credits or more a month, with alerts, so usage can reach the week 4 milestone without hitting a cap. Sustain (Months 2 and 3): save the scenarios that work as shared Cowork skills any team can reuse, and add pilot users to keep active users above 50. Check users, credits and attribution every week in Cost management in the Microsoft 365 admin center. Approve credit requests quickly and recover any dip before Month 3. Reward (after Month 3): calculate qualified new users, expect payment about six weeks after the window closes, and move the customer onto the monthly managed services. The tenant can only be paid once, so the next activation payment comes from the next tenant. Every Step, Week by Week Each stage breaks down into the steps below, and the same plan works for any eligible tenant. Timing is recommended pacing, not a program rule. Wk 1 is the first week of Month 1, and negative weeks are the lead-in before it. ID Stage Activity Timing (week) Exit Criteria Pre-req Customer fit Customer meets the August 2026 baseline Aug 2026 Copilot with Cowork enabled; under 50 Cowork users and under $2,500 monthly consumption; at least half bought through CSP; not Strategic 500 Q1 Qualify Confirm partner eligibility Wk -4 Solutions Partner designation and $1M (direct bill) or $25K (indirect reseller) trailing 12-month revenue Q2 Qualify Enrol and finish Partner Center setup Wk -4 to -3 Partner program agreement, incentive enrolment and CSP authorization in place; identity, tax and banking details accepted Q3 Qualify Find eligible customers Wk -3 Customer meets the August 2026 baseline Q4 Qualify Set attribution Wk -2 One partner is transacting partner of record for the Copilot licences and the Azure subscription carrying Cowork consumption Q5 Qualify Set up Partner Earned Credit and cost management billing Wk -2 to -1 CSP Azure plan with Owner or Contributor access (or Azure Lighthouse); default spending policy on, billed pay as you go A1 Activate Run the Cowork Investment Assessment Wk -2 to -1 Each pilot user rated Yes (2+ workflows across 2+ teams), Yes with a pilot (1 workflow) or Not yet A2 Activate Land Executives scenarios Wk 1 For example: command centre, board pre-reads A3 Activate Land Sales scenarios Wk 1 For example: pipeline risk reviews, RFP responses A4 Activate Land Marketing scenarios Wk 2 For example: launch activation kits, campaign kickoff A5 Activate Land Customer Service scenarios Wk 2 For example: SLA-risk triage, stalled-case outreach A6 Activate Land Finance and Operations scenarios Wk 3 For example: close and variance packages, audit evidence A7 Activate Land Legal scenarios Wk 3 For example: playbook contract review, obligations tracker A8 Activate Reach both thresholds Wk 4 50+ Cowork users and $2,500+ monthly consumption; attribution confirmed; spending limit of at least 250,000 credits a month S1 Sustain Turn proven scenarios into shared Cowork skills Wk 5 to 8 (Month 2) Skills reusable across teams; pilot users added to stay above 50 S2 Sustain Watch usage every week Wk 1 to 12 Users, credits and attribution checked weekly; limits tuned; dips fixed before Month 3 S3 Sustain Hold or grow usage Wk 9 to 12 (Month 3) Both thresholds still met and attribution unchanged; Month 3 results set the payment S4 Sustain Start a new window if needed Wk 13+ A new window opens the next month both thresholds are met; June 2027 is the last start R1 Reward Work out qualified new users End of Wk 12 Lower of (Month 3 users minus August users) and (extra monthly consumption ÷ $50), rounded down R2 Reward Apply the rate and limits End of Wk 12 $50 per qualified user as a full rebate; $200 minimum, $12,500 maximum per tenant R3 Reward Receive payment ~Wk 18 Paid 45 days after the window closes R4 Reward Keep growing through managed services Wk 19+ The activation payment does not repeat for this tenant; from here, managed services carry the growth: Cowork adoption and support and AI FinOps and governance every month, plus Cowork scale-out to new teams, and to new tenants that can start their own window Layer by Layer: What One Tenant Returns Run those steps on one tenant and three returns stack up during the window. Here is how they add up for a customer that starts from zero Cowork usage. Earning How it is worked out 50 new users At the cap: 250 new users Cowork CSP Activation Incentive $50 for each qualified new user, paid 45 days after Month 3 $2.5K $12.5K CSP incentive on Copilot Credits† 13% of monthly Cowork consumption (3% core plus 10% growth), over the three months ~$0.98K ~$4.88K Partner Earned Credit† 13% of monthly pay-as-you-go Cowork consumption on the customer's CSP Azure plan, while you hold eligible admin access, over the same three months ~$0.98K ~$4.88K Total per tenant, per window ~$4.5K ~$22.3K † Illustrative. Assumes $50 of monthly Cowork consumption per new user, so $2,500 a month at 50 users and $12,500 a month at 250. The CSP incentive is paid 60% as rebate and 40% as co-op. The 13% Partner Earned Credit rate is a planning figure; the rate that applies is the one in the Partner Center price list. Check every figure against the latest Microsoft Commercial Partner Incentives Guide. When Partner Earned Credit applies. All of the following must be true: You hold an active Microsoft AI Cloud Partner Program agreement and bill the customer's Azure plan through CSP. The Cowork consumption runs pay-as-you-go on that Azure plan. Reservations, savings plans, Spot virtual machines, and Marketplace or third-party products are excluded. You have admin access to the subscription through an eligible Azure role: the default admin on behalf of (AOBO) access, Azure Lighthouse, or user or service-principal accounts linked with Partner Admin Link. The role must sit at subscription, resource group or management group level, because root scope alone does not count. As an indirect reseller, your indirect provider grants you that role on the customer's subscription. The access stays in place. If the customer removes it, or the subscription moves to a new partner who does not set it up again, the credit stops. The credit is worked out daily and shows as a lower price on your invoice, not as a separate line. See Partner Earned Credit for managed services for the full rules. Those returns grow in two ways. First, the CSP incentive and Partner Earned Credit do not stop after Month 3. They continue every month the customer keeps using Cowork. Second, the activation payment is once per tenant, so the real scale comes from running the same twelve weeks across many tenants. To find them, filter the AI Business Solutions & Security Insights (ASPX) dashboard for customers you manage that have Copilot, Cowork usage below 50 users and a CSP relationship. Then line up a new cohort each month. The last window can start in June 2027, so every month you wait is one fewer cohort. How the Offer Fits Together: A Twelve-Week Run Plan The picture below puts one tenant's journey on a single page: the twelve weeks across the top and the returns underneath. Read it from left to right: Lead-in (four weeks before Month 1): eligibility, attribution, Partner Earned Credit and Default Spending policy are settled, and pilot users are rated by the assessment. Month 1 (weeks 1 to 4): two functions land each week, Executives with Sales, then Marketing with Customer Service, then Finance and Operations with Legal. Week 4 is the milestone: 50 users and $2,500 of consumption. Months 2 and 3 (weeks 5 to 12): champions, role-based training and new users run throughout. Proven scenarios become reusable skills in Month 2. Weekly monitoring keeps both numbers above the line until the final Month 3 check. Payout (about week 18): qualified users are calculated and the ~$2.5K activation payment arrives. The ~$0.98K CSP incentive and ~$0.98K Partner Earned Credit build up month by month along the way, bringing the window to about $4.5K per tenant before any managed services. Beyond the Payout: Services That Grow With Every New User The payout closes the activation, not the relationship. Keeping Cowork useful takes work every month, so group the services into three families: run adoption, support and FinOps as one subscription after Month 3, and add security and scale-out as the customer needs them. Service family What you run Cadence What the customer gets Cowork adoption and support Usage health monitoring: track active use by team and follow up on drop-offs 4 hours a month Drop-offs caught within the month. Each lapsed user means about $5.2K a year of time savings lost Cowork adoption and support Change management and enablement: champion network and role-based training 5 hours a month Each extra active user adds about $5.2K a year of time saved for about $600 of Cowork spend Cowork adoption and support Continual improvement: add new scenarios and build shared Cowork skills 1 day a month Time saved rises from 2 to 2.5 hours per user a week: about $65K more a year across 50 users Cowork adoption and support Service desk (first and second line): access issues, errors and how-to questions 8 hours a month Fixes by the next working day. Each stuck user loses about $100 a week of time savings AI FinOps and governance Copilot Credit optimisation: review credits by user, group and agent; tune the costliest tasks 1.5 hours a month 5 to 10% of waste removed: about $1.5K to $3K a year back on about $30K of Cowork spend AI FinOps and governance Spending policies: limits, alerts, credit requests, billing method and departmental chargeback 2 days to set up, then monthly tuning Monthly spend stays within 10% of the $2,500 plan, and invoices hold no surprises AI FinOps and governance Monthly business review with the sponsor: value against cost, next priorities 3 hours a month One scorecard: hours saved at $50 an hour against about $48K a year of Cowork and Copilot licences AI FinOps and governance Skill and automation lifecycle: test, update and retire shared skills and scheduled tasks 4 hours a month At $0.70 to $15 a run, each daily task nobody uses wastes about $250 to $5,500 a year until retired AI FinOps and governance Security and compliance monitoring: alerts on risky Cowork actions, oversharing and data loss events 24x7, as an add-on to an existing security operations service Risky actions triaged within an agreed time, for example one hour, at low extra cost Cowork scale-out Re-run the Investment Assessment for new teams or roles in the same tenant 1 week per group Spend goes only to Yes users: about $600 a year of Cowork each, returning about $5.2K of time saved Cowork scale-out Land and expand: discovery for new business units or tenants 2-week sprint Next three units sized. For example, 50 users save about $260K a year for about $48K of Cowork and Copilot Cowork scale-out Repeatable rollout: run the proven twelve weeks for each new unit or tenant About 3 months per rollout 50+ active users each time, reusing proven skills. New tenants can earn their own activation payment Total About 4.5 partner days a month / about 55 a year About $260K a year of time saved against about $103K of total cost: a return of about 2.5 times, rising towards 3 times at 100+ users The total row tells the story. Around $55K a year of service revenue from one tenant sits on top of the ~$4.5K earned in the activation window, and it repeats every year the customer keeps using Cowork. On the customer side, the $103K of total cost breaks down as $30K of Cowork, $18K of Copilot licences and $55K of services. As usage grows to 100 or more users in the year, Cowork spend rises to about $60K and the return climbs towards three times. Value figures are illustrative. They assume 2 hours saved per user a week at $50 an hour, Copilot at about $30 per user a month and a partner day rate of $1,000. Replace them with each customer's Investment Assessment results. Start Your First Tenant This Quarter Putting the playbook to work starts with one tenant. Six moves get you there: Check you qualify: confirm your Solutions Partner designation and revenue threshold, then enrol in the incentive and complete your Partner Center details. Find your tenants: in ASPX, filter for customers with Copilot, Cowork usage below 50 users and a CSP relationship. Confirm each one against the August 2026 baseline. Get the plumbing right first: attribution, the CSP Azure plan and the default spending policy all need to be in place before Month 1. A missed setup step cannot be fixed later in the window. Run the assessment in parallel: pilot users can take the Cowork Investment Assessment at any point. It never holds up the scenario rollout, and its results show where Cowork should grow next. Package it once: treat the twelve-week activation as an investment that pays back as users grow, then layer a monthly adoption, FinOps and scale-out service on top, sold through the routes your customers already buy from you. Put the Month 3 review in the diary on day one, together with the sponsor's first monthly business review. Cowork is where Copilot moves from answering questions to finishing work. Help every customer reach that point, one tenant at a time. Further Reading and Tools These resources cover the rules, the tools and the wider Copilot picture behind this playbook. Copilot Cowork CSP Activation Incentive Copilot Cowork Investment Assessment Copilot Credit Estimator Cowork Nifty-Sixty The new Copilot and the partner opportunityCopilot, Microsoft 365 & Power Platform Community call
💡 Copilot, Microsoft 365 & Power Platform weekly community call focuses on different use cases and features within the Microsoft 365 and Power Platform - across Microsoft 365 Copilot, Copilot Studio, SharePoint, Power Apps and more. Demos in this call are presented by the community members. 👏 Looking to catch up on the latest news and updates, including cool community demos, this call is for you! 📅 On 5th of November we'll have following agenda: Latest news and events from Microsoft Latest on Copilot prompt of the week CommunityDays.org update Microsoft 365 Maturity model PnP Framework and Core SDK extension PnP PowerShell Script samples Copilot pro dev samples Power Platform samples Demos this time Vijay Kumar Gilakattula – Content Rollup aggregate news across SharePoint sites with Microsoft Search Marc André Schröder-Zhou – Creating UX component solution to manage approvals directly in Copilot canvas Adam Wójcik - Announcing new and updated PnP Provisioning engine for M365 provisioning automation 📅 Download recurrent invite from https://aka.ms/community/m365-powerplat-dev-call-invite 📞 & 📺 Join the Microsoft Teams meeting live at https://aka.ms/community/m365-powerplat-dev-call-join 💡 Building something cool for Microsoft 365 or Power Platform (Copilot, SharePoint, Power Apps, etc)? We are always looking for presenters - Volunteer for a community call demo at https://aka.ms/community/request/demo 👋 See you in the call! 📖 Resources: Previous community call recordings and demos from the Microsoft Community Learning YouTube channel at https://aka.ms/community/youtube Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home 🧡 Sharing is caring!Copilot, Microsoft 365 & Power Platform product updates call
💡Copilot, Microsoft 365 & Power Platform product updates call concentrates on the different use cases and features within the Microsoft 365 and in Power Platform. Call includes topics like Microsoft 365 Copilot, Copilot Studio, Microsoft Teams, Power Platform, Microsoft Graph, Microsoft Viva, Microsoft Search, Microsoft Lists, SharePoint, Power Automate, Power Apps and more. 👏 Weekly Tuesday call is for all community members to see Microsoft PMs, engineering and Cloud Advocates showcasing the art of possible with Copilot, Microsoft 365 and Power Platform. 📅 On the 3rd of November we'll have following agenda: News and updates from Microsoft Together mode group photo Joe Komban - Copilot in SharePoint: New Skills Management Experience and Productivity Features Paolo Pialorsi - Building Copilot Cowork Skills and Plugins Vesa Juvonen - Copilot UX Components: From AI Chat to Interactive Business Applications – Sales Pipeline in Action 📞 & 📺 Join the Microsoft Teams meeting live at https://aka.ms/community/ms-speakers-call-join 🗓️ Download recurrent invite for this weekly call from https://aka.ms/community/ms-speakers-call-invite 👋 See you in the call! 💡 Building something cool for Copilot, Microsoft 365 or Power Platform (Copilot Studio, SharePoint, Power Apps, etc)? We are always looking for presenters - Volunteer for a community call demo at https://aka.ms/community/request/demo 📖 Resources: Previous community call recordings and demos from the Microsoft Community Learning YouTube channel at https://aka.ms/community/youtube Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home 🧡 Sharing is caring!Introducing the Logic Apps local CLI: develop Standard workflows from your terminal
We're introducing the public preview of the Logic Apps Standard extension for the Azure command-line interface (CLI). It brings local project creation, connector discovery, connection configuration, runtime management, and execution diagnostics into az logicapp . Why a CLI for Logic Apps Standard? The designer remains useful for understanding and editing workflows visually. The CLI gives you another interface to the development work around that workflow: checking dependencies, discovering operations, validating definitions, starting the local host, and inspecting runs without switching tools at every step. You can use those commands yourself, put them in a script, or let a coding agent invoke them with your approval. Existing Azure CLI app-management and app-settings commands remain a separate part of the same CLI surface. This extension adds Standard developer workflows; it doesn't replace the designer or reinterpret existing resource-management commands. Your coding agent needs more than workflow JSON A coding agent can propose a plausible connector action. Plausible isn't authoritative. The operation identifier, required inputs, and authentication parameters need to come from the connector catalog for your target, not from the agent's recollection of a similar example. That's where deterministic tools matter. The CLI gives the agent a defined operation to execute and evidence to inspect: discover the connector, read its operation schema, author the workflow, validate it, then examine execution results. It reduces guesswork and avoids making the agent reconstruct platform calls it doesn't have available by default. The CLI doesn't make the agent's decisions deterministic, and a successful command doesn't prove your business process is correct. You still review the workflow and its effects. But now that review is grounded on the same type of information the extension and runtime's have. Install the public preview The preview package is logicapp version 1.0.0b1 . It declares Azure CLI 2.67.0 or later and Python 3.10 or later for the interpreter hosting Azure CLI. Install it through the public Azure CLI extension mechanism: az extension add --name logicapp --allow-preview true az extension show --name logicapp --query version --output tsv az logicapp --help For later releases, use az extension update --name logicapp --allow-preview true . Local runtime dependencies are separate from extension installation. What can you do with the extension? The preview registers 59 extension-owned commands. Every group below follows az logicapp ; inherited core commands aren't included. Group Commands Purpose project create Scaffold a local Standard project. context create, use, list, show, update, delete Save target coordinates. workflow create, validate, list, show, export, set, delete, enable, disable Author, inspect, and manage workflows. dependency check, install, uninstall Manage supported local tools. runtime doctor, start, show, stop Diagnose and operate local hosts. connector , connector operation list, show in each Discover runtime connectors and operations. connector managed , connector managed operation list, show in each Discover regional managed APIs. connection create, list, show, test, delete Create local service-provider wiring; inspect and manage deployed connections. connection managed create Create, authorize, and wire a deployed managed connection. connection acl list, show, add, remove Manage connection access policies. identity assign, show, remove Manage deployed app identities. run start, list, show, wait, cancel, resubmit Invoke, observe, and control supported executions. run action list, show, show-content Inspect action results. trigger history resubmit Replay an exact retained trigger event. deployment package Build a deterministic ZIP. test create, plan, run Scaffold, plan, and execute tests, with limitations described below. test results show Inspect test results. Walkthrough: save email attachments to Blob Storage Use Office 365 Outlook as the managed connector and Azure Blob Storage as the in-process service-provider connector. The workflow runs on your workstation; the mailbox, managed connection, and storage account remain in Azure and Microsoft 365. Local doesn't mean offline. Use a test mailbox, a storage container, and an existing non-production Standard app with an assigned identity and valid connections.json . You need permissions for connection creation, consent, access policies, and storage data access. The PowerShell examples use placeholders: replace them before execution. Don't run them against production. 1. Create the project and check the environment From a new solution directory, keep the host under app and create a sibling artifacts folder for exports and packages. az logicapp project create --path .\app --workflow save-attachments --workflow-kind Stateful az logicapp context create --name attachments-local --path .\app --port 7071 --use az logicapp dependency check --path .\app az logicapp runtime doctor --path .\app --port 7071 Install only missing supported tools with dependency install --kind <kind> . The command doesn't install the .NET SDK. Read the doctor's findings: exit code 2 can mean compatibility is unknown, not that everything needs reinstalling. Contexts save coordinates, not your Azure subscription or credentials. 2. Discover both connector catalogs Use az login and check az account show before querying the Azure catalog. These are standard Azure CLI commands. az logicapp runtime start --path .\app --port 7071 --background --ready-timeout 90 az logicapp runtime show --port 7071 az logicapp connector list --local --port 7071 az logicapp connector show --local --port 7071 --connector "<blob-connector-id>" az logicapp connector operation list --local --port 7071 --connector "<blob-connector-id>" --search "upload" az logicapp connector managed show --location "<region>" --connector office365 az logicapp connector managed operation list --location "<region>" --connector office365 --kind trigger az logicapp connector managed operation show --location "<region>" --connector office365 --operation OnNewEmailV3 az logicapp connector operation show --local --port 7071 --connector "<blob-connector-id>" --operation uploadBlob Take the Blob connector identifier from connector list . Runtime catalogs describe the service provider; the regional managed catalog describes Outlook. They aren't interchangeable. Use each family's operation show command to inspect the selected operation before authoring it. This is a useful agent task: "Read both connector schemas. Identify an email trigger, attachment retrieval, and Blob upload. Show me the required inputs and authentication before changing the workflow." The Outlook reference documents attachment retrieval through GetAttachment_V2 ; the Blob service-provider reference documents uploadBlob . 3. Create Outlook access, then wire the local project Stop the discovery host with az logicapp runtime stop --port 7071 before changing settings. Then create the managed connection: az logicapp connection managed create --resource-group "<group>" --logic-app-name "<nonproduction-app>" --name outlook-local --connector office365 --location "<region>" --auth-mode oauth az ad signed-in-user show --query id --output tsv az logicapp connection acl add --resource-group "<group>" --connection outlook-local --object-id "<developer-object-id>" --tenant-id "<tenant-id>" Approve mailbox consent in the browser. Creation also adds the app's access policy and changes the deployed app's connection wiring. The additional policy authorizes your local developer principal. These are real Azure changes, even though the example workflow stays local. Failed creation can retain resources; inspect them and the wiring before retrying. The CLI doesn't write local managed-connector wiring. Read the created entry with connection show against that app and deliberately use --show-runtime-urls for this setup step. Manually merge its API identifier, connection identifier, runtime endpoint, and ManagedServiceIdentity authentication into the local managedApiConnections.outlook-local entry. Keep the runtime endpoint in a private app setting, referenced with @appsetting('OUTLOOK_RUNTIME_URL') ; don't paste returned URLs into the post or shared logs. The documented local identity feature requires the Standard VS Code extension 5.961.19 or later and workflow bundle 1.165.52 or later. Merge this value into both the project's local.settings.json and its workflow-designtime\local.settings.json , preserving existing settings: "WORKFLOWS_AUTHENTICATION_METHOD": "managedServiceIdentity" After completing the connection configuration, start the local runtime as shown in step 5 so it loads the updated settings. Make sure the local runtime authenticates as the developer identity you granted access to the managed connection. 4. Configure Blob access without an account key Read the service provider's managed-identity parameter set and endpoint parameter from discovery. Don't reuse the managed Blob connector's parameter-set name. Substitute those discovered values in this local wiring command: az logicapp connection create --path .\app --name blob-local --connector "<blob-connector-id>" --parameter-set "<discovered-identity-set>" --% --parameter "<endpoint-parameter>=@appsetting('BLOB_ENDPOINT')" authProvider.Type=ManagedServiceIdentity --app-setting BLOB_ENDPOINT=https://<storage-account>.blob.core.windows.net Keep this PowerShell command on one line. The --% marker preserves the app-setting expression through az.cmd ; variables don't expand after it. Review the discovered identity fields before using the command. Grant the local developer Storage Blob Data Contributor at the intended container scope, using your approved Azure role-assignment process. In Azure, grant the app's managed identity its own required access. A workstation doesn't impersonate that identity, and assigning an identity to an app doesn't grant storage permissions. 5. Author and validate the workflow Replace the scaffold's starter definition with Outlook's polling When a new email arrives (V3) trigger, OnNewEmailV3 , an attachment loop, GetAttachment_V2 , and the Blob upload action. Configure the trigger's recurrence and message splitting from its schema. Bind Outlook operations to outlook-local and Blob operations to blob-local . Set includeAttachments to false and retrieve attachments separately. Map each message and attachment identifier explicitly. For uploadBlob , supply containerName , blobName , and content . Decode Outlook's base64 contentBytes before writing binary content; use a unique blob name so repeated filenames don't overwrite unrelated attachments. These are workflow-authoring decisions, not generated business logic from the CLI. For an attachment action named Get_attachment , the upload content expression is @base64ToBinary(body('Get_attachment')?['contentBytes']) . Match action names to your authored definition. Validate offline, restart with the new settings, then validate against that host: az logicapp workflow validate --path .\app --workflow save-attachments az logicapp runtime start --path .\app --port 7071 --background --ready-timeout 90 az logicapp runtime show --port 7071 az logicapp workflow validate --path .\app --all --with-runtime --local --port 7071 Check that the host is running, readiness.managementEndpointReachable is true, and the workflow is registered. Validation doesn't establish connector authorization or business correctness. Static reference warnings can remain after runtime validation and block --fail-on-warning ; don't remove configuration references to manufacture a pass. 6. Send a test email and inspect the run Send a synthetic email with one harmless attachment. Identify the matching execution by timing and message correlation, not by assuming the newest run is yours. az logicapp run list --local --port 7071 --workflow save-attachments --max-items 10 --query "value[].{runId:runId,status:status,startTime:startTime}" --output table az logicapp run wait --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" --timeout 300 az logicapp run action list --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" az logicapp run action show-content --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" --action "<actual-action-name>" --max-bytes 16384 For Stateful runs, run wait exits 0 only after observing success. Its timeout doesn't cancel execution. If outputs are absent, use run action show for failure metadata. Bounded content can still contain private data. Verify the saved blob's bytes independently; a green status isn't an attachment-integrity check. 7. Stop and package az logicapp runtime stop --port 7071 az logicapp deployment package --path .\app --output-path .\artifacts\attachments.zip Verify shutdown, including unshared CLI-owned Azurite processes. Review the package manifest and ZIP: exclude local settings, design-time files, editor content, reports, and private fixtures through .funcignore . Don't confuse it with .gitignore . Packaging is deterministic archive creation, not validation, deployment, or a guarantee that no secrets exist. Add the Logic Apps skill to GitHub Copilot The azure-logic-apps-standard-cli skill is now available on Awesome Copilot. It gives Copilot procedures for using the CLI: inspect the project first, discover connector schemas, preserve existing layouts, prefer managed identity for new connections, and distinguish validation from actual execution. It covers Logic Apps Standard, not Consumption-only development. Install the complete skill package With GitHub CLI 2.90.0 or later, preview the skill and review its bundled references before installing. The following commands install it for your personal Copilot use across projects: gh skill preview github/awesome-copilot azure-logic-apps-standard-cli gh skill install github/awesome-copilot azure-logic-apps-standard-cli --agent github-copilot --scope user For a repository-specific installation, run the install command from that repository with --scope project instead. The installer places the package in the appropriate skills directory. Alternatively, download the complete skill folder and place it under .github\skills in your repository or .copilot\skills in your home directory. Keep SKILL.md , README.md , and all five references files together; copying only SKILL.md leaves required procedures unavailable. The skill is guidance, not the Azure CLI extension or a runtime installer. Install the extension separately as described above; runtime and test dependencies still need their own checks and approval. Use it in Copilot CLI Start copilot from your project directory. If a session is already open, reload skills, then check that the package is available: /skills reload /skills info azure-logic-apps-standard-cli Copilot can select relevant skills automatically. To request this one explicitly, name it in your prompt: Use the /azure-logic-apps-standard-cli skill to inspect this existing Standard project and validate its workflows offline. Preserve its layout, workflow kinds, and authentication. Do not start a host, install dependencies, or access Azure. Report any checks you cannot complete. To approach the attachment walkthrough with Copilot, begin with a plan rather than authorizing every operation at once: Use the /azure-logic-apps-standard-cli skill to plan an Outlook-to-Blob workflow for this project. Identify the connector discovery steps, authentication requirements, and permissions needed. Separate offline work from host startup and Azure changes, and wait for approval before those operations. Review proposed commands and their effects before approving them. The skill requires operation-specific bundled procedures and explicit authorization for cloud changes, replay, and native-test prerequisites; it doesn't replace Copilot's permission controls or prove that a workflow works. See GitHub's Copilot CLI skills guide for installation and usage details. Beyond this walkthrough Use workflow list/show/export against a running host to inspect or save a definition. Against Azure, connection list/show/test , connection acl list , and identity show expose wiring and access. A connection with no available test remains unverified. For compatible callable triggers, run start invokes a workflow; it doesn't manufacture an incoming Outlook email. Cancellation and replay are explicit operations with external effects. Guarded workflow replacement and state changes also need deliberate approval; they aren't transactional shortcuts. Before you build: preview realities and what comes next Commands and outputs can change during preview. Testing commands already provide scaffolding, planning, approved SDK execution, and result inspection, but the current SDK/engine combination has a reported typed-output limitation. They aren't part of this walkthrough. Proposed improvements include testing, local connection inspection, trigger/history discovery, and managed-connection deployment export. These are areas of work, not delivery commitments or commands you can use today. Try it with a workflow you know Take a non-production workflow and ask your coding agent to discover its connectors before editing it. Compare the proposal with the catalog, then inspect the actual execution. If a command is missing or the results don't help you diagnose a failure, tell us which step broke and what you needed instead. Giving us feedback early will help us getting the features ready to you faster!
Amplify Healthcare Intelligence: Data, AI, and Agent-Powered Transformation
Join Microsoft for Amplify Healthcare Intelligence, a webinar and in-person workshop series designed for healthcare and life sciences organizations building the foundation for trusted AI. Every session starts from the same premise: you cannot deliver trusted AI without a trusted data foundation. Across the series you will see how leading organizations unify their data estate, ground AI agents in real business context, and turn that foundation into results they can measure. What You Will Learn How to build a unified, AI-ready data foundation across a fragmented healthcare data estate How to ground AI agents in trusted healthcare data and real business context How to modernize analytics while reducing complexity and cost How to accelerate innovation with Microsoft Fabric, Azure AI Foundry, Microsoft IQ, and Copilot technologies How to deliver measurable impact across clinical, operational, research, and business scenarios Whether you are defining your AI strategy, modernizing your analytics platform, or scaling AI across your organization, these sessions offer practical guidance, real-world customer examples, and hands-on learning to help you move from AI ambition to business impact. Webinars & In-Person Workshops 🎥 Webinars One-hour virtual sessions with actionable guidance, live demonstrations, customer stories, and best practices from Microsoft experts. Each webinar shows how leading healthcare organizations are turning data, AI, and enterprise intelligence into measurable business outcomes. All sessions are from 3-4 ET (12-1 PT) and are free to attend. Date Topic Register Oct 28 3-4 ET (12-1 PT) Reduce BI Sprawl, Cut Cost and Build an AI-Ready Analytics Foundation Register Nov 11 3-4 ET (12-1 PT) Connecting Microsoft Fabric with ExpressRoute: Enterprise Network Architecture Register Nov 18 3-4 ET (12-1 PT) From Question to Visuals: Data Insights with Fabric, Rayfin & GitHub Copilot Register Dec 2 3-4 ET (12-1 PT) The Intelligent Healthcare Enterprise: Microsoft IQ in Action Register Dec 9 3-4 ET (12-1 PT) From Trusted Data to Action: Microsoft Fabric + Copilot Cowork for Healthcare & Life Sciences Register Cannot join live? Register anyway. We will send you the recording and session materials after the event. Additional sessions will be added through the end of the year, so check back or register for one session to be notified as new dates are announced. 🏢 In-Person Workshops Our two-day workshops combine executive strategy, healthcare-specific use cases, architecture guidance, and hands-on labs designed to help teams identify and accelerate high-value AI opportunities. Attendance is free. Participants are responsible for their own travel and accommodation, and space at each location is limited. Workshops run 9am to 4pm local time on both days. Day 1: From Healthcare Data to Healthcare Intelligence Day 1 focuses on healthcare transformation strategy, customer examples, and the architectural patterns that make trusted AI possible at scale. The day closes with a networking reception and peer exchange. The Frontier Transformation imperative: from AI ambition to measurable impact Microsoft IQ: turning data into enterprise intelligence Building the unified data foundation Building trusted AI: security, governance, privacy, and compliance Healthcare transformation in action: clinical, operational, research, and finance scenarios Activating data with AI data agents and Copilot experiences Day 2: Hands-On Healthcare AI and Analytics Lab Day 2 is a guided, end-to-end lab. Participants build a working healthcare intelligence solution from raw data through to a grounded AI agent, using Microsoft Fabric, Azure AI Foundry, Copilot technologies, and modern data architectures. Build the foundation: data ingestion, lakehouse architecture, and data engineering Create actionable insights: semantic models and dashboards Prepare data for AI: AI-ready data assets and data governance Build and ground AI agents in trusted enterprise data From insight to intelligent action: planning your organization's next steps What to bring: a laptop with a current browser. Lab environments and credentials are provided on site, and no prior Fabric or Foundry experience is assumed. Date City Venue Register November 10-11, 2026 9am - 4pm Chicago Microsoft Chicago (AON Center) 200 East Randolph Drive, Suite 200 Chicago, IL 60601 Register December 8-9, 2026 9am - 4pm New York Microsoft Garage 300 Lafayette Street New York, NY 10012 Register Who Should Attend This series is built for the people who own the data estate and the people who depend on it. Sessions are technical enough for practitioners and strategic enough for the leaders who prioritize the work. Data & analytics leaders Data platform, data engineering, and business intelligence teams Data architects, engineers, and data scientists AI and innovation leaders Healthcare and life sciences executives Clinical, operational, research, and finance transformation leaders No prior Microsoft Fabric or AI experience is required for any session in this series. Questions Contact Camille Whicker if you have any questions about our upcoming events.Turn GitHub notifications into code with GitHub Copilot in Microsoft Teams
GitHub can now bring repository updates into a channel, group chat, or private chat. When an update needs action, reply to the notification and @mention GitHub with the task you want GitHub Copilot to carry out. GitHub Copilot uses the issue or pull request linked in the notification and the conversation in the thread to understand the task. It can reproduce a bug, run tests, implement a fix, and prepare a pull request for review. Turn an issue notification into a pull request If the player doesn’t load, open the video in a new window: Open video For a bug report, the workflow starts in the notification thread: A GitHub Issue notification arrives in a Teams channel with a link to the reported bug. You @mention GitHub to investigate the issue and prepare a proposed fix in a pull request. The team reviews the pull request, iterates with GitHub Copilot, tests the proposed changes, and decides whether to merge. Starting from the linked issue and thread lets your team delegate the work to GitHub Copilot without rebuilding the request from scratch. The same workflow can be used to implement a feature, expand test coverage, update documentation, and more. Product and engineering teams at Microsoft are already leveraging the GitHub app in Teams to build products today. Get started Explore the new GitHub app in Microsoft Teams (previously called GitHub Notifications). If you already have GitHub Notifications installed, update the app to the latest version. The legacy GitHub app will be renamed “GitHub (deprecated)” and retired on November 16. Learn more at teams.github.com! Turn the updates your team follows into code your team can review.The Context Advantage
A strange thing happens when enterprises upgrade their AI models. The model gets smarter. The benchmarks improve. The demos become more impressive. And sometimes, the business outcome barely moves. The agent still asks questions the organization answered months ago. It recommends something policy doesn't allow. It treats a strategic customer like any other customer. It proposes an architecture your engineering team rejected six months ago. The problem isn't necessarily intelligence. It is ignorance of the business. That distinction matters because the world's most capable models are becoming available to almost everyone. Your competitors can increasingly access the same frontier intelligence you can. What they cannot access is your customer history, operating knowledge, organizational memory or understanding of how decisions actually get made. Models are becoming shared. Context remains proprietary. And that may be where the next enterprise AI advantage is built. Intelligence Without Context is Surprisingly Ordinary Consider a simple enterprise question: Can we offer this customer a larger discount? A powerful model can reason about discounts. But answering that question properly may require the customer's lifetime value, current contract, payment history, margins and approval thresholds and perhaps a conversation yesterday in which the account executive learned that a competitor had entered the deal. The model isn't missing intelligence. It is missing context. Humans rarely make important decisions from one piece of information. We combine data, experience, relationships, history and situational awareness almost unconsciously. Agents need a version of the same capability. That is why enterprise AI is moving from an era dominated by prompt engineering toward one increasingly shaped by context engineering. Satya Nadella recently described the emerging market simply as “a world of context engineering.” Prompt engineering asks: What should I tell the model? Context engineering asks the larger question: What does the model need to understand before it can act well? That difference becomes critical as AI moves from answering questions to performing work. The Enterprise Context Stack In discussions about enterprise agents, “context” can easily become shorthand for giving a model access to more data. That definition is too narrow. I think about enterprise context as a stack: DATA → SEMANTICS → KNOWLEDGE → WORK → MEMORY → JUDGMENT Data tells the agent what happened: orders, transactions, inventory, claims and customer records. Semantics tells it what that data means to the business: what constitutes a strategic customer, how margin is calculated, which assets belong to which production line. Knowledge tells it what the organization knows: policies, contracts, procedures, research and accumulated expertise. Work tells it what is happening now: who is involved, what has been discussed and which commitments already exist. Memory tells it what happened before: previous interactions, decisions, exceptions and outcomes. And judgment helps determine what should happen next. Memory deserves particular attention because it is context agents can accumulate through experience. Microsoft Foundry now distinguishes between session, user and procedural memory - moving agents beyond remembering a conversation toward remembering preferences and learning how work gets done across repeated interactions. Sometimes the cheapest way to make an agent meaningfully better may not be a bigger model. It may be a better memory. Not every agent needs every layer. But the more consequential its responsibility, the richer, and more carefully governed, its context usually needs to become. This is where context stops being a retrieval problem and starts becoming an enterprise architecture problem. Context Is Becoming Infrastructure This shift is now visible well beyond any one technology platform. Gartner increasingly describes a context layer as an architectural foundation for agentic AI - bringing together semantics, operational state, provenance and other enterprise signals so agents can act reliably. Anthropic, approaching the problem from AI engineering, argues that context should be treated as a finite resource that must be carefully curated rather than simply expanded. Microsoft's recent direction is particularly interesting through this lens. Work IQ, Fabric IQ, Foundry IQ and Web IQ increasingly form a shared intelligence layer across Microsoft's stack. Work IQ provides context about how work happens. Fabric IQ brings business semantics and relationships. Foundry IQ provides reusable enterprise knowledge and agentic retrieval. Web IQ extends that understanding with fresh external intelligence. The architectural implication matters more than the product names. Instead of every new agent rebuilding connectors, retrieval logic, semantic definitions and permissions, context becomes reusable infrastructure from which many agents can reason. Microsoft captured the shift particularly well: As agents become the new application model, context becomes critical infrastructure. Your Data Estate Is Not Automatically Your AI Moat For years, organizations have been told their data is a competitive advantage. Sometimes it is. But possessing data and making that data useful to an agent are very different things. Most enterprises don't suffer from a shortage of information. They suffer from an abundance of it -scattered across databases, documents, emails, meetings, applications and people's heads. The advantage doesn't come from connecting an agent to all of it. It comes from turning information into usable context: preserving business meaning, understanding relationships, distinguishing authoritative knowledge from convenient information, respecting permissions and retrieving what matters when a decision is being made. The enterprise with the most data may not build the best AI. The enterprise that makes its context most usable might. The Context Budget There is a trap on the other side too. If context improves AI, the natural instinct is to give the agent as much as possible. That is the wrong objective. Context consumes attention and compute. Irrelevant information creates noise. Stale information can mislead. Conflicting context can degrade reasoning rather than improve it. The objective should therefore not be maximum context. It should be minimum sufficient context the smallest trusted, relevant and permission-aware set of information required to produce the right outcome. In Beyond Tokens, I introduced the idea of an Intelligence Budget: How much intelligence does this outcome deserve? Enterprise agents increasingly need a companion concept. The Context Budget. How much context does this decision deserve? A scheduling agent may need calendars and preferences. A pricing agent may need customer economics, margins, commitments and approval policies. A clinical agent requires an entirely different level of completeness, provenance and governance. Every unnecessary token of context is cost. Every missing piece of necessary context is risk. Which gives us a useful way to think about enterprise agents: Right Intelligence × Right Context → Right Outcome Spend more intelligence where the outcome warrants it. Provide more context where the decision requires it. Do neither indiscriminately. What An Agent May Know Matters Too! There is another dimension to the Context Budget: permissions. Enterprise context belongs to someone. A system that retrieves the right answer but ignores whether the agent is entitled to see it isn't intelligent. It is a security problem. Enterprise context must therefore remain identity-aware and permission-aware as it moves from source systems into agent reasoning. This becomes especially important as agents gain persistent identities and greater autonomy. What an agent may know is as much a part of its job description as what it may do. Autonomy defines the boundary of action. Context defines the boundary of understanding. From RAG Projects To Context Architecture The first generation of enterprise GenAI often started with RAG: connect documents to a model and retrieve relevant passages. That was an important step. But an agentic enterprise cannot become a collection of hundreds of independent RAG pipelines, each separately rediscovering the organization's customers, products, policies, terminology and permissions. That risks creating another generation of technology fragmentation. The opportunity is to move from agent-specific retrieval toward reusable enterprise context. What knowledge should agents inherit? Which business entities should have common definitions? Which sources are authoritative? Which memories should persist—and which should be forgotten? And perhaps the hardest question: Who owns enterprise context? Today, responsibility is scattered across data teams, application teams, knowledge management, security, business functions and increasingly AI teams. In an agentic enterprise, context may need to be managed as a product, not everyone's side project. The Moat Is Not The Model Imagine two competing organizations using exactly the same frontier model. One connects it to fragmented documents and a handful of applications. The other has strong data foundations, shared business semantics, governed knowledge, connected workflows and organizational memory. They have access to the same AI. They do not have the same intelligence system. The second organization's agents understand customers more deeply, interpret signals more accurately and act with greater awareness of how the organization actually works. And that advantage compounds. Every workflow creates more context. Every interaction adds organizational memory. Every decision creates another signal from which future agents can reason. Models depreciate the moment a better one ships. Context appreciates every day you operate. That may be the most important strategic shift of all. Anyone can rent intelligence. No one can rent your context. Intelligence Is Becoming Abundant. Understanding Isn't. The first wave of enterprise AI taught us how powerful models could be. The next may teach us that models were only one part of the equation. An agent needs intelligence to reason. But it needs context to understand your business. As frontier intelligence becomes more accessible, enterprises may discover that their most defensible AI asset was never the model. It was everything the organization had learned before the model arrived: its data, semantics, knowledge, relationships, history, workflows and judgment. The organizations that turn those assets into trusted, reusable context will give every agent they build an advantage from day one. So perhaps the strategic question is no longer simply: Which model should we use? It is: What does our organization know that our competitors don't and can our AI actually use it? Because in a world where everyone can access intelligence, context may be what makes that intelligence uniquely yours. References Microsoft — FY2026 Q2 Earnings Conference Call Microsoft — FY2026 Q4 Earnings Conference Call Microsoft Learn — What is Foundry IQ? Microsoft Foundry — Foundry IQ: Build Smarter Agents Faster with Unified Knowledge and Serverless Retrieval Microsoft Foundry — What's New in Microsoft Foundry | Build 2026 Gartner — Context Engineering Is the New Prompt Engineering Gartner — Market Overview for AI Context Platforms Gartner — The 3 Core Components of the Context Layer for AI Agents
