Zoom in or out of forms, tables, and queries when in Form View or Datasheet View
Access now lets you zoom in and out when you’re working with forms, tables, and queries in Form View or Datasheet View. Zoom in for a closer look at your data or zoom out to see more on screen at once. You can adjust the zoom level using the Zoom button on the ribbon, the zoom slider on the status bar, or keyboard shortcuts. Zoom is also available in Print Preview for reports. Zoom isn’t supported in Report View or Design View. This feature is available in Access for Microsoft 365, version 2605 and later. Choose a magnification setting from the ribbon On the Home tab, select Zoom and choose one of the following options: 50%, 75%, 125%, 150%, 175%, 200%, or 500%. To return the view to 100% zoom, click Zoom 100%. If you prefer to use the keyboard, you can press Ctrl + Alt + 0 (zero). Use the zoom slider to quickly zoom in or out On the status bar in the lower right-hand corner of Access, select the zoom slider. Slide to the percentage zoom setting that you want. Press – or + to zoom in gradual increments. Use zoom keyboard shortcuts or mousewheel To zoom in, press Ctrl + Alt + Plus (+). To zoom out, press Ctrl + Alt + Minus (-). To return to 100% magnification, press Ctrl + Alt + 0 (zero). To use the mousewheel and scroll to zoom in or out, press Ctrl + mousewheel. Change your default zoom percentage Access doesn't save zoom settings on closing and reopening a form. Instead, it opens your form using the default zoom setting. To set your zoom default percentage, choose File > Options > Current Database > Application Options and choose the Default Zoom setting. Note Content inside of ActiveX controls, such as the text in a TreeView control, doesn't resize when zoomed. Zooming in Access only affects Access-native controls. If a form uses ActiveX controls, consider replacing them with native Access controls so they scale with the rest of the form.
Excel can't open file from hyperlink after upgrade windows11
Hello, I met a strang issue. After upgrade system from w10 to w11, my excel can't open linkage file which was working normal before. Tested file and folder which located on local and SMB was not working, after click the hyper-lnik nothing happen and no pop-up just turn to mouse to loading icon then nothing happen how can I check which part cause this issue? Also tested on word have same issue. Further, url was working normal.Building a Controllable Inference Platform on Kubernetes with AI Runway
When enterprises move generative AI from demos to real business workloads, the hardest question is usually not whether a model can answer a prompt. The harder question is whether the whole system can run reliably, predictably, securely, and economically over time. This becomes especially important as major model providers continue to adjust token pricing, context-window pricing, batching discounts, and model tiering. That is where AI Runway becomes valuable. It turns model deployment into a Kubernetes-native platform capability. Instead of binding every application to a specific inference runtime, AI Runway lets teams describe model-serving intent through a unified ModelDeployment resource, while the platform selects or delegates to the right provider and engine underneath. For teams already using Kubernetes, AKS, or cloud-native platform engineering practices, AI Runway offers a practical path from “calling an external model API” to “operating an enterprise inference platform.” Why do we need a self-hosted inference platform? Many teams have already proven the value of LLMs in knowledge assistants, code generation, content creation, customer support, document processing, and agentic workflows. But once usage grows, several platform-level issues appear quickly. 1. Token cost becomes an engineering problem In a proof of concept, token usage often looks like a small budget line. In production, it becomes an architectural concern. A single RAG request may include system prompts, user input, retrieved context, tool outputs, and the final answer. An agentic workflow may call models many times for planning, routing, summarization, validation, and generation. An internal Copilot used by hundreds of employees can generate token consumption at a scale that surprises the original project team. External model API cost is also affected by model versions, input/output token ratios, context length, caching policies, batch processing, and provider pricing strategy. When model vendors change pricing, enterprises without an alternative path become price takers. Self-hosted inference does not mean replacing every external model. It means creating a controllable platform layer for high-frequency, predictable, localized, or privacy-sensitive workloads. Scenario Why self-hosted inference helps High-frequency internal Q&A Large request volume can be served by smaller or quantized models Document summarization and extraction Stable task pattern, suitable for specialized local models Agent intermediate steps Planning, classification, and rewriting may not require the strongest closed model Edge or private-network workloads Data may need to stay inside a controlled boundary Cost-sensitive applications CPU/GPU resource pools, batching, and model tiering can reduce unit cost 2. Data boundaries and compliance become clearer Many enterprises are willing to use cloud-hosted models, but they also need clear controls for data classification, access boundaries, logging, and auditing. A self-hosted inference platform allows sensitive documents, internal knowledge bases, customer interactions, and business context to remain inside a governed network and operational model. 3. Teams should not be locked into one engine Inference engines are evolving quickly. vLLM, SGLang, TensorRT-LLM, and llama.cpp serve different needs. Some are optimized for high-throughput GPU serving. Some are better for structured serving or NVIDIA GPU acceleration. Others make GGUF quantized models practical on CPU or lightweight GPU environments. A platform should not force every team into one runtime. It should provide a unified entry point and absorb runtime differences underneath. 4. Production AI requires model operations, not just endpoints Production workloads need deployment lifecycle management, status, logs, metrics, scaling, debugging, progressive rollout, resource quotas, and secure ingress. A self-hosted inference platform should prevent every team from handcrafting runtime-specific YAML and instead provide these capabilities as shared platform primitives. What is AI Runway? AI Runway is a Kubernetes-native platform for deploying and managing large language models. Its core idea is to describe model deployment intent through a unified Kubernetes CRD called ModelDeployment. The AI Runway Controller then selects or delegates to provider-specific controllers based on provider capabilities. The project describes itself as: Deploy and manage large language models on Kubernetes — no YAML required. AI Runway supports a Web UI, REST API, Headlamp Plugin, and direct CRD management with kubectl. The UI is optional and replaceable; the core platform capability lives in the controller, CRDs, and provider abstraction. Key capabilities Capability Value Unified ModelDeployment CRD One API for model, engine, resources, scaling, and gateway configuration Multiple providers Supports KAITO, NVIDIA Dynamo, KubeRay, llm-d, and provider shims Multiple engines Supports vLLM, SGLang, TensorRT-LLM, and llama.cpp Automatic provider and engine selection Matches CPU/GPU requirements, serving mode, and provider capability Web UI and Headlamp Plugin Simplifies model discovery, deployment, and monitoring Hugging Face integration Enables model catalog browsing and deployment Observability Surfaces deployment status, logs, and Prometheus metrics Gateway API integration Enables unified OpenAI-compatible routing through a gateway Cost and capacity guidance Helps with GPU fit, pricing, and capacity decisions Multi-engine support is the key differentiator AI Runway is not just another model deployment tool. Its most important value is decoupling application developers from inference runtime decisions. Applications can call an OpenAI-compatible endpoint or a unified gateway, while the platform decides which engine and provider should serve a particular model. Engine Typical use case Resource target vLLM High-throughput general LLM serving GPU SGLang Complex inference workflows and structured serving GPU TensorRT-LLM Highly optimized inference on NVIDIA GPUs GPU llama.cpp GGUF quantized models and lightweight inference CPU / GPU For teams, this is an important story: instead of forcing every team into the same runtime, AI Runway creates a common platform where different workloads can choose different engines while keeping the developer experience consistent. AI Runway architecture overview The following Mermaid diagram shows a simplified view of the AI Runway platform layers. Three design points matter most: Unified control plane: users submit ModelDeployment resources instead of handcrafting YAML for each runtime. Out-of-tree providers: KAITO, Dynamo, KubeRay, and llm-d declare their capabilities through provider shims and controllers. Replaceable runtime layer: the same platform can serve CPU-based llama.cpp models and GPU-based vLLM or TensorRT-LLM workloads. Solution 1: Local Kubernetes with AI Runway, KAITO, and CPU Local Kubernetes is ideal for learning, demos, development validation, and small-model prototyping. The goal is not maximum throughput. The goal is to prove that AI Runway + KAITO + llama.cpp can expose an OpenAI-compatible model service without requiring a GPU. When to use this pattern Scenario Description Local developer experiments Use kind, minikube, k3d, or Docker Desktop Kubernetes Platform demos Show the ModelDeployment, provider, and OpenAI-compatible API flow CPU-only validation No GPU or cloud resource required SLM / GGUF testing Use llama.cpp to serve quantized models For local CPU inference, allocate at least 4 vCPU and 12 GiB memory. Even small models need memory for runtime startup, model loading, KV cache, and context windows. Local architecture The local KAITO + CPU pattern is powerful for education and adoption: Developers learn the ModelDeployment abstraction without needing a GPU. The application does not need to know whether the backend is LocalAI, llama.cpp, or KAITO Workspace. CPU-only environments can still run lightweight and quantized models. Teams can validate models, prompts, and API behavior locally before moving to AKS or production clusters. Sample Guideline - https://gist.github.com/kinfey/28b2338845cc63139aee2ea462a3c466 Solution 2: Azure with AKS, AI Runway, KAITO, and CPU After local validation, the next step is usually a cloud-hosted inference platform. AKS provides managed Kubernetes control plane, node pools, networking, identity, monitoring, and Azure ecosystem integration. It is a natural foundation for AI Runway in production or pre-production environments. The example below uses CPU-only AKS + KAITO + Qwen3-0.6B GGUF to build a cloud-hosted inference service without GPU nodes. Azure architecture Production recommendations for AKS Area Recommendation Secure ingress Do not expose plain HTTP 80 directly; add TLS, API keys, OAuth2 Proxy, WAF, or internal LoadBalancer Model governance Pin model versions, image versions, and GGUF filenames Cost governance Use CPU for lightweight tasks and GPU for high-throughput large models Observability Integrate Azure Monitor, Prometheus, logs, and request-level metrics Quota planning Check regional vCPU/GPU quota before deployment Caching Use PVCs or model cache volumes to reduce repeated downloads GitOps Manage ModelDeployment, providers, and ingress through GitOps Access control Use namespaces, RBAC, and NetworkPolicy for team isolation Sample Guideline - https://gist.github.com/kinfey/d439a545d8c93e15d8a2854b65f03d4d How to evangelize AI Runway inside an engineering organization When introducing AI Runway, I would avoid starting with “we are building our own model platform.” A more effective narrative is: Start with cost predictability: high-frequency workloads should not all depend on the most expensive external model tier. Emphasize technical optionality: teams can use different models and engines while keeping a unified platform entry point. Highlight Kubernetes-native operations: existing AKS, RBAC, monitoring, GitOps, networking, and security practices can be reused. Use CPU demos to lower the barrier: local KAITO + CPU lets developers understand the full flow without GPUs. Use Azure as the production landing zone: AKS carries the same abstraction into cloud environments and can evolve toward GPU, gateway, monitoring, and multi-tenant governance. This path avoids starting with GPU procurement, complex scheduling, or full-scale platform governance. Start small, prove the abstraction, then add higher-performance engines and stronger governance as the platform matures. Closing thoughts As AI applications enter production, enterprises need more than a model that can answer prompts. They need an inference platform that is controllable, observable, scalable, and evolvable. AI Runway brings this problem back into the Kubernetes platform engineering world: use ModelDeployment to standardize model deployment, use providers to hide runtime differences, and use multiple engines to match different cost and performance goals. From a local Kubernetes KAITO + CPU demo to a Qwen3-0.6B CPU inference service on AKS, AI Runway provides a clear adoption path: start with a low-barrier setup, then evolve toward multi-model, multi-engine, multi-provider, unified-gateway, enterprise-governed inference. In a world where token pricing changes frequently and model ecosystems evolve rapidly, a self-hosted inference platform is not about rejecting external models. It is about giving engineering teams more control over cost, architecture, and technical choice. References AI Runway GitHub: https://github.com/kaito-project/airunway AI Runway Architecture: https://github.com/kaito-project/airunway/blob/main/docs/architecture.md AI Runway Providers: https://github.com/kaito-project/airunway/blob/main/docs/providers.md AI Runway CRD Reference: https://github.com/kaito-project/airunway/blob/main/docs/crd-reference.md KAITO: https://github.com/kaito-project/kaito LocalAI: https://localai.io AKS Application Routing: https://learn.microsoft.com/azure/aks/app-routing Qwen3-0.6B GGUF: https://huggingface.co/Qwen/Qwen3-0.6B-GGUF
404 error downloading file versions via CSOM (SharePoint 2013 On-Prem)
I need to download historical versions of a document from a SharePoint 2013 On Premises document library using a C# console application, so I can migrate them chronologically to SharePoint Online along with their column properties. While downloading the current latest version works perfectly, downloading older historical versions always fails. Standard CSOM methods fail because ListItem.Versions does not exist in the SharePoint 2013 v15 SDK. Reverting to direct HTTP endpoints consistently throws an error. Here is the exact exception message I receive: System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found). Below is the minimal reproducible code example demonstrating how the connection is initialized, how properties are loaded, and where the download fails on historical versions: using System; using System.IO; using System.Net.Http; using Microsoft.SharePoint.Client; using SP = Microsoft.SharePoint.Client; class Program { static void Main() { string siteUrl = "https://example.com"; using (ClientContext sourceCtx = new ClientContext(siteUrl)) { sourceCtx.Credentials = System.Net.CredentialCache.DefaultCredentials; List sourceList = sourceCtx.Web.Lists.GetByTitle("MyLibrary"); CamlQuery query = CamlQuery.CreateAllItemsQuery(); ListItemCollection items = sourceList.GetItems(query); sourceCtx.Load(items, ic => ic.Include( item => item.Id, item => item.File, item => item.File.Versions, item => item.File.ServerRelativeUrl )); sourceCtx.ExecuteQuery(); foreach (ListItem item in items) { if (item.File == null || !item.File.Exists) continue; foreach (FileVersion ver in item.File.Versions) { string absoluteVersionUrl = siteUrl.TrimEnd('/') + "/" + ver.Url.TrimStart('/'); using (var handler = new HttpClientHandler { Credentials = sourceCtx.Credentials }) using (var client = new HttpClient(handler)) { client.DefaultRequestHeaders.Add("X-FORMS_BASED_AUTH_ACCEPTED", "f"); client.DefaultRequestHeaders.Add("User-Agent", "Mozilla/5.0"); // CRITICAL FAILURE HERE: Always throws 404 Not Found HttpResponseMessage response = client.GetAsync(absoluteVersionUrl).Result; response.EnsureSuccessStatusCode(); using (Stream fileStream = response.Content.ReadAsStreamAsync().Result) { // Upload logic to SPO goes here } } } } } } The version URL returned inside the property matches the following virtual folder layout format: _vti_history/512/Folder/Doc.docx My specific environment queries are: Why does navigating to the absolute history folder URL over an authenticated HttpClient trigger a 404 Not Found error in SharePoint 2013 on premises, even though the path token is extracted directly from the version url metadata property? Is there an alternative legacy REST endpoint routing structure or an alternative file stream extraction method available in the SharePoint 2013 (v15) SDK that allows an external client application to fetch older version binaries successfully?Integrating Azure DevOps with VS Code Agent using MCP (Model Context Protocol)
🧠 What is MCP (Model Context Protocol)? MCP is a standard interface that allows AI agents to securely interact with external systems such as Azure DevOps/ With MCP: Azure DevOps capabilities are exposed as tools GitHub Copilot can discover, reason, and execute actions All actions happen with user consent and authentication Want to learn more about MCP see https://github.com/microsoft/mcp-for-beginners ✅ Prerequisites Before starting, ensure you have: Visual Studio Code installed GitHub Copilot extension enabled Node.js 20+ installed Azure CLI installed Access to an Azure DevOps organisation 🖼️ Solution Architecture Below is a high-level view of how the integration works: VS Code → Copilot Agent → MCP Server → Azure DevOps ✅ Copilot acts as the orchestrator ✅ MCP acts as the bridge ✅ Azure DevOps is the system of record 🔹 Step 1: Authenticate with Azure 🔹 Step 2: Configure MCP in VS Code Create a configuration file: .vscode/mcp.json Add the following configuration: 🚀 What You Can Do with MCP Integration Once connected, you can: Retrieve and update work items Query repositories and pull requests Trigger pipelines Access test plans and wiki Automate repetitive DevOps operation 💡 Benefits Faster review cycles Automated summarisation of large diffs Better consistency across reviews ⚠️ Security and Best Practices MCP provides direct access to enterprise systems, so follow best practices: Use trusted MCP servers only Apply least-privilege access Avoid exposing sensitive tokens Review tool permissions before execution 🔮 What’s Next? Microsoft is evolving towards a Remote MCP Server (Preview): No local setup required Hosted integration with Azure DevOps Simplified onboarding for enterprise environments 🏁 Conclusion We are moving from: 🧑💻 Code-first workflows to 🤖 Agent-driven workflows With Azure DevOps MCP: ✅ You reduce context switching ✅ Improve developer productivity ✅ Enable intelligent DevOps automation Enable AI assistance with the Azure DevOps MCP Server - Azure Boards | Microsoft LearnHow to hide the Modify this view and Create View as per users available in groups
Hi All, I have classic view of SharePoint in list/libraries. I have group(for Managers). I just want want to show and hide the Create View/Modify View/Modify this view depends on users available in group. If user available in group(for Managers) then they can do anything like Create View/Modify View/Modify this view but if user is not a part of the group(for Managers) then they can not modify any Public views but the can create Personal view. Is there any way how I can achieve this functionality?
Circular Reference Issues - A desperate woman needs help ASAP =(
I have an incredibly in-depth spreadsheet, with about 15 pages, and in-depth tables and calculations on most of those pages. Point being, I have a HUGE freaking file with tons of data collected over the years. Now, all of a sudden, I cannot input anything without the Microsoft Excel Warning popping up, stating: "There are one or more circular references where a formula refers to its own cell either directly or indirectly. This might cause them to calculate incorrectly. Try removing or changing these references, or moving the formulas to different cells." I understand what this pop up is saying, but my file is so huge, and there is so much information, I cannot find the error anywhere!!!!! And I don't have the option to search for it. So I cannot correct this error on my own, and I cannot input anything into the spreadsheet without having to exit out of that **bleep** pop up!!! I am defeated, INCREDIBLY FRUSTRATED, and I cannot see a clear path to recovery. I have been working on this document for years now, and I cannot start fresh. HELP, HELP, HELP!!!!!!!!!!!!! SOS!! Anyone! I am desperate and beyond frustrated =(Six Coding Agents, One Production System: A Field Guide to AgenticOps with AKS-Lab-GitHubCopilot
The shift: from "AI helps me code" to "AI authors my repo" For two years we've been talking about GitHub Copilot as an inline pair programmer — a clever autocomplete that lives in your editor. That framing is officially out of date. The new reality is agentic delivery: a team of named, scoped AI agents owns slices of your repository, each with its own tools, skills, and refusal rules. They produce pull requests. They run tests. They roll deployments. And when one finishes its turn, it hands off to the next. The microsoft/AKS-Lab-GitHubCopilot's five labs you ship ZavaShop — a multi-agent retail supply-chain control plane running on AKS + Azure Container Apps — and along the way you internalize an operating model you can carry to any project. Everything in the repo (specs, agents, MCP servers, tests, Bicep, Helm, GitHub Actions) is authored by six GitHub Copilot Custom Coding Agents working from your IDE, plus the remote GitHub Copilot Coding Agent that closes the PR loop on GitHub. This is what AgenticOps looks like in practice. Two layers of agents — don't confuse them The first cognitive hurdle in this lab is keeping two very different agent populations straight: Layer What it is When it lives Examples Application agents The product you ship — the runtime ZavaShop fleet that solves a business problem Production (AKS + ACA) InventoryAgent, SupplierAgent, LogisticsAgent, PricingAgent, OrchestratorAgent Coding agents The dev-time team that writes the application agents Your IDE + GitHub requirements-analyst, mcp-builder, agent-builder, orchestrator-architect, test-author, deploy-engineer Both are built with the Microsoft Agent Framework (MAF). Both use the GitHub Copilot SDK as their model provider. But they exist at different layers of the development lifecycle, and the entire lab is structured around that distinction. If you only remember one thing from this post: the coding agents are how you build the application agents. That is the whole AgenticOps loop, compressed into one sentence. GitHub Copilot Coding Agent vs. Custom Coding Agents There are two flavors of "coding agent" in the GitHub Copilot ecosystem, and this lab uses both. 1. The remote GitHub Copilot Coding Agent This is the GitHub-side, asynchronous, PR-driven agent. You assign it an issue, it spins up a sandboxed environment, writes the code, runs the tests, and opens a PR for human review. You don't watch it work — you review what it produces. In ZavaShop, Lab 04 (Testing) explicitly uses this agent: you take a failing eval scenario, file it as an issue, assign it to Copilot, and the agent comes back with a PR. Your job is the human bar, not the keystrokes. Important governance choice from AGENTS.md: the remote Coding Agent is allowed to open PRs against src/ and tests/ only — never against infra/ without human review. That single rule is a textbook example of agent-aware policy. 2. The local Custom Coding Agents These are scoped, in-IDE specialist agents you select <agent name> in Copilot Chat. They live as *.agent.md files inside .github/agents/ and are discovered by VS Code on reload. Each one owns exactly one slice of the repository. Six of them ship in this lab: Phase Agent Owns Refusal rule Requirements requirements-analyst specs/*.md Refuses to write code MCP tools mcp-builder src/mcp_servers/* One server per turn Specialist agents agent-builder src/agents/<specialist>/* One specialist per turn Orchestration orchestrator-architect src/agents/orchestrator/*, src/shared/*, docker-compose.yml Owns wiring, not business logic Tests test-author tests/** Never edits src/ Deploy deploy-engineer infra/**, .github/workflows/** Won't touch application code The pattern that matters here isn't just "we made some custom agents." It's that every agent declares what it owns and what it refuses to do. That refusal envelope is what makes the system safe to delegate to. Without it, you'd just have a noisier autocomplete. Three workflow prompts in .github/prompts/ chain the agents together so you don't have to remember the sequence: /feature-from-issue — issue → spec → code → tests → PR → deploy /spec-to-code — drive an existing spec through code + tests /ship-it — quality gate → build → push → ACR/ACA/AKS rollout → smoke + evals This is the closest thing I've seen to a programmable software development lifecycle. Where AgenticOps fits in DevOps gave us repeatable infrastructure. MLOps gave us repeatable model lifecycles. AgenticOps is what you need when the thing you're operating is itself a fleet of autonomous agents — both at build time and at runtime. The lab makes the four pillars of AgenticOps concrete: Specs as the contract. /requirements-analyst produces specs/<slug>.md files with goals, contracts, and eval scenarios. Nothing else in the repo is built until that spec exists. Specs are the source of truth that human reviewers actually read. Skills as living documentation. .github/skills/<skill>/SKILL.md files hold shared, agent-agnostic knowledge — Python conventions, Kubernetes patterns, MAF idioms. Every coding agent declares which skills it must consult before writing code. This is how you stop drift: knowledge lives in one place and is pulled in on demand. Evals as the quality gate. The repo runs a four-layer test pyramid plus five golden eval scenarios (S1–S5). uv run poe check runs locally and in GitHub Actions. Copilot-authored PRs must pass the same bar a human does — no exceptions. Observability tied to agent identity. Every agent emits agent.name, agent.run_id, and agent.span_id through structlog. When something misbehaves in production, you can trace the line from "this evaluation failed" all the way back to "this version of this agent, on this run, called this tool with these arguments." These four pillars aren't ZavaShop-specific. They're the contract for any AgenticOps system: scoped ownership, contracts as code, evals as gates, identity in every span. Walking through the workshop: which agent does what, when The five labs are five chapters of one story — ZavaShop going from an empty Azure subscription to a live retail control plane. Each lab activates a different subset of coding agents. Lab 01 — Environment Setup (no coding agents yet) You provision the platform: AKS cluster, ACA environment, Azure Container Registry, Key Vault, and the Workload Identity that every agent will wear. Then you install the six Custom Coding Agents into your IDE. Think of this as hiring the development team and giving them their badges. Lab 02 — Agent Creation (four agents in play) This is where it clicks. You start by requirements-analyst in Copilot Chat to produce the spec for each ZavaShop application agent. Then mcp-builder is invoked four times to scaffold the four MCP servers — one per domain (inventory DB, supplier API, shipping API, pricing API). Then agent-builder runs four more times to build the typed ChatAgent specialists. Finally orchestrator-architect wires them together with a MAF Workflow. What's stunning about this lab is the handoff discipline. Every coding agent ends its turn with a line naming the next agent to invoke. You're not orchestrating the work — the agents are. Lab 03 — Multi-Agent Orchestration & Config (two agents) The orchestrator stops being a one-shot LLM call and becomes a deterministic Workflow. Secrets move from .env to Key Vault. The whole fleet boots locally with Docker Compose. This is orchestrator-architect's star turn — wiring A2A endpoints, MCP tool registration, Key Vault hydration, OpenTelemetry. Specs come from requirements-analyst; the rest is orchestration. Lab 04 — Testing (both coding agent flavors) /test-author writes the four-layer pyramid (unit, MCP contract, integration, eval). Then you switch gears: take a failing eval scenario, file it as a GitHub issue, and assign it to the remote GitHub Copilot Coding Agent. The agent works asynchronously, opens a PR, and uv run poe check decides whether it passes. This is the lab where the local-vs-remote distinction stops being abstract and starts being operational. Lab 05 — Deployment & Run (deployment specialist) /deploy-engineer writes the Helm chart for the AKS orchestrator and the Bicep modules for the ACA specialists. The /ship-it workflow prompt then runs the full pipeline: quality gate → ACR build → ACA deploy → AKS rollout → smoke tests → evals. GitHub Actions OIDC re-runs the same pipeline on every main push. Notice the pattern across all five labs: at no point does a human write production code from scratch. Humans set goals, review specs, approve PRs, and run quality gates. The keystrokes belong to agents. How Coding Agents transform the DevOps pipeline Take a step back from the lab and ask: what actually changes in your DevOps flow when you adopt this model? The atomic unit of work shifts. In classic DevOps the unit is the commit. In AgenticOps the unit is the spec. A spec drives one or more agents; agents produce commits; commits trigger CI; CI gates promotion. The commit becomes a derived artifact, not the starting point. Code review changes shape. You're no longer reviewing "did this human understand the codebase?" — you're reviewing "did this agent follow its refusal rules, consult its skills, and produce something that passes the evals?" Reviewers spend less time on style and more time on intent. The diff is often less interesting than the spec it came from. Governance becomes structural, not procedural. Instead of writing a wiki page that says "don't touch infra without review," you encode that rule in AGENTS.md and refuse to let the agent's tool set include infra paths. Policy becomes part of the agent definition, not a checklist humans hopefully remember. The CI pipeline expands. Beyond build/test/deploy, you now have an eval stage that asks "does the system still behave correctly on the golden scenarios?" — and a Copilot-authored PR has to pass the same eval stage as a human-authored one. The pipeline is the great equalizer. Onboarding compresses. A new engineer doesn't need to read 50 wiki pages to be productive. They read AGENTS.md, select the relevant agent walks them through. Institutional knowledge lives in .agent.md and SKILL.md files instead of senior engineers' heads. The net effect is a pipeline that's faster, more uniform, and easier to audit. Faster because agents parallelize what humans serialize. More uniform because every change goes through the same six-agent template. Easier to audit because every artifact has a named author and a refusal rule it had to respect. What to take away The AKS-Lab-GitHubCopilot workshop teaches three things at once. The surface lesson is "how to build a multi-agent retail system on AKS." The middle lesson is "how to use GitHub Copilot Custom Agents and the remote Coding Agent." The deepest lesson — and the one I'd argue matters most — is how to design a development process where AI agents are first-class citizens with bounded responsibilities, not free-form copilots. If you take the model and walk away from the lab, three patterns are worth keeping: Scope before capability. Don't give an agent every tool; give it the smallest surface that makes it useful. Specs are the API between humans and agents. Invest in requirements-analyst-style flows even if the rest of your stack isn't there yet. Evals are non-negotiable. The moment an agent can open a PR, you need a quality gate that doesn't care who the author is. Clone the repo microsoft/AKS-Lab-GitHubCopilot , hit Developer: Reload Window, select agents in Copilot Chat, and watch six teammates show up. That's the future of the DevOps pipeline — and it's already shipping. Resources microsoft/AKS-Lab-GitHubCopilot — The repository this post is built on. Best practices for using Copilot to work on tasks — Governance patterns for delegating issues to Copilot. GitHub Copilot SDK (Python) — The provider used by every agent in this lab.
pnp-modern-search does not work in the local SharePoint workbench
Version used 4.9.0 (SPFx 1.15.0) Describe the bug The solution works correctly when deployed using the .sppkg package in SharePoint Online, but it does not work in the local SharePoint workbench. There are two related issues: When running gulp serve, the build/runtime reports an error related to microsoft/sp-webpart-workbench/lib/api/, suggesting a failure in loading or resolving the local workbench API module. When adding the web part to the local workbench page, the web part fails to render with the following error: Error: Cannot find module './15.js' The second error appears to be related to a missing or incorrectly resolved chunk/module during bundle loading. The issue only occurs in the local workbench. The deployed .sppkg solution in SharePoint Online works correctly. Node.js version: 16.8.0 (compatible with SPFx 1.15.0). Dependencies installed via npm install without errors. To Reproduce Clone the repository Run npm install Run gulp serve Open the local SharePoint workbench Add the web part to the page Observe: Error during gulp serve related to microsoft/sp-webpart-workbench/lib/api/ Web part fails to load with Cannot find module './15.js' Expected behavior The web part should load and render correctly in the local workbench without module resolution errors. Desktop : Browser: Chrome Node.js: 16.8.0 SPFx: 1.15.0
Ability to schedule email of SharePoint post
We've started using SharePoint to create and send mass emails in our organization, but its a huge pain that I can't schedule them ahead of time to send at a specific time/date. Could you work on creating a way to schedule not just the publishing of a SharePoint news post, but when it is shared via email? That would be amazing.
