Field notes from European Microwave Week 2026, London.
Keysight's "Design with Agentic AI" corner at EuMW 2026 showed an AI agent working inside Keysight ADS, the RF circuit simulator. A chat request asked for two terminals and two transmission lines. The agent built the schematic, configured an S-parameter simulation and reported back: "Completed 6 steps." That alone is a reasonable demo. The more instructive part was on the screen next to it: the instruction file that teaches the agent how to use ADS. Line 13 of that file contains one of the most honest sentences I saw at the show.
What the agent was given
The file, ads-filter.md, describes its own purpose: design an RF filter in ADS via the "ads-de MCP", simulate it, and plot the results inline. It then explains that everything runs through a single tool that executes Python in the ADS console. There is no dedicated "create schematic", "run sim" or "plot" tool. Then comes the key passage, paraphrased: several API calls listed in an earlier draft of the instructions came from an unverified version and do not match the real API. The agent is told to use the patterns below them instead, all of which "were exercised end-to-end against a live ADS session".
In other words, the first version of the agent's instructions contained API calls that did not exist, and somebody had to find that out by running them against real software.
Why that sentence matters
Anyone who has used a language model to write instrument or EDA scripts knows this failure mode. The model produces code that looks entirely plausible: correct naming style, sensible arguments, credible method names. Some of those methods simply do not exist. In a general programming language, the error appears at the first run. In a niche scripting API, like an EDA tool's internal Python interface, the model has seen far less training data, and plausible-but-wrong calls are much more likely.
The remedy shown here is the right one: validate the agent's tool knowledge against the live system, then write only the verified patterns into its instructions. The instruction file becomes a tested interface specification, not a guess. That is ordinary software engineering discipline applied to agent instructions, and it is exactly what makes an agent reliable in a domain-specific tool.
A known-answer first circuit
The circuit the agent built was deliberately trivial. The design was named "KuBand_SParam_Thru" and contained:
- two 50 Ω terminals;
- two ideal transmission lines (TLIN), each Z = 50 Ω, E = 90° at F = 14 GHz;
- an S-parameter sweep from 10 to 18 GHz in 100 MHz steps.
The expected result is obvious to any RF engineer. Two cascaded 50 Ω lines between 50 Ω terminals form a matched, lossless thru: |S21| = 0 dB across the band, S11 ideally zero, and an S21 phase of −180° at 14 GHz that falls linearly with frequency.
That makes it a good first test, not a weak one. When you introduce automation, whether a script, a macro or an agent, start with a circuit whose answer you already know. If the agent's result does not match the hand calculation, the problem lies in the toolchain, not in the design. Only after the known-answer case passes is it worth asking the agent for a real filter.
The wider picture: surrogates and lifecycle
The laptop below the display showed a presentation slide titled "Creation and Lifecycle of Surrogates can be Streamlined". It described an enterprise pipeline in which parameterised layouts of filters, matching networks and components are simulated in batches, and the results are aggregated into surrogate models, all orchestrated from Keysight's SOS AI environment. That is the other half of AI in RF design: fast models trained on many simulations, so that optimisation does not need a full EM solve at every step.
Nearby, a support-portal screen showed an "Ask AI" conversational search for documentation, calibration and service questions. Taken together, the three stations covered three different jobs: agents operating the tool, surrogates speeding up the physics, and assistants answering questions.
A checklist for putting an agent into an EDA or instrument workflow
- Verify every API call against the live tool before it goes into the agent's instructions.
- Write down explicitly what does not exist, as this file did. Negative instructions prevent repeated mistakes.
- Start with a known-answer circuit, such as a thru, a quarter-wave line or a simple RC network.
- Check the result against a hand calculation before moving on to real designs.
- Keep the instruction file under version control, because it is now part of the toolchain.
Takeaway
The demo showed an agent that can drive a professional RF design tool. Its instruction file showed what that took: discovering which API calls the model had invented, and replacing them with patterns tested against a live session. For RF engineers, the lesson transfers directly. Treat an agent like any new instrument in the lab. Calibrate it against something you already know before you trust it with something you do not.
Notes: Observations and interpretations are my own, based on what was running at the booth during the show. Text from the instruction file is paraphrased, with short phrases quoted, from my photos. The full content of the file and the details of the MCP integration were not confirmed with the exhibitor.