Robert Fennis, an RF engineer and consultant from the Netherlands and the creator of EMerge: a free, open-source 3D Finite Element Method (FEM) electromagnetic solver written in Python. They demystify the black magic of RF engineering, breakdown the mathematical and physics foundations of simulation, and explain how Robert is building the IKEA of FEM solvers to make electromagnetics accessible to everyone.

Timeline

• Chris welcomes Robert Fennis, creator of EMerge, to discuss RF simulation as a way to unlock knowledge of the universe. (00:00:15)
• LinkedIn Shout-outs: Chris and Robert praise the amazing RF visualizations done by past guests Lukas Henkel, Sam Aldahar, and Katerina Galitskaya. (00:01:20)
• The Wizard School of RF: They discuss how RF engineering is often seen as a black magic wizard school of electronics, despite being normal to Robert. (00:03:10)
• Pyramid of Knowledge: Robert explains how learning RF and simulation is like building a pyramid step-by-step, where you have to understand waves, ports, and S-parameters rather than trying to build it all from scratch. (00:05:00)
• Python and LLMs: EMerge is written as a Python module but utilizes fast external libraries under the hood. They talk about how script-based engineering allows LLMs to assist by writing simulation code from existing examples on the EMerge Hub on GitHub. They draw a comparison to OpenSCAD’s parametric code-first approach in mechanical design. (00:07:30)
• The Big Three Full-Wave Simulation Methods: Robert explains how full-wave solvers attempt to approach exact solutions to Maxwell’s equations. (00:11:30)
  • Finite Difference Time Domain (FDTD): A time-stepping method that operates similarly to movie physics engines, marching forward in time. (00:12:15)
  • Method of Moments (MoM): A method solving specifically for currents and voltages on conductors, using Green’s functions to calculate interactions without discretizing the surrounding air. (00:13:40)
  • Finite Element Method (FEM): A frequency-domain solver derived from variational calculus (the Principle of Least Action). It solves for complex electric fields in the airspace surrounding conductors, treating conductors as boundary constraints. (00:15:10)
• The Veritasium Switch Video: They connect the physics of FEM to the famous Veritasium switch debate, noting that energy travels outside of wires. This is why FEM solvers must discretize the surrounding airspace to capture the physics, as famously illustrated in the Veritasium switch video. (00:18:20)
• The Challenges of Real-World Boundaries: In FEM, boundary conditions define where the simulation ends. Choosing the right boundaries is critical because perfect electric conductors can introduce unrealistic internal resonances. (00:20:45)
• Simplifying vs. Overcomplicating Models: Mentor advice on simplifying models to ensure convergence. Robert warns that adding too much detail quickly exhausts RAM, which is currently expensive. (00:22:15)
• Frequency and Detail: A rule of thumb is that higher frequencies make small details matter more. Right-angled corners on PCB traces act as parasitic capacitors at 10 GHz, and silk screen on a 2.4 GHz patch antenna can completely de-tune it. (00:24:30)
• Bluetooth Antenna Design Workflow: Chris shares his fear of designing custom 2.4 GHz antennas for boards like the NRF52840. Robert outlines his step-by-step customer consultation process, evaluating orientation and directivity (omnidirectional vs. directional). (00:32:15)
• The Logarithmic Scale of Decibels: Squeezing S11 reflection coefficients from -20 dB to -25 dB only wins a fraction of a percent of energy. Since receivers have massive dynamic ranges, aiming for -10 dB or even -5 dB is often perfectly fine for non-critical systems. (00:36:40)
• The Incremental Design Method: Instead of modeling the entire system, start with the simplest geometry (e.g., a simple square patch or wire). Find the length where it resonates, and then introduce components like plastic enclosures, screws, or clips one by one to see how they shift the resonant frequency. (00:41:20)
• Working with Ports in EMerge: EMerge uses lump ports (numbered starting from 1) for PCBs and computes S-parameters like S11, which can be plotted on a logarithmic scale with the built-in plot_SP function. (00:44:50)
• Alternative EMerge Applications: (00:47:45)
  • PCB Filters: Designing microstrip and coupled-line filters on FR4 or Rogers substrates. FR4 is risky due to variations in refractive index, making simulation validation highly valuable before spending money on expensive substrates. (00:48:10)
  • Radar Cross-Section (RCS): Modeling how objects scatter electromagnetic waves. (Note: Large stealth bombers are computationally impractical for EMerge, but smaller models work). (00:51:30)
  • Power Dividers: Tuning Wilkinson power dividers. (00:52:45)
  • Crosstalk and Signal Integrity: Making sure high-speed 1 Gbps bitstreams arrive intact without degrading or leaking into other ports. You can view an example crosstalk simulation on the EMerge Showcase page. (00:53:30)
• Under-the-Hood Engineering and Performance: (00:55:00)
  • Robert shares his story of spending a week straight getting 3D solver matrices to assemble and solve. (00:55:15)
  • He highlights that 98% of the effort in building a solver is computational geometry (meshing), for which EMerge uses the GMSH library. (00:58:30)
  • Linear algebra is solved using Intel MKL on x86 platforms (thanks to Olaf Schenk) and Apple Accelerate on macOS (thanks to Dr. Jonathan Hogg). (01:00:15)
  • The solver assembles sparse coordinate matrices converted into compressed column storage. (01:02:00)
  • Robert wants EMerge to be the IKEA of FEM solvers—not perfect, but free, accessible, and good enough. (01:03:50)
• The Nightmare of Importing PCBs: Why computational geometry makes importing PCBs incredibly difficult. (01:08:15)
  • Gerber Files: Aperture-based photographic formats. Approximating circles with polygons can lead to tiny gaps that crash mesh engines. (01:09:45)
  • STEP Files: They model trace thickness physically (which is unnecessary for EMerge) and cause floating-point rounding errors on round holes. (01:11:30)
  • ODB++: Robert is using Claude/AI to help write an ODB++ parser. (01:13:00)
• Method Chaining and the Builder Pattern: An alternative to importing CAD files is describing geometry programmatically using a method chaining philosophy in Python (e.g., drawing traces with straight, turn_right, and skip functions). This forces the user to keep things simple, making the design additive rather than subtractive. (01:15:45)
• Closing Thoughts and Consulting: Robert runs a consulting business but emphasizes that the open-source software is GPLv2 and has no warranty. He prefers teaching clients how to use the software and run simulations themselves. You can connect with Robert and other RF simulation enthusiasts via the EMerge Discord community. (01:19:30)

Recommended Reading List

• The Finite Element Method in Electromagnetics by Jian-Ming Jin (the mathematically dense Bible of FEM)
• Davidson’s electromagnetics textbook
• Computational Electromagnetics with MATLAB by Matthew M. Sadiku (an accessible textbook that can be translated to Python or Octave)

How to Set Up Copilot Skills in PowerPoint (and Build Your Own)

You have a deck you rebuild every month. The business review, the project update, the readout for leadership. Every time, the same work. Cut the bullets down. Fix the capitalization someone else broke. Take 20 slides down to 7 so an executive will read it.

Copilot in PowerPoint does all of that, and it's good at it. Then next month you open a new deck and type the whole thing out again, because Copilot doesn't remember how you like it done.

That's the problem skills solve.

I help organizations roll out Copilot in front of thousands of users, and skills are the feature I see the fewest people using. Plenty of teams are paying for it and have never turned it on.

What a skill is

A skill is a pattern you wrote down once.

Take the thing you explain to Copilot over and over. Put it in a file with a name, a description, and a set of instructions. Save it. From then on you point Copilot at the skill instead of retyping the prompt, and you get the same result without rebuilding it.

Monthly business review formatting. Your team's deck standards. The way you like speaker notes written. All of it becomes something you call by name.

Two things before you start

A Microsoft 365 Copilot license. Skills live in the Copilot pane inside PowerPoint. No Copilot in your Office apps, no skills.

An Anthropic model. This is the one that catches people. Open the Copilot pane, find the model picker, and switch from GPT to Claude. Opus 4.8 is fine. On a GPT model your skills will sit there and do nothing, and you won't get an error explaining why. That will probably change. Today it's where things stand.

Turning skills on

Open Copilot in PowerPoint. Hit the plus button at the bottom of the pane, then Choose skills.

You'll already have a few there from Microsoft. Run one before you build anything of your own.

You can also call a skill by name. Type @ and the skill name in your prompt, the same way you'd mention a person, and Copilot runs that one. Once you know what you have, it beats going through the menu every time.

I opened Background and context on a text-heavy slide and asked it to visualize the slide. It created a new slide and generated an image that carried the same information in a format I could read at a glance. Side by side with the original, it wasn't close.

Skill plus prompt

The image was good, and it was an image, so I couldn't edit any of it.

So I asked, in plain language: I like this, can you make it more native PowerPoint so I can edit it? Keep the structure.

It rebuilt the whole thing with real PowerPoint objects and kept the layout that made it work. I wasn't running any branding at that point and it still came out clean.

Skill first, then prompt. That combination is where most of the value sits. The skill gets you 80 percent of the way with no typing, and the prompt handles the part only you know.

Building your own

Go back to the plus button, Choose skills, then Manage skills. There's a Custom skills section, and it'll be greyed out until you have skills of your own.

Don't hand-write the skill file.

Grab Microsoft's documentation page, the one PowerPoint links to from the Manage skills pane:

https://support.microsoft.com/en-us/powerpoint/copilot/copilot-in-powerpoint-skills

Paste that URL into Copilot and say: using this link, help me build a PowerPoint skill that does X.

Copilot reads the requirements and writes a file that fits the format. You're using AI to build AI, and it saves you more than typing. Skill files have real formatting rules, and Copilot will meet them instead of you finding each one through a failed upload.

The format itself is short. A skill is a folder with a SKILL.md file in it. The file opens with a frontmatter block between three-dash delimiters holding a name and a description, and everything below that is your instructions. Spend your time on the description. That's the part telling Copilot when to reach for the skill, so a vague one means it never fires.

If somebody sent you a skill, paste that in too and let Copilot clean it up.

Where skills live

In Manage skills, if you've never set this up, you'll see an option to create your skills library. Click it and Copilot creates the folder in your OneDrive.

Pay attention to the path, because you'll need it:

OneDrive > Documents > Copilot > Microsoft PowerPoint > skills

Each skill is its own folder with a SKILL.md file inside. Drop new skills in there and they show up in PowerPoint.

One catch: after you add something to OneDrive, refresh PowerPoint. It has to reload the folder. If you added a skill and it isn't showing, that's usually why.

The other one that will bite you is the folder name. It has to match the name inside the SKILL.md file. Copilot skips any folder where those two don't line up, and it skips it quietly. No error, no warning, the skill is missing. If you refreshed and it's still not there, check that next.

Two ways to add a skill, and the limit on one of them

You don't have to touch OneDrive at all.

In Manage skills, Add skill lets you upload an .md file, or type a skill in by hand with a name, description, and instructions. PowerPoint builds the folder structure and the file for you.

I lost time on this one. The box where you type or paste a skill in caps at 1024 characters. I had Copilot write me a few skills, they came out longer than that, and I got errors that didn't explain themselves. I built them with Copilot, so I assumed they were fine.

That cap is on the typed box. Uploading an .md file, or dropping the folder straight into OneDrive, doesn't have it. So if you have a long skill, don't cut it down to fit. Upload it as a file instead.

Three skills on one bad deck

Here's what I have built:

• Brand check. Reviews wording, terminology, and capitalization against our team's deck standards. No layout changes.
• Handoff notes. Writes speaker notes for someone else to deliver. I write the deck knowing I might not be the one presenting it, and my notes are useless to anybody but me.
• Slide diet. Takes a long deck, cuts the fluff, consolidates what's left.
• Slide design. The visual pass.

I ran three of them on a plain deck, in order.

Brand check went first. Text only. It consolidated some lines, rewrote a few, and fixed capitalization.

Slide diet went second. It broke walls of text into bullets and cut what wasn't earning its place. Five bullets beat a paragraph block, and it made that call without being told.

Slide design went last. This is the one where you sit back and let it work. Black text on white turned into something branded and visual, with the information in an order that reads.

Three skills, and a deck I didn't want to read became one I'd present.

Brand kits

One more thing in that same plus menu: Brand.

A brand kit holds your colors, fonts, and icons. You can build one for yourself, or your organization can publish one for everybody in the tenant. Pair a brand kit with a design skill and decks come out on-brand without anyone checking hex codes by hand.

What it cost and what it saved

The full run took 30 to 40 minutes, and the design pass was about 10 of that. Copilot needs time to work through a deck. This isn't instant.

Building that by hand, at the quality it came out at, is 4 to 8 hours. A full day.

The documentation

Microsoft's page for all of this is here:

https://support.microsoft.com/en-us/powerpoint/copilot/copilot-in-powerpoint-skills

It has the format requirements, the three ways to add a skill, and how to edit or delete one. Worth a read before you build your second skill.

One thing that page points to is worth knowing: the SKILL.md format is an open spec, not a PowerPoint invention. So the skills you write here aren't stuck in PowerPoint.

Where to start

Pick the pattern you repeat most, not the hardest deck you own.

Write down what you'd tell a new hire about how you do it. That's your first skill. Hand it to Copilot, let it write the file, drop it in the folder, refresh PowerPoint.

Then be curious, and go push some buttons.

Open models are driving a new wave of AI innovation, giving organizations more freedom to choose the models that best fit their requirements for performance, cost, latency, customization, and governance. As the open model ecosystem evolves rapidly, developers want access to the latest innovations without being locked into a single model provider or deployment approach.

That's why Microsoft Foundry continues to invest in bringing leading open models to a unified platform. Our goal is simple: help developers discover, evaluate, and deploy the right model for each workload while benefiting from consistent tooling, enterprise-grade governance, and flexible deployment options.

Today we're announcing several additions to the Foundry models catalog:

• DeepSeek-V4-Flash-0731 as a Direct from Azure model and through Fireworks on Foundry
• NVIDIA Nemotron 3.5 Lightning through Fireworks on Foundry and through the Hugging Face collection on Foundry

More choices for agentic AI and enterprise applications

Many of today's most popular open models are advancing rapidly, particularly for agentic workflows, code generation, reasoning, document understanding, and workflow automation.

For example, DeepSeek-V4-Flash-0731 introduces improvements in coding-agent performance, tool use, and workflow automation, making it well suited for AI assistants and agentic applications.

Similarly, NVIDIA Nemotron 3.5 Lightning is designed for agentic workloads with capabilities such as tool calling, long-context processing, multilingual support, structured outputs, and multi-step task execution.

One model, multiple deployment choices

As the model ecosystem grows, customers increasingly want flexibility in how they consume models.

With these launches, developers can access models through different pathways in Foundry depending on their requirements:

Direct from Azure

DeepSeek-V4-Flash-0731 builds on the previously available DeepSeek V4 Flash model with substantial improvements for agentic applications. Compared to the prior Flash release on Foundry, it delivers strong gains across coding, tool-use, and automation benchmarks, including a more than 7x improvement on DeepSWE (7.3 to 54.4) and a 21-point increase on Terminal Bench (61.8 to 82.7), helping developers build more capable coding agents and workflow automation solutions

Direct from Azure models are billed through your Azure subscription, covered by Azure service-level agreements, and supported by Microsoft.

Fireworks on Foundry

The same models are available through more than one path, so teams can pick the consumption model that fits the workload rather than the other way around. Fireworks deployments run inside your Foundry project with Azure governance and access controls, on pay-per-token or provisioned throughput. Start serverless while you evaluate, move to reserved capacity when traffic gets predictable. Same path brings your own fine-tuned weights (BYOM) into the same catalog and endpoint as everything else. Available through Fireworks on Foundry starting today:

• DeepSeek-V4-Flash-0731
• NVIDIA Nemotron 3.5 Lightning

Table: Fireworks on Foundry Models Pricing and Deployments*

* Global Provisioned deployments are billed at USD 1.00 per Provisioned Throughput Unit (PTU) per hour, and US Data Zone Provisioned deployments are billed at USD 1.10 per PTU per hour. Provisioned deployments are billed based on the number of deployed PTUs, rather than the number of tokens consumed.

Hugging Face collection on Foundry

NVIDIA Nemotron 3.5 Lightning is also available through the Hugging Face collection in Foundry, making the model compatible with managed compute. Developers can deploy it on dedicated GPU capacity with a Foundry-managed runtime, then choose the deployment template, accelerator family, and scaling behavior that fit their workload. This flexibility can help teams lower inference costs by aligning compute capacity and scaling with application demand rather than using a one-size-fits-all deployment.

Choosing the format that fits your workload

Many of the models that come in through our Hugging Face collection are optimized for specific hardware. NVIDIA Nemotron 3.5 Lightning comes in two different formats BF16 and NVFP4 allowing developers the ability to make an intentional tradeoff among customization, inference speed, memory use, hardware coverage, and model fidelity:

A unified experience for model evaluation and deployment

While the number of available models continues to grow, the developer experience shouldn't become more complicated.

Microsoft Foundry provides a single platform where teams can discover models, compare options, evaluate them against their own datasets, and deploy them with enterprise-grade governance and management capabilities. This allows developers to focus on finding the right model for their scenario rather than managing fragmented tooling.

Get started

Explore the latest additions in the Microsoft Foundry model catalog:

• DeepSeek-V4-Flash-0731 Direct from Azure and through Fireworks on Foundry
• NVIDIA Nemotron 3.5 Lightning through Fireworks on Foundry and Hugging Face collection on Foundry BF16 and NVFP4

As the open model ecosystem continues to evolve, Microsoft Foundry remains committed to providing customers with broad model choice, flexible deployment options, and the tools needed to move from experimentation to production.

Helpful resources:

Foundry Models sold by Azure - Microsoft Foundry | Microsoft Learn

Fireworks models on Microsoft Foundry - Microsoft Foundry | Microsoft Learn

Hugging Face models in Microsoft Foundry (preview) - Microsoft Foundry | Microsoft Learn

Many discussions about Microsoft Foundry Agent Service eventually arrive at the same question: should this workload be implemented as a Prompt Agent or a Hosted Agent? While the documentation explains both options well, the architectural decision usually comes down to something much simpler: where do you want the orchestration logic to live?

First, what actually makes something an agent? 

A basic AI assistant generates an answer. An agent can also decide what to do next, call tools, access data, maintain context and complete work across multiple steps. 

At the center of most agents are three building blocks: 

• Model: provides language understanding, generation, and reasoning. 

• Instructions: define the job, boundaries, role, and expected behaviour. 

• Tools: connect the agent to knowledge and actions such as search, APIs, databases, code execution, MCP servers or business systems. 

For enterprise use, that is only the starting point. You also need identity, authorization, network controls, content safety, session management, evaluation, tracing, versioning, rollback, and cost controls. Foundry Agent Service provides the surrounding platform capabilities, while letting you choose how much runtime logic your team owns. 

Where should orchestration logic live and who should own the runtime?

Understanding the Runtime Boundary

When evaluating Foundry Agent Service, many teams focus on models. In practice, models are rarely the architectural differentiator.

Most architecture reviews eventually come down to three questions:

• Who owns orchestration?
• Who owns state?
• Who owns operations?

Foundry Agent Service provides a managed platform for these concerns, but the amount of control retained by engineering teams depends on the selected agent type.

For most teams, the architectural decision usually comes down to one of two operating models

• Prompt agents: declarative agents defined by a model, instructions, and tools, with a managed runtime. 

• Hosted agents: code-based agents that you package and run in Foundry, while the service manages the endpoint, identity, scaling, sessions, and observability. 

Prompt Agents

With a Prompt Agent, engineering teams focus primarily on defining the model, instructions, tools, knowledge sources and identity configuration, while Foundry takes responsibility for the surrounding runtime.

Why teams start here 

Prompt agents are usually the fastest route from an idea to a working, governed agent. They are a good fit when the behaviour can be expressed clearly through instructions and supported tools. 

• You need to deliver quickly. 

• The agent follows a fairly straightforward reasoning and tool-use loop. 

• Foundry-supported tools cover the required integrations. 

• You do not need custom libraries, middleware, or orchestration code. 

• You want Foundry to own compute, scaling, and patching. 

• Reviewers need an agent definition that is easy to inspect. 

Good examples 

Enterprise knowledge assistant. Employees ask about policies, engineering standards, procedures, or product information. The agent retrieves approved content and cites its sources. 

Document review assistant. The agent checks a proposal or design against an approved rubric and returns structured findings, while a human keeps responsibility for the final decision. 

Employee self-service agent. The agent answers questions and performs a small number of tightly scoped actions, such as checking request status or creating a support case. 

A useful warning sign A Prompt agent is probably becoming the wrong fit when the prompt starts looking like application code. Large branching instructions, retry logic written in prose, state-machine behaviour, custom payload handling, framework middleware or real-time media are all signs that runtime logic belongs in code instead. 

Hosted Agents

Hosted Agents move the responsibility boundary. Instead of defining behaviour through configuration alone, engineers deploy an actual application into Foundry Agent Service. Hosted Agents are framework-agnostic. Whether your team builds with Agent Framework, LangGraph, Semantic Kernel, OpenAI Agents SDK, or a custom runtime, Foundry can host the application while managing the surrounding operational services.

When Hosted agents make sense 

• You need a particular agent framework or custom orchestration engine. 

• The flow includes branching, parallel work, fan-out and fan-in, or human approvals. 

• Business rules require a deterministic state machine around model reasoning. 

• You need custom packages, middleware, algorithms, retries, caching, or error handling. 

• The client sends custom payloads or webhooks. 

• The session needs persistent files or custom state. 

• The design includes multi-agent orchestration or real-time voice. 

Good examples

A bank onboarding workflow where uploaded documents must be validated, checked against multiple systems, and routed to a human when confidence drops below a threshold.

A fraud investigation agent that gathers transaction history, enriches data from multiple internal systems, applies bank-specific risk rules, requests additional evidence when required, and generates a recommended outcome for an investigator. The process involves long-running workflows, branching logic and audit requirements that are better suited to code-based orchestration.

A lending workflow that coordinates document collection, credit bureau checks, income verification, affordability assessments, policy exceptions, and approval routing. The process spans multiple systems and often requires deterministic decision paths that extend beyond prompt-driven orchestration.

A security operations agent that aggregates alerts from SIEM platforms, enriches incidents with threat intelligence, executes automated containment actions, opens tickets, requests approvals for high-impact remediation steps, and maintains a complete audit trail of decisions and actions.

The trade-off 

More control also means more ownership. Your team must secure and patch the code and dependencies, test the runtime, manage supply-chain risk, and think about compute sizing, cold starts, session lifecycle, and cost. Hosted agents reduce platform plumbing, but they do not remove application engineering. 

Choosing Prompt Agent/Hosted Agents 

A pattern I see quite often is teams arriving at the solution before they've fully articulated the requirement. The conversation usually starts with "We need a Hosted Agent," but after digging into the workload, the real requirements turn out to be things like persistent state, webhook processing, custom orchestration, background execution, framework-specific capabilities, or human approval workflows.

These are runtime concerns, not agent concerns and they're usually the factors that determine whether a Hosted Agent is necessary. Hosted Agents are valuable because they give engineering teams control over those aspects of execution while still offloading much of the operational infrastructure to Foundry.

This is also where teams most commonly choose the wrong agent type. A frequent assumption is that existing investments in frameworks such as LangGraph or Semantic Kernel automatically imply a Hosted Agent architecture. In practice, many of these workloads are relatively simple orchestration scenarios that can be implemented effectively as Prompt Agents, with lower operational overhead and less infrastructure to manage.

My advice is usually to start by identifying the runtime requirements rather than selecting an agent type. Once those requirements are clear, the right architecture often becomes obvious.

What I would choose today

Hosted agents in Foundry Agent Service - Microsoft Foundry | Microsoft Learn