Heat Agent Router

Heat Agent Router governs AI coding agents by routing tasks, enforcing policy, stopping unsafe execution, and producing cryptographic proof that its boundaries held.

Comment

Heat Agent Router

Inspiration

Heat Agent Router may have been this particular destination, but it was not the journey.

It started with me realizing that many of us are optimizing for the wrong things when it comes to LLMs. We try to make LLMs better authors, optimizing for single-shot correctness and adding hooks, rules, and conditions to make things behave the way we want. But I felt like this approach shifts correctness to the higher, more expensive end of the development cycle. In the SDLC and QA world, this is generally not what you do. I wanted to shift correctness and enforcement into cheaper, faster, more deterministic layers—for example, the compiler (Heat demos).

I wanted to guard against poisoned LLM context and state, debug doom loops, runaway subagent sprawl and cost, and repeated failures that produced no new learning (Hamingja).

I also found myself using excessive Codex and Claude quota because I would forget to downshift into less costly models for tasks that didn't demand cutting-edge frontier models. More complex still: if I have a $100 Codex plan budget and a $20 Claude plan budget, how do I correctly spread model usage across that particular configuration?

I needed a system and interface that combined all of these pieces into one coherent whole, giving me stronger assurances and safeguards at lower quota spend.

That is how I arrived at Heat Agent Router...

What it does

Heat Agent Router isn't another coding agent.

It's a governance layer that sits between agents and models, deciding what is allowed before work begins, validating what comes back, and recording evidence that can later be verified.

It:

  • Classifies work by capability and risk.
  • Selects reviewed model routes across providers.
  • Enforces context, cost, retry, tool, and capability limits.
  • Sends bounded prompt packets instead of uncontrolled conversation history.
  • Validates responses against explicit contracts.
  • Stops or escalates malformed, unsafe, or unsupported outcomes.
  • Records durable audit events, routing decisions, costs, and outcomes.

The goal isn't to replace coding agents.

It's to give them meaningful freedom inside explicit boundaries instead of unlimited authority.

Unknown, stale, malformed, or policy-conflicting inputs fail closed instead of silently falling back.

Don't trust the demo. Verify it.

Most security demos end with "trust me."

I wanted mine to end with "verify it yourself."

So for Build Week I built Sealed Execution Proof.

Heat creates a one-time operator canary and allows an authorized operation to produce a signed, input-bound receipt. A paired request attempting to reveal the same secret is denied.

An offline verifier independently checks the receipt, the audit trail, and every required control boundary.

The UI presents both runs side by side:

  1. The authorized operation succeeded.
  2. The disclosure request was stopped.
  3. The secret never appeared in Heat's tracked artifacts.
  4. Every claim can be independently verified.

The browser can even verify the operator's canary locally without sending it back to the server.

This isn't a universal claim that secrets can never leak through every possible system.

It's a precise, testable guarantee over Heat's bounded prompt packets, structured artifacts, audit trail, and execution boundaries.

If evidence is missing, modified, malformed, or incomplete, verification fails closed.

Challenges

The hardest problem wasn't proving something happened.

It was proving something didn't.

It's easy to show that an operation succeeded.

It's much harder to prove that a provider was never called, that execution stopped exactly where it should have, or that a secret never appeared anywhere Heat claims to track.

That forced me to rethink the entire architecture.

Explicit terminal events.

Hash-bound run stores.

Signed receipts.

Complete boundary coverage.

Verification rules that reject incomplete evidence instead of making assumptions.

The other challenge was turning rigorous audit data into something people could understand in seconds.

Raw logs contain the truth, but they force the operator to reconstruct it.

Heat instead projects already validated evidence, showing the conclusion first and letting reviewers drill into the proof behind it.

Finally, I wanted every layer to fail closed.

If Heat can't prove a claim, it refuses to make one.

How I built it

Heat separates governance from execution.

A Python runtime handles providers, credentials, tools, and durable storage.

Heat owns routing policy, typed contracts, validation, stop conditions, audit events, and outcome accounting.

The SvelteKit interface doesn't interpret raw logs. It presents validated evidence.

For Build Week I added:

  • OpenAI as the reviewed default execution path, with explicit local-model opt-in.
  • Policy-selected GPT-5.6 routes with bounded prompt packets and response contracts.
  • Intervention Proof, showing exactly which boundary fired, whether the provider was called, how many retries occurred, and whether anything executed after the terminal decision.
  • Sealed Execution Proof, including signed receipts, offline verification, browser-local witness challenges, and paired authorization/denial runs.
  • A deterministic judge path that reproduces the proof without requiring private credentials.

Throughout Build Week, I used Codex as an engineering collaborator: navigating the architecture, implementing bounded product slices, generating adversarial tests, reviewing failure paths, and hardening the Python, cryptographic, packaging, and UI boundaries.

GPT-5.6 generates candidate work through the same governed execution path demonstrated by the product.

What I learned

Before Heat, I thought the difficult problem was choosing the right model.

I don't anymore.

Choosing the model is the easy part.

The harder problem is deciding when an agent should be allowed to act, how much authority it should receive, and how someone else can verify that decision later.

Trustworthy AI isn't just about model capability.

It's about governance.

The moment Heat finally felt complete wasn't when the routing worked.

It was when I could put an authorized operation beside a denied disclosure request and let the evidence speak for itself.

What's next

Today Heat helps an individual developer govern AI agents.

The next step is expanding that into a team control plane: richer organizational policy, additional runtime integrations, shared audit views, stronger capability brokers, and outcome-driven model rankings.

Models will keep getting smarter.

I don't think that reduces the need for governance.

I think it makes governance one of the defining infrastructure problems of the AI era.

Heat is my attempt to solve that.

Built With

  • codex
Share this project:

Updates