Welcome to the April 2026 update. In broader Microsoft 365 news, Copilot's Agentic capabilities are now generally available, and Copilot Cowork, which is an agentic AI capability that acts like a digital teammate—turning your goals into multi-step plans and helping execute tasks across apps (email, meetings, documents, workflows) with user oversight, is available via the Frontier program. 

For Excel, new Edit with Copilot capabilities include the Chat/Edit switcher, step-by-step reasoning with plan mode, understanding changes made by Copilot, and the ability to use the power of Python directly from Copilot, as well as new OpenAI GPT-5.5 and Claude Opus 4.7 models.

Excel for Windows, Mac, and web:
- New Edit with Copilot capabilities

Excel for iOS:
- Modernized comments experience on iPhone

Excel for Windows, Mac, and web

New Edit with Copilot capabilities

Chat/Edit Switcher

Users will see a chat/edit switcher above the prompt box that lets them control how Copilot interacts with their workbook: 

• Chat only: Copilot answers questions, provides suggestions, and offers guidance—without making direct changes to the file. 

• Allow editing: Copilot actively works in the workbook or spreadsheet—creating content, applying formatting, building formulas, and making app-native edits. 

 By default, ‘Allow editing’ is enabled for many users with Copilot access

Plan mode
Plan mode for Copilot in Excel helps users make complex changes with confidence by outlining a clear, step‑by‑step approach before anything in the workbook is updated. Users can review how Copilot intends to complete the task, see which data or capabilities may be used, and adjust the plan as needed—helping ensure edits are intentional. This makes it easier to tackle multi‑step or high‑impact tasks while staying in control of every change.

Understand changes from Copilot
Copilot makes spreadsheet edits easy to see and control by highlighting changes directly on the grid and marking modified sheets with a green tab indicator. These visual cues persist during a Copilot turn and clear once you're done, keeping you oriented without any clutter.

Python
You can now use Python directly in Edit with Copilot in Excel to take on more advanced data analysis—without needing to leave your workbook. Copilot can apply Python-powered techniques as it makes edits, helping you transform data, generate visualizations, and complete complex, multi‑step tasks in place. When Python is enabled, Copilot can create charts and other visual outputs as part of your requested edits—bringing advanced analytical capabilities into the same experience you use to clean, reshape, and update your spreadsheet. You can invoke this feature directly in your prompt by asking Copilot to use Python for the analysis, or Copilot may invoke Python when appropriate.

Excel for iOS

Modernized comments experience on iPhone
The updated Comments pane experience improves the clarity and usability of mobile commenting by making comment threads easier to find, read, and act on. With a more modern, streamlined user interface, you can more quickly understand what needs your attention, respond quickly, and stay engaged in collaboration as you review your files on the go. Read more here >

Many of these features are the result of your feedback. THANK YOU! Your continued Feedback in Action (#FIA) helps improve Excel for everyone. Please let us know how you like a particular feature and what we can improve upon—"Give a compliment" or "Make a suggestion".  You can also submit new ideas or vote for other ideas via Microsoft Feedback.

Subscribe to our Excel Blog and the Insiders Blog to get the latest updates. Stay connected with us and other Excel fans around the world – join our Excel Community and follow us on X, formerly Twitter.

Special thanks to our Excel MVPs David Benaim, Bill Jelen, Alan Murray, and John Michaloudis for their contribution to this month's What's New in Excel article. David publishes weekly YouTube videos and regular LinkedIn posts about the latest innovations in Excel and more. Bill is the founder and host of MrExcel.com and the author of several books about Excel. Alan is an Excel trainer, author and speaker, best known for his blog computergaga.com and YouTube channel with the same name. John is the Founder & Chief Inspirational Officer at MyExcelOnline.com where he passionately teaches thousands of professionals how to use Excel to stand out from the crowd.

GitHub Copilot in Visual Studio is becoming more agentic with every release. This update brings cloud agent integration front and center, letting you start remote coding sessions without leaving the IDE. Custom agents now support user-level definitions that travel with you across projects, C++ code editing tools for agent mode are generally available, and a new Debugger Agent that validates fixes against real runtime behavior.

Download Visual Studio 2026 to try everything in this update.

Cloud agent integration

Cloud agents run on remote infrastructure for scalable, isolated execution, and you can now start new sessions directly from Visual Studio. Select Cloud from the agent picker in the Chat window, describe the work you need help with, and the cloud agent takes it from there.

The workflow starts by asking for permission to open an issue in your repository, then creates a pull request to address it. While the cloud agent prepares the PR, you can keep working on other tasks in Visual Studio or close the IDE entirely and come back later. When the PR is ready, you get a notification with options to View PR or Open in browser.

Cloud agent in Visual Studio is currently powered by Copilot coding agent. To use it, make sure you are in a GitHub repository and that Copilot has permission to create issues in that repository. This is a different way of working that frees you up to focus on the parts of your project that need your full attention.

Build your own custom agents

Custom agents launched last month with support for repository-based .agent.md files. This update extends the story with user-level agents that travel with you across projects.

User-level agents are stored in %USERPROFILE%/.github/agents/ by default. You can change this location in Tools > Options > GitHub > Copilot > Copilot Chat > Custom agents user directory. Creating new agents is also easier now: click the + button in the agent picker and follow the prompts.

Everything you could do with repository-based agents still works: workspace awareness, code understanding, tools, model selection, and MCP connections to external knowledge sources like internal documentation, APIs, and databases. The community has been sharing agent configurations on the awesome-copilot repository if you are looking for starting points. We’d love to see what you build.

C++ code editing tools for agent mode

C++ Code Editing Tools for GitHub Copilot agent mode are now generally available by default. These tools give Copilot language-aware navigation of your C++ codebase, helping it map out class inheritance hierarchies and follow function call chains when refactoring or modifying code.

To get started, open a C++ project with IntelliSense configured and enable the tools using the Tools icon in Copilot Chat. The two available tools are get_symbol_call_hierarchy and get_symbol_class_hierarchy.

Once enabled, Copilot uses these tools automatically. For example, you can ask Copilot to analyze the major classes in a file and it will use get_symbol_class_hierarchy to trace inheritance and usage relationships across your codebase.

If you work with large C++ codebases, these tools make a real difference. They work best with AI models that support tool-calling, so check the model comparison page to see which ones are compatible.

Agentic Issue to Resolution

Debugging with static analysis only gets you so far. The new Debugger Agent workflow validates bugs against real runtime behavior, walking you through a complete loop from understanding the issue to verifying the fix through live execution.

Start from a GitHub or Azure DevOps issue, or describe the bug in natural language. Switch to Debugger mode using the dropdown in the lower-left corner of the chat, and the agent maps the problem to your local source code. From there, it works through a structured process: creating a minimal reproducer, generating failure hypotheses, instrumenting your app with tracepoints and conditional breakpoints, running the debug session to analyze live telemetry, and suggesting a precise fix at the exact failure point.

You can interact with the agent during the debugging process to provide additional context, discuss your theory, or refine the fix in real time. This is debugging that works with you, not just for you.

IntelliSense takes priority over Copilot

Seeing IntelliSense and Copilot completions at the same time can be distracting. We heard your feedback, and the editor now prioritizes the IntelliSense completion list, showing only one suggestion at a time.

When IntelliSense is active, Visual Studio temporarily suppresses Copilot completions so you can focus on your current selection. After you dismiss or commit the IntelliSense selection, Copilot completions resume automatically. This behavior is enabled by default, so just update and code as you normally do.

Customizable Copilot keyboard shortcuts

You can now customize the keyboard shortcuts for accepting Copilot inline suggestions. Whether you want to change the key for accepting a full suggestion, the next word, or the next line, it is all available in standard keyboard settings.

Head to Tools > Options > Environment > Keyboard and search for the commands: Edit.AcceptSuggestion, Edit.AcceptNextWordInSuggestion, or Edit.AcceptNextLineInSuggestion. Remove the existing binding and assign your preferred shortcut under the Inline Suggestions Active scope.

Your new shortcut appears throughout the editor hint bar, so you always know which key to press.

From our entire team, thank you for choosing Visual Studio! For the latest updates, resources, and news, check out the Visual Studio Hub and stay in touch.

Happy coding! The Visual Studio team

The post Visual Studio April Update – Cloud Agent Integration appeared first on Visual Studio Blog.

Here's something that I didn't know you could do: You can build .NET native DLLs using AOT compilation, that can be compiled to platform specific native DLLs. For example, on Windows you can compile an AOT library down to a Standard Calling Convention type DLL that you can call from any tool that can access WinApi dlls.

I'm specifically looking at this for some Windows DLLs that I eons ago created C compiler built DLLs. Moving those into .NET and C# certainly would make a number of things easier including not having to install the C++ compiler and all its crazy Windows dependencies (C++ SDK, ATL etc.) and dealing with the constant version update hassles in Visual Studio when the C++ compiler revs.

My specific use case involves some very old FoxPro x86 code on the client end calling into DLL code, so I'll use FoxPro for the client end of the examples that call into the AOT code here.

Setting up an AOT Project for native Windows DLL Compilation

So here's what you need to create an .NET AOT DLL for use as a Windows API style DLL:

• Create a project file and set it up for AOT compilation
• Create a class and use specific attributes to specify native Exports
• Use dotnet publish to build the native DLL for each target platform

Let's start with the project file:

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<TargetFramework>net10.0</TargetFramework>
		<ImplicitUsings>enable</ImplicitUsings>
		
		<!-- These are the critical settings -->
		<PublishAot>true</PublishAot>
		<NativeLib>Shared</NativeLib>
		<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
	</PropertyGroup>
</Project>

Next create a class and add the appropriate attributes:

public static class Exports
{    
    [UnmanagedCallersOnly(
        EntryPoint = "Add",
        CallConvs = new[] { typeof(CallConvStdcall) })]
    public static int Add(int a, int b)
    {
        return a + b;
    }
}    

The key bit here are the [UnmanagedCallersOnly] attribute which marks the method for external access. For Windows Standard Call or 'WinApi' style DLLs you can specify the CallConvStdcall type which is required in order to generate the DLL export, so the exported function becomes visible.

Next you need to build the project. A plain build just builds a .NET DLL, but in order to create the native DLL you have to dotnet publish it.

Open a terminal in the project folder and then use:

dotnet publish -c Release -r win-x64 /p:PublishAot=true
dotnet publish -c Release -r win-x86 /p:PublishAot=true

You should publish for each of the platforms you want to target.

To call this now externally - FoxPro in my case - I can do the following:

lcDll = FullPath("wwDotnetBridge_Loader.dll")

DECLARE integer Add;
     in (lcDll) ;
     as DotnetAdd ;
     integer a, integer b 
     
? DotNetAdd(1,5)

Et voila: You now have a Windows compatible DLL that you can call from another application.

The file is 850k - not exactly tiny but considering it's .NET code that's not bad. As you add features though, the size of the DLL gets bigger. Obviously the code above does very little so that's about as small as the DLL gets and from here any dependencies used increase the size - the bigger the dependency the bigger the size! For the samples I show here (which are all very minimal!) the size will end up at about 1.5mb.

It's .NET but it's different

Although you're building your code with .NET, a Windows native DLL that is called using external non-.NET code has to behave more like a C/C++ method than a .NET interface. This means that while you can easily pass primitive parameters like the integers I passed above back and forth, for just about anything else you have to fall back to C style calling conventions, which means pointers for strings and objects, ints for boolean values and so on. The only straight through values are number primitive types (int, long, double, single).

This makes passing parameters in and out a bit more tedious. Here's an example of passing strings in and out:

[UnmanagedCallersOnly(
    EntryPoint = "StringInStringOut",
    CallConvs = new[] { typeof(CallConvStdcall) })]
public static int StringInStringOut(IntPtr input, IntPtr output)
{
    // retrieve the input buffer        
    string inputStr = Marshal.PtrToStringAnsi(input) ?? string.Empty;


    // get the empty buffer for size
    string outputStr = Marshal.PtrToStringAnsi(output) ?? string.Empty;
    if (outputStr.Length < 1)
        return 0; // output buffer too small

    var result = inputStr + " !!!"; // "Echoing back your message:\r\n\r\n" + inputStr;

    WriteAnsiString(output, outputStr?.Length  ?? 0 , result);
    return outputStr.Length;  // success
}

In typical Windows API style string output is passed in as a buffer address that is filled by the method. Input too comes in as a pointer that has to be deferenced back into a string first.

To call this from FoxPro looks like many Windows APIs by providing a pre-allocated buffer for the return value:

DECLARE integer StringInStringOut ;
     in (lcDll) ;
     string input, string@ output

lcOutput = SPACE(255)
? StringInStringOut("Hello World. Time is: " + TIME(), @lcOutput)
? lcOutput

Objects? Yes but no Thanks!

Object passing is even more painful especially when you work with a non-structured client like FoxPro that can't easily construct a fixed structured. For objects, the best way is to use Structures with fixed layouts that can be filled and read by the client.

Here's an example of passing data in via a structure, updating it and passing it back:

[StructLayout(LayoutKind.Sequential, Pack = 1, CharSet = CharSet.Ansi)]
public struct PersonInfo
{
    public int Id;
    public double Amount;
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 64)]
    public string Name;
}

[UnmanagedCallersOnly(
    EntryPoint = "ProcessPerson",
    CallConvs = new[] { typeof(CallConvStdcall) })]
public static int ProcessPerson(IntPtr personPtr)
{
    if (personPtr == IntPtr.Zero)
        return -1;

    // read the structure from the VFP buffer
    var person = Marshal.PtrToStructure<PersonInfo>(personPtr);

    var id = person.Id; // return val        
    
    // Update fields
    person.Id += 100;
    person.Amount += 10.00;
    person.Name = "Updated from .NET";

    // Write updated struct back into same VFP buffer
    Marshal.StructureToPtr(person, personPtr, false);

    return id;
}

From FoxPro this code is ugly as you have to create the binary layout via string construction. Here's what that looks like:

lcStruct = ;
    BINTOC(11, "4RS") + ;        && int Id
    BINTOC(99.95, "8B") + ;       && double Amount - verify format
    PADR("Rick", 64, CHR(0))      && fixed char[64]
? lcStruct

DECLARE INTEGER ProcessPerson IN (lcDll) STRING@ person

lnResult = ProcessPerson(@lcStruct)
? lnResult  && 11

***  retrive the data back out
lnId = CTOBIN(SUBSTR(lcStruct, 1, 4), "4RS")  
lnAmount = CTOBIN(SUBSTR(lcStruct, 5, 8), "8B")
lcName = SUBSTR(lcStruct, 13, 64)
lcName = LEFT(lcName, AT(CHR(0), lcName + CHR(0)) - 1)

? lnId    && 111
? lnAmount
? lcName

Yeah that's not pretty, but it gives you the idea of how to pass complex data in and out using StdCall DLL interface. This isn't any better than standard C/C++ because we're building a native DLL.

There are FoxPro libraries that can help with structure conversions (Vfp2C32) but even then this process is tedious and error prone especially if structures change.

When does this make Sense?

I was pretty excited about the idea of having access to C# to create DLL interfaces to replace some of my ancient nearly unmaintainable DLL interfaces. Using C/C++ for critical components is a PITA and requires installation of the C compiler and all of the required dependencies which break every time a new version of the compiler or the Windows SDK ships. So yeah, replacing C with C# and AOT compilation seems like a good idea.

But... there are issues. I use .NET Interop a lot from different applications, but one thing that has always bugged me is the need for the loader DLL that fires up the .NET Runtime Host. First of that code is incredibly dense and LLMs invariably have gotten this wrong for me on many occasions trying to clean this up. Unfortunately it turns out that using .NET and AOT doesn't help here as COM wrapper interfaces are not part of AOT. And even if it was, it probably would bloat the startup to multi-meg size that would be unacceptable.

The reality is that in order to do something productive with this technology you really still need to use the awkward calling syntax which is a large part of the pain involved with C code in the first place. That doesn't go away with AOT. And if you need to do serious work in C# code that requires runtime dependencies you're very likely to end up with a fairly large DLL anyway.

For most scenarios I'd recommend just sticking to traditional ways to call into .NET via COM Interop or wwDotnetBridge or something similar, and just use the .NET Runtime interface. Yes it's not native code, but you do get benefit of a clean calling interface and code that is only slightly slower on first access as the JIT compiles code. After that I wouldn't expect any reduced performance compared to native AOT compilation vs. standard Interop access.

I could see it useful for some things. I may still end up using it for my wwDotnetBridge bootstrapping DLL. Although I can't use the runtime libraries to load up the .NET Runtime Host I might be able to make this work with P/Invoke calls. Again the only real benefit I see for this is that would allow me to kick out the C compiler from my build pipeline which would be a win.

Summary

In the end using AOT to create native DLLs is a very niche feature that has a very narrow optimal usage range, that probably benefits only certain bootstrapping scenarios. Almost everything else is probably better handled with full .NET interop with the same performance profile other than initial JIT compile overhead.

However, if you find yourself with one of those very narrow use cases, I hope this post has given you the background for what you need to know to create your AOT DLLs...

It’s been about a day and a half since I returned from baby bonding leave, and my mind is already racing. Google has a generous leave policy, and I decided to truly unplug during that time to give my growing family my full attention. But as any developer knows, a “reset” often leads to a “rethink.”

The pace of innovation in this AI-driven world is, frankly, astonishing. One of the first things I noticed upon my return was the rise of agent skills. Essentially, these are folders of instructions, scripts, and resources that agents can discover and use to perform tasks more accurately and efficiently.

The Angular team recently released its own set of Angular agent skills (GitHub), and I just caught up on Addy Osmani’s agent-skills repository. His collection, which covers the entire software development lifecycle, recently went viral — and for good reason. Organizing skills in a cohesive way for agents to accomplish complex tasks brought me right back to a concept I was musing over before my leave: Agent Building Blocks. To understand my interest in this concept, let’s take a look at one of my favorite projects from last year.

The Experiment: The Angular AI Tutor

Last year, I created the Angular AI Tutor. The goal was to teach developers Angular interactively by guiding them step-by-step through building a modern application. You can access it now via the Angular MCP server.

The surprising part? Creating it wasn’t an uphill battle in terms of complexity. The instructions are open-sourced and written in plain English. It started as a simple experiment: Could I get Gemini to teach me Angular?

With a modest 10-line rules file, the answer was a resounding yes. Gemini didn’t just provide information; it created a learning journey that emphasized critical thinking and joy. But as I moved from “experiment” to “product,” I hit two major roadblocks:

• Lesson Continuity: Creating a cohesive lesson plan where every step builds toward a single, navigable app.
• Syntax Recency: Ensuring the agent used modern features (like Signals) that the model wasn’t originally trained on.

The Maintenance Nightmare

After some trial and error, I overcame these hurdles with a README that totaled 824 lines. Not bad for a functional tutor! The project sparked considerable interest — Angular GDEs wanted to build their own, and teams like Flutter and Firebase were curious about the “Tutor” model for their own ecosystems.

However, there was a problem that needed to be addressed first: The logic was too “coupled.”

The instructions that controlled the tutor’s behavior were intertwined with Angular-specific syntax. This created a few headaches:

1. Low Reusability: Retrofitting the tutor for Firebase or Flutter required a massive rewrite.
2. Duplication: We had separate rules for the tutor and separate rules for general code generation.
3. Update Friction: Adding a new module like Signal Forms was time-consuming because changes had to be made in multiple places.

My first attempt at a fix — breaking the language into multiple rules files — flopped. Without an agent routing mechanism, the model had trouble deciding which “skill” to pull from and when.

The Vision: Context Pipeline Engineering

In one of my last meetings before bonding leave, I proposed a Router + Building Blocks architecture. The idea was to break the AI tutor’s brain into modular components that could be reused or swapped for different frameworks. At the time, I wasn’t sure how to build it.

Now that I’m back, I see Agent Skills as the potential vehicle for this vision. But there are still some questions we need to explore:

• Extensibility: How do we make these skills customizable for individual developer workflows?
• Reliability: How do we keep the skills and their use by the model reliable in the presence of other skills, tools, and context used by the model?
• Token Optimization: How do we keep building block pipelines up-to-date while ensuring they don’t bloat the model’s context window?
• Stability: As models evolve, how do we ensure the “pipeline” doesn’t break?

I’ve started calling this discipline Context Pipeline Engineering. If you’re interested in these deeper, structural questions about AI engineering, I touched on some of these themes in my ng-conf talk: Architect or Assembler: Your Role in the AI Future.

It’s good to be back. Subscribe to our YouTube channel and blog to follow along as we explore these questions and more. Let’s build something.

Back from Baby Bonding: Agents, Building Blocks, and the Future of AI Engineering was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.