Inspiration

Would you trust an AI-recommended component enough to put it on a circuit board?

I wanted to build a system where a convincing explanation wasn’t enough. The agent would have to propose a change, test it, inspect the results and decide what to try next.

That became Second Source: a regulator replacement investigator with a simple rule, the AI does not get to mark its own answer as correct.

What it does

Second Source investigates replacements for a 3.3 V sensor-board regulator.

You enter the board’s input-voltage range, load, voltage tolerance and thermal assumptions. You also decide whether the agent can change the output capacitor or consider a different package.

NVIDIA Nemotron, running through Nebius Token Factory, proposes an experiment. ngspice simulates the circuit, and separate evaluator code checks the results. Nemotron receives that feedback and can revise its proposal or explain why it has stopped.

Changing a requirement starts a fresh investigation. Previous results do not automatically carry over as valid.

A result that explains the project

In one live investigation at 400 mA, Nemotron proposed AP2112K-3.3 with a 100 µF output capacitor.

It almost worked.

The simulated output reached 3.4708 V. The permitted ceiling was 3.465 V, a difference of about 5.8 mV. The evaluator rejected it.

Nemotron then cited that measured overshoot and proposed 220 µF. Fresh simulations produced an output range of 3.222–3.355 V, and the candidate passed all six implemented checks.

That investigation completed 54 SPICE tests across the original circuit and five AI proposals.

I also increased the required load to 800 mA. In a separate live run, the agent stopped after reviewing the original circuit’s failures: the eligible regulator exceeded the thermal limit, and the other catalog parts could not meet the current requirement. Increasing the capacitor would not solve the thermal problem.

Both outcomes matter. Sometimes the useful answer is a tested candidate. Sometimes it is a clear explanation of why the available options are unsuitable.

How I built it

The interface uses JavaScript, HTML and CSS, hosted on Cloudflare Pages.

The planning model is NVIDIA Nemotron 3 Super, served through Nebius Token Factory using nvidia/nemotron-3-super-120b-a12b. Token Factory let me build and test the inference loop without deploying model weights or managing a GPU server.

The circuit simulations run in the browser. I used ngspice 45.2 through the EEcircuit WebAssembly engine, with a Web Worker keeping simulation work off the main interface thread.

Each proposed design is tested at three input voltages. With the assumption sweep enabled, three control-response profiles bring that to nine simulations per proposal.

The evaluator checks:

  • Simulated output-voltage envelope
  • Rated output current
  • Input operating range
  • Estimated junction temperature
  • Minimum output capacitance
  • Specified DC accuracy budget

The agent can choose experiments, but it cannot lower the requested load, relax the limits or supply its own passing verdict.

Run exports retain the requirements, proposals, measurements, netlists and hashes, evaluator results, and available Nebius request metadata.

What was difficult

The early agent behavior was not always good.

It sometimes gave up before trying another permitted capacitor value. In another run, it proposed a regulator rated for less current than the board required. It also spent experiments trying to improve voltage behavior when a thermal failure would still prevent the design from passing.

Those failures shaped the implementation. I added current-rating screening, clearer thermal guidance and an explicit experiment budget. The application now distinguishes an agent decision to stop from a search that simply ran out of experiments.

Deployment brought its own problems. The simulator’s embedded WebAssembly did not load under the site’s content security policy, so I moved it into a separate same-origin asset. Model-format errors and provider failures also needed explicit handling so an interrupted run would preserve its evidence without inventing a result.

What I learned

The most useful part of an agent system is often what happens after its first answer fails.

Giving the model measured feedback helped, but it also needed clear permissions, a bounded search and checks it could not override. Keeping unsuccessful runs made it much easier to see whether a change actually improved the system.

I also learned to treat stopping as a real outcome. “No tested design passed,” “the agent stopped,” and “the search budget was exhausted” mean different things.

Current limitations

This is a focused prototype with three catalog regulators: LM1117-3.3, MCP1700-3302 and AP2112K-3.3.

It uses simplified, lab-authored behavioral models, not manufacturer transistor-level models. Junction temperatures are estimates based on user-supplied board assumptions.

A passing result means the candidate passed the implemented modeled checks. It does not establish pin compatibility, PCB suitability, stability, startup behavior, noise performance or hardware reliability. Stock and prices are not checked.

The exported hashes support reproduction; they are not tamper-proof attestation.

What’s next

The next step is stronger model validation against manufacturer references and physical measurements. I also want to improve how the agent distinguishes sustained dropout from transient voltage excursions.

After that, I would expand the catalog where reliable model evidence is available.

Second Source currently has 27 passing automated tests, a public demo and an open-source repository. The goal is to make every recommendation easier to inspect, challenge and reproduce before anyone considers using it on hardware.

Built With

Share this project:

Updates

Submission history