Skip to content

Build1 publisher2 min readPublished

Reactive Agents repairs the almost-right tool call so the run keeps going

The MIT-licensed TypeScript framework at v0.16 exposes seven named run phases with hooks on each side, and its case for harness over model rests on one incident-triage run that a 4B local model and Claude both finished.

The Engineer · Build desk

Illustration accompanying Reactive Agents repairs the almost-right tool call so the run keeps going

What happened

  • Reactive Agents shipped v0.16 as an MIT-licensed open source TypeScript agent framework, built on the premise that the engineering around the model is what makes an agent reliable.
  • Its builder turns on exactly one thing per .with() call: memory writes wait for .withMemory(), guardrail scanning has to be asked for, and there is no hidden system prompt.
  • The post reports that swapping the provider and model lines to a local qwen3:4b run produced the same investigation as claude-sonnet-4-6, down to the same rollback recommendation.
  • The runtime is Effect-TS. A failed tool call or a provider timeout becomes a typed value in an explicit error channel.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • capability Prompt and tool work can be developed against a model running on a laptop at no API spend. When a task needs the extra reasoning, a two-line change points it at the frontier model.
  • contradiction The post concedes the 4B model is less capable while claiming the harness finishes the loop whichever model is behind it. One triage walkthrough cannot show which limit a given workload hits first.
  • cost Effect-TS lands in your dependency tree for the sake of the error channel even though none of your own code is Effect. The people on call inherit stack traces through a runtime they did not choose to learn.
  • constraint Repair happens ahead of the tool. Anyone scoring a model on tool-call success is scoring the harness with it, and the after-act hook is the documented place to see what the tool actually received.

The FC-dialect probe is the part that makes the one-line model swap work. It picks native function calling where a provider supports it, and falls back to a tiered text-parsing driver where it does not. The dev.to post calls that "the actual reason a small open model and Claude can share one code path at all" [11].

Two layers sit on top of it. Model-adaptive context profiles tune prompt density and compaction per model tier, on the reasoning that a small model drowns in the same verbose prompt a frontier model handles easily [9]. A healing pipeline sits in front of every tool call and repairs the almost-right ones: a tool name off by a naming convention, a parameter sent under an alias, a malformed path. The call gets repaired and runs [10]. Those three failure modes are what you get when a call is parsed out of prose, so the probe and the healing layer are handling one weakness at two points.

The comparison on offer is a single incident. In both configurations the agent calls the health and recent-deploys tools, ties a degraded error rate to a deploy from twelve minutes ago, and recommends a rollback [6]. The post does not report a pass rate or a repeat count, and does not say how often the healing pipeline fires [17]. It is direct about the capability gap: "A 4B local model is obviously not as capable as Claude, and nobody working on this framework would tell you otherwise," the post said [7].

For that result to transfer, your tools would have to resemble those two. Both are read-only. Both are cheap to call twice. The conclusion is one hop from the evidence, because a deploy twelve minutes old is a strong signal in a short context [6]. Put a write tool, six services and two disagreeing metrics in the same loop, and the claim I would test first is that the harness finishes the loop regardless of which model is behind it [8].

The control claim gets concrete in the phase list. A run moves through bootstrap, guardrail, cost-route, think, act, observe and verify, continuing through termination, and every phase exposes hooks before and after it runs [12]. Seven named phases at two timings each is fourteen interception points before you write any provider code [16]. The example hook fires after the act phase, reads ctx.toolResults.at(-1), and logs the tool name [13].

The comment on the ollama line in the builder reads "your laptop, $0" [5]. That figure prices the API calls; the afternoon spent on prompt density sits outside it.

What to watch

  • Whether a later release publishes repeated runs with pass rates and healing-repair counts.
  • Whether each repair the healing pipeline makes is logged, since a silent rewrite changes what a tool-call success rate measures.
  • Whether the model-adaptive context profiles are documented per tier, so you can see which prompt density a given model gets.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories