A lot of vendors talk about agentic capabilities. Far fewer are willing to show the agent actually working, live, with no pre-recorded safety net. In this webinar in JuliaHub's ongoing webinar series, we did exactly that, building and refining a circuit model in Dyad Studio from start to finish, live, using the Dyad agent.

Why an Engineering Agent Is Not the Same as a Coding Agent

The session opened with a distinction worth making: connecting a general-purpose coding agent to an MCP server is not the same thing as having a dedicated engineering agent. Coding agents have gotten remarkably good at writing and reviewing software — genuinely impressive relative to where the field was even a couple of years ago. But that skill set doesn't automatically transfer to reasoning about physical systems.

The analogy offered was simple: if your air conditioner breaks, you don't call a software engineer. Software is not hardware. What separates an engineering agent from a coding agent is the harness,  the layer of process, guardrails, and domain knowledge wrapped around the underlying model. The Dyad agent runs on Claude, but with a harness purpose-built around the actual process of engineering rather than general software development, and one that JuliaHub says it continues to revise.

Two supporting principles came up early and shaped the rest of the demo:

• Agents need feedback loops. A task on its own isn't enough — an agent needs some way to check whether it got the answer right, not just whether the output looks plausible.

• Specificity pays off. The more detail and planning that goes into a request, the less iteration is needed to land on the right result. Vague prompts lead to more back-and-forth.

• Verification.  Verification is already a part of engineering workflows, so it should absolutely be included in the feedback loop of the agent.

The Demo: Building an RLC Circuit From an Underspecified Request

Rather than opening with a fully detailed spec, the demo began with a deliberately vague prompt: build a simple RLC circuit, and ask what specifics are needed first. The agent responded with exactly the questions an engineer would expect — circuit topology, signal source, component values, initial conditions, what to observe, and how long the simulation should run.

The follow-up prompt filled in the requirements, but stopped short of giving raw component values. Instead, it specified a resistor in series with a parallel inductor-capacitor pair, driven by a step voltage, with a target natural frequency of 3 Hz and a damping ratio of 0.7, starting from equilibrium with a 24V step at 0.5 seconds.

That's a set of engineering requirements, not a parts list — and the agent had to derive the actual resistance, inductance, and capacitance values itself. Working through its exposed reasoning, it solved the natural-frequency and damping-ratio equations, selected a sensible value for the one remaining degree of freedom, built the model, and ran a transient simulation. It then validated its own result: it correctly determined that capacitor voltage and inductor current needed to start at zero at equilibrium — a detail that was never stated explicitly in the prompt. That's the kind of engineering judgment the session was framed around: understanding what "equilibrium" implies for this specific system, not just parsing the sentence containing the word.

Reproducible Artifacts, Not Just One-Off Outputs

Once the model was built, the agent could generate a plot of the capacitor voltage and inductor current directly. Instead, the demo took a different path: asking the agent to write a standalone Julia script that produces the plot, rather than generating the plot itself each time.

The reasoning: repeatedly asking an agent to remake the same chart burns tokens and doesn't build understanding, and it risks inconsistency between runs — different colors, different legend placement, and so on. A script, by contrast, is a deterministic, reusable artifact. It can be run independently of the agent, version-controlled, and understood line by line — reinforcing a broader point about not offloading comprehension along with labor.  The fact that Dyad comes with Julia means we don’t need to install any additional tools and neither do the users of the models and artifacts we create.

Interpreting Intent, Not Just Instructions

The demo then pushed the agent further: modify the component values so the response shows three clearly visible oscillations and a peak capacitor voltage of 5V, and regenerate the plot — again, without specifying a damping ratio or component values directly.

The agent lowered the damping ratio (to roughly 0.125) while holding the natural frequency fixed at 3 Hz, adjusted the model, corrected an error along the way, and returned a plot matching the requested behavior. The underlying takeaway: the agent was translating a description of desired system behavior into the engineering parameters that produce it, rather than requiring the parameters to be specified up front.

One File, Not Two: Text and Diagram as a Single Source of Truth

An audience question asked why use Dyad Studio rather than a terminal-based coding agent. Part of the answer is architectural: in Dyad, the graphical circuit diagram and the underlying text file are the same artifact, not two things that need to be kept in sync. Components can be edited graphically or as text, and either approach updates the same file. That single source of truth is what makes standard software practices — version control, diffing, branching, and collaboration (including with the agent itself) — work cleanly on physical models.

Q&A Highlights

Participants in the webinar had some interesting questions about agent-assisted engineering, the deployment, access, conservation of laws etc.

• Deployment and export: Dyad compiles to Julia and supports FMU export. Source-code export currently applies to synchronous, embedded-code-style programs; models involving differential-algebraic or nonlinear equations still run through the Julia ecosystem.

• Documentation access: The agent's documentation is deliberately kept local rather than pulled from the open web, so it can't reference outdated or inconsistent sources. Public documentation exists separately for human use.

• Conservation laws and pricing tiers: Conservation of energy, mass, and similar physical quantities is a property of the acausal modeling formulation itself, not something gated behind a paid tier. The AI layer adds its own checks on top, most relevant when building custom component libraries outside the standard ones.

• Extensibility: As of Dyad Agent 3.0, projects can include custom skills and a persistent context file, allowing teams to encode their own conventions or processes for the agent to follow.

• Domain extrapolation: The general approach was described as likely to extend reasonably well to adjacent domains like systems biology, though the modeling conventions in that space differ enough to warrant separate treatment.

What's Next?

This webinar continues JuliaHub's broader series on Dyad and agentic engineering. Future sessions in the series will go deeper into how the Dyad agent supports post-processing, test construction, and more complex multi-domain analyses.

Watch the full webinar video.