Quick answer
LFM2.5-2.6B has a provider-documented tool-calling protocol:
- provide tool definitions;
- let the model propose a function call;
- validate and execute the call in the host application;
- return the result with the tool role;
- let the model form a final answer.
The official model card says the default call representation is Python-like and can be requested as JSON in the system prompt. Use tokenizer.apply_chat_template(..., tools=...) where the supported runtime implements the official template. Do not parse arbitrary model text with eval or treat a syntactically valid call as authorized.
Separate proposal from authority
| Layer | Responsibility |
|---|---|
| Model | Propose a tool and arguments; interpret returned data |
| Parser | Accept only the documented call envelope and schema |
| Policy | Decide whether the user, purpose, resource, and action are allowed |
| Executor | Apply timeouts, idempotency, rate and spend limits, and cancellation |
| Approval | Confirm destructive, external, financial, permission, or irreversible actions |
| Audit | Record source, model revision, prompt, call, decision, result, and final answer |
An authenticated tool is not blanket authorization. Split read, draft, and commit operations; scope credentials to the minimum resources; and re-approve when the resource, destination, purpose, audience, or spend changes.
Build a replay suite
Test at least these cases:
- correct tool and arguments;
- no tool needed;
- ambiguous user intent;
- missing or malformed arguments;
- unavailable, slow, or failing tool;
- duplicate delivery and retry;
- permission denial;
- prompt injection inside retrieved or tool-returned content;
- conflicting results;
- material action requiring confirmation;
- user cancellation before and during execution;
- final answer that must distinguish observed result from model inference.
Score call selection, argument correctness, policy compliance, false success, recovery, refusal quality, final grounding, latency, and intervention rate. A benchmark or provider harness-training claim does not replace this application-specific evaluation.
Harness compatibility boundary
Liquid AI says the model was trained inside agent harnesses such as Hermes Agent, OpenClaw, and Pi. Treat named harnesses as a training and compatibility signal, not a guarantee for every current release or extension. Pin the harness version and retest after model, template, parser, tool, policy, or prompt changes.
Use the Base versus post-trained guide before considering custom training and the device guide when the harness and tools share a constrained device.
Frequently asked questions
How does LFM2.5-2.6B tool calling work?
Liquid AI documents four core stages: supply tool definitions, let the model propose a call, execute the call in the host application, and return the tool result so the model can produce a final answer.
Does the model execute tools by itself?
No. The model emits a tool-call representation. The harness must validate, authorize, execute, observe, retry or stop, and return the result.
Which agent harnesses trained LFM2.5-2.6B?
Liquid AI’s current documentation names Hermes Agent, OpenClaw, and Pi as example harnesses used in its training record. That does not prove compatibility with every version, plugin, tool, or production policy.
Official sources
- LiquidAI LFM2.5-2.6B model card and tool protocol
- Liquid LFM2.5-2.6B agent documentation
- Liquid tool-use documentation
Source check: August 5, 2026. Verify the exact model, tokenizer, template, runtime, harness, parser, permissions, and tool versions before use.