The Smallest Useful Agent Is a Decision Model

Oct 7, 2026 7 min read

The next important agent model may not be the one writing the answer.

It may be the small model deciding whether an answer is needed at all.

Liquid AI announced Open d1, a pair of open-weight multimodal decision models. The release includes d1-3B, which handles text and vision, and d1-omni-600M, which handles text plus image or audio. Liquid says both are intended to run from data center hardware down to RTX workstations and Jetson devices.

That sounds like another open model release. It is more interesting than that.

The release points toward a different agent architecture: a large model does not need to sit in the middle of every decision. A smaller model can classify intent, inspect a frame, choose a route, or reject an action before the expensive reasoning loop starts.

The model is not the whole agent. It is a control surface inside one.

Open d1 is aimed at the decision layer

Liquid describes d1 as a decision model family rather than a general chat model. In the launch thread, the company positions d1-3B for reranking, agent guardrails, and visual inspection. It positions d1-omni-600M for voice-command routing, on-device moderation, and intent classification.

That distinction matters.

A generative model returns a sequence of tokens. A decision model can return a typed choice that software acts on directly:

input: user request + current state + available tools
output: { route: "local", risk: "low", action: "inspect" }

The exact interface is an implementation choice, not a claim about Liquid’s API. The architectural pattern is the important part. The model sits beside the control loop, not at the end of a chat transcript.

Liquid’s announcement says d1-3B is built from LFM2.5-VL-3B and makes decisions from text and images in one pass. The company also says d1-omni-600M combines a 350M encoder with vision and audio encoders. Those are small footprints for systems that need to react continuously to cameras, microphones, or tool events.

This is not a claim that a 600M model replaces a frontier model. It is a claim that many agent decisions do not require one.

The useful comparison is not model versus model

The usual open model discussion asks which checkpoint is strongest. That is the wrong comparison for this layer.

The relevant question is which model belongs at which point in the loop.

Agent job	Reasonable model shape	Why it belongs there
Wake word, intent, or policy precheck	Small decision model	Fast, cheap, and local
Image or audio triage	Multimodal decision model	Converts raw input into a route or action candidate
Tool selection	Decision model plus policy	Narrows the available action space before execution
Long planning and synthesis	Larger generative model	Spends compute where context and reasoning matter
Final approval for high impact actions	Independent verifier or human	Keeps the acting model outside the trust boundary

This is model routing as systems design, not model shopping.

A small local model can answer questions such as:

Is this input relevant enough to wake the main agent?
Does this image contain a condition that needs inspection?
Is the requested tool within the user’s policy?
Should this request stay on the device, go to a hosted model, or be rejected?
Is the agent’s proposed action ordinary, suspicious, or unclear?

Each decision can prevent a more expensive call. More importantly, each decision can happen before a powerful model receives secrets or gains access to tools.

That makes routing part of the security boundary.

Edge deployment changes the control loop

Liquid says the two Open d1 models have day one llama.cpp support and can run across NVIDIA DGX, RTX, and Jetson hardware. The launch thread reports single question latency for d1-3B of 8 ms on an RTX 4090, 16 ms on a Jetson AGX Thor, 26 ms on a Jetson AGX Orin 64 GB, and 50 ms on a Jetson Orin Nano.

Those are Liquid’s reported figures, not an independent benchmark. The thread does not establish a universal latency guarantee, and the measurement conditions are not a substitute for testing a target device with a real input stream.

The direction is still clear.

When the decision model runs next to the sensor or tool loop, the agent does not need to send every event to a remote API. A camera can be filtered locally. A voice command can be classified locally. A tool request can be routed locally before a larger model sees it.

That reduces round trips, but latency is only half the story. Local execution also reduces the number of places where raw inputs, credentials, and intermediate decisions travel.

The uncomfortable truth is that moving a model on device does not make the system safe. It makes the control loop more immediate. If the local model is wrong, the device can make the wrong decision faster and with less observability.

Open weights do not create an approval gate

Open weights are useful because operators can inspect, fine-tune, quantize, and deploy without depending on a hosted endpoint. Liquid explicitly tells users to download the weights, fine-tune them, and deploy locally.

That is control over the artifact. It is not control over the outcome.

A decision model used for guardrails still needs a policy around it. The model’s output should be treated as a recommendation or a bounded classification, not as permission to perform an irreversible action. The system around it should record the input, model version, policy version, decision, and downstream effect.

A safe control loop looks more like this:

observe
  -> local decision model
  -> policy evaluation
  -> capability-scoped tool
  -> execution
  -> independent observation
  -> audit record

The decision model can narrow the path. It cannot be the only thing that authorizes the path.

This matters especially for the uses Liquid names in its announcement. Reranking, moderation, intent classification, and agent guardrails all sound low risk until their outputs control access to a tool, a person, a payment, or a physical system.

The model should be small enough to run locally. The approval boundary should be strong enough to survive a bad prediction.

The gotcha is observability

The obvious failure mode is latency. The less obvious one is silent routing.

A large conversational model produces a visible answer. A small decision model often produces a label, score, or route that disappears into the machinery. If that decision is wrong, the failure may show up much later as a tool error, a missing alert, or an agent run that chose the wrong branch.

Operators need to make the invisible layer inspectable.

At minimum, log:

the exact model and quantization used
the input modalities and preprocessing path
the decision and confidence, if exposed
the policy version that interpreted the decision
the tool or model route selected
the eventual result and any override

Do not log sensitive raw media by default. Store a reference, a redacted representation, or a bounded digest when that is enough to reproduce the decision path.

The release makes edge deployment easier. It does not remove the need for a trace.

What builders should do now

If you are building an agent, stop sending every event to the largest model available.

First, identify the decisions that are repetitive, local, and bounded. Examples include intent routing, input filtering, tool eligibility, and simple visual inspection. Measure how often those decisions are made, how costly a mistake is, and whether the decision requires broad context.

Then put a small model behind a narrow interface. Do not give it arbitrary tool access. Give it a finite output schema, validate that schema, and make the policy layer explicit.

Finally, compare the full loop, not just model latency. Count remote calls avoided, secrets exposed, retries triggered, false positives, false negatives, and human overrides. A fast classifier that causes expensive downstream recovery is not a fast system.

The model you route around may matter more than the model you route to

Open d1 is notable because it treats decision-making as a deployable model category, not merely a hidden prompt inside a larger agent.

That creates a better division of labor. Small models handle the repeated decisions close to the data. Larger models handle the ambiguous work that needs context. Policies and verifiers decide what either model is allowed to cause.

The winning agent architecture will not be the one with the biggest model in every loop.

It will be the one that spends intelligence selectively, keeps the first decision close to the event, and never confuses a model output with an approval boundary.