We Didn't Train the AI. We Taught Our Tools to Explain Themselves.

We didn't fine-tune a model or write orchestration code. We gave each Vyges™ Loom engine a clear, typed, machine-readable interface — and an off-the-shelf GPT-4.1 model, connected through MCP, discovered the tools and drove the sign-off flow on its own. Orchestration became a property of the interfaces, not the intelligence of a particular model.

July 16, 2026 • By Shivaram Mysore

When I started taping out the Vyges™ Edge Sensor SoC, my goal was simple: I wanted a sign-off flow I could trust.

Like many engineers in the open silicon ecosystem, I relied on OpenSTA. It is an excellent foundation, but for the level of sign-off and optimization I wanted, there were capabilities I needed that simply weren't there. My original plan was modest: build a few missing pieces in Rust and augment the existing flow.

That plan didn't last long.

What began as a single Rust project gradually evolved into Vyges™ Loom — a shared architecture for sign-off and physical design optimization that now includes more than twenty engines covering timing analysis, characterization, parasitic extraction, DRC, LVS, optimization, and other sign-off tasks.

The technical challenge was exciting.

The developer experience challenge was much harder.

Twenty tools are harder to learn than one

Once the first dozen engines existed, I started asking a different set of questions:

  • How is someone supposed to know which tool to run?
  • Which engine comes first?
  • What inputs does it expect?
  • Which outputs feed the next stage?

I could certainly write documentation. Lots of documentation. But I've built developer tools long enough to know the uncomfortable truth:

Most people don't read documentation until after they're stuck.

Adding more tools would only make that problem worse.

A different idea

Around the same time, the Model Context Protocol (MCP) was gaining traction.

Instead of writing an "AI assistant" trained specifically for Loom, we tried something much simpler.

Every Loom engine already had a well-defined contract:

  • structured inputs
  • structured outputs
  • machine-readable descriptions

What if we simply exposed those contracts through MCP?

  • No prompt engineering.
  • No custom orchestration code.
  • No fine-tuning.
  • No semiconductor-specific training.

The model would discover the tools the same way a developer would. If the interfaces were good enough, perhaps the model could figure out how to orchestrate them on its own.

To our surprise, it worked.

The model correctly identified the available engines, selected the appropriate ones, chained them together, interpreted the results, and drove the workflow without ever being trained on Loom.

  • We didn't teach the model semiconductor design.
  • We taught our tools to describe themselves.

That experience eventually became the foundation for our paper, "Deterministic Core, Agent Tail", which argues that AI should plan while deterministic tools compute and verify.

Making it reproducible

There was still one problem.

When I travel to conferences, customer meetings, or workshops,

  • I can't depend on having a carefully prepared development environment.
  • Live demos are notoriously fragile.
  • A single missing dependency, a network hiccup, or an outdated installation can derail an otherwise great demonstration.

So we asked ourselves another question:

  • What if anyone could watch the entire experience — from installation through orchestration — using a completely fresh environment?

The result is the Vyges™ Loom Testbench. Every demonstration starts from a brand-new instance. The environment installs Loom from scratch, connects a standard GitHub-hosted GPT-4.1 model through MCP, discovers the available tools, and executes the workflow live.

  • No pre-training.
  • No hidden prompts.
  • No cached state.
  • No custom model.
  • Just a deterministic toolchain exposing its capabilities through standard interfaces and an off-the-shelf language model orchestrating them.

That's exactly the developer experience we wanted to build.

And you don't have to take my word for it — you can watch it happen. The Vyges™ Loom Testbench dashboard runs the whole thing in a clean cloud runner: Loom is installed from scratch, a stock GitHub-hosted GPT-4.1 model is pointed at the engines through vyges mcp, and each engine lights up as the model picks it, forms its arguments, runs it, and reads back the engine's own real sign-off result — timing met, IR-drop OK, LVS match, and so on. No pre-training, no hidden prompts, no cached state.

The bigger lesson

This project taught me something I wasn't expecting. We often ask how to train AI to use our software. Perhaps that's the wrong question. Maybe we should spend less effort teaching models about our tools and more effort teaching our tools to explain themselves. If every engineering tool exposes clear, typed, machine-readable interfaces, then orchestration becomes a property of the interfaces — not the intelligence of a particular model.

That also means today's model isn't special. Tomorrow's model should work too. And the one after that. That's a much more durable architecture.

See it at DAC 2026

I'll be presenting these ideas during the DAC 2026 Open Source EDA Birds of a Feather (BoF) session, including a live demonstration of MCP-driven orchestration using a completely fresh installation of Vyges Loom.

If you're interested in open-source EDA, agentic workflows, or what practical AI integration looks like for deterministic engineering tools, I'd love to meet you there.

Learn more