LFM2.5-24B-A2B Agent Guide: Local Setup, Tools and Context Planning

LFM2.5-24B-A2B is a candidate for developers who want a local agent with a modest active computation budget and a longer document context. The first useful evaluation is a small tool-assisted task: retrieve a passage, return a cited answer and stop. Adding filesystem writes before that loop works makes failures harder to diagnose.

This guide covers weight memory, local serving, tool execution and context planning. The workflow below is an evaluation proposal, not a claim that we ran the model or reproduced Liquid AI's benchmark results.

Confirm the LFM2.5 checkpoint and format

Liquid AI's model card names LiquidAI/LFM2.5-24B-A2B, specifies 131,072 tokens of context, and links a GGUF package for compatible local runtimes. Its tool-use instructions describe formatting tool definitions through the chat template. The release has a custom license linked from the card. Official model card.

Do not substitute the older LFM2-24B-A2B checkpoint while keeping the new context setting. Save the exact repository, revision, tokenizer and weight format together. Tokenization and conversation formatting belong to the deployed model, not merely to the agent framework around it.

The official documentation lists several inference choices. Select the path your existing environment can support, then pin its working version. A runtime described as compatible today may need a recent implementation of this architecture. Liquid AI inference documentation.

Budget storage, resident weights and context separately

Two billion active parameters does not mean a two-billion-parameter checkpoint. A local deployment still needs to handle the larger weight set, the chosen quantization and allocations outside the routed layers. List those costs separately before deciding whether the model fits a laptop or server.

Start with a short context even if the model advertises a much larger limit. Your users may need only a handful of relevant passages. Filling the window with an entire archive can raise resource use and make it harder to see whether the answer came from the right source.

A useful deployment record includes available memory before loading, memory after loading, peak memory during generation and elapsed time for a complete task. Repeat a request after several turns. A model that loads successfully can still fail once context and concurrent requests grow.

For GGUF, record the quantization name and the runtime build. Compare a small correctness set after changing either one. If the model begins emitting malformed tool arguments, inspect the template and runtime before assuming the quantization caused the problem.

Give the agent one read-only tool first

Define a document lookup tool with a narrow input, such as a search phrase and a maximum number of results. Return passage text with a stable source identifier. Avoid passing a shell tool that can do anything when the task only needs to search a local manual.

The agent loop should validate the proposed tool call before execution. Check that the tool exists, arguments match your schema and limits are respected. After execution, attach the result as a tool response and let the model produce the final answer. Treat malformed arguments as a failed step with a visible reason.

For an initial test, use a fictional support manual you wrote yourself. Ask a question answered in one section, a question requiring two sections, and a question with no answer. A useful agent should cite the first two and express the missing evidence in the third.

Keep tool calls in a separate event log. The final response can appear correct even if the agent made unnecessary calls or retrieved an unrelated passage first. Reviewing the sequence reveals those costs and gives you concrete cases to improve.

Make long context a measured application feature

Build context tests around your task rather than a token-count milestone. Place a relevant policy passage near the beginning of one document and an exception later. Ask for the policy with its exception, then change their positions. Score whether the answer includes both and cites the right locations.

Increase document length gradually with irrelevant material. Preserve the same question and expected answer. This can reveal where the complete application becomes unreliable even though the input remains below the advertised limit.

These are recommended evaluation cases. Record actual token counts using the deployed tokenizer, along with the prompt and tool outputs. Character counts and document page counts are rough planning aids, not equivalent context measurements.

Add write actions only after the read loop passes

If the next task is to update a ticket, make that action a separate tool with a precise target and a proposed change. Present the change for review in your own application before execution. This keeps an incorrect answer from immediately altering a business record.

Use a small action budget and a stop condition. For example, a support lookup may need a search and one follow-up retrieval, then a final answer. If the model keeps searching after it has adequate evidence, inspect the stopping prompt and tool responses rather than raising the budget indefinitely.

License review, local serving cost and operational ownership remain part of deployment planning. A downloaded model has no per-request vendor invoice, but hardware, maintenance and review still consume resources.

Worked agent: answering a policy question from a local manual

Consider a hypothetical operations assistant that answers questions from an internal manual. Create a synthetic manual with a current expense policy, a superseded policy and an exception for one fictional department. Mark the versions and effective dates clearly. This lets you test evidence selection without using confidential business material.

The user asks whether a particular fictional purchase needs approval. Your lookup tool returns passages with source identifiers and version labels. The expected answer should state the current rule, explain whether the exception applies and cite the relevant passages. A fluent answer based on the superseded policy fails the task.

Keep the tool's result compact. Return the useful passage plus enough surrounding text to interpret it, rather than the entire manual after every search. If the agent requests a second passage, record why that retrieval was necessary. This makes the cost of reasoning through an exception visible in the event trace.

Add a case in which the manual never mentions the purchase category. The final answer should identify the missing rule and avoid fabricating an approval decision. For a business assistant, knowing when the evidence is incomplete is part of correctness, not a failure to be helpful.

Then test a follow-up question: “What changes if the purchase is for the other department?” The application should preserve relevant context while allowing the new condition to change the answer. Inspect whether the agent retrieves the exception or simply repeats the earlier conclusion.

Maintain an expected evidence set for each question. It is possible for a final answer to be correct by coincidence while the tool trace contains the wrong policy. Require both a correct conclusion and a supportable source path before calling the agent reliable for this workload.

Keep the chat template and tool schema in one versioned contract

A local agent connects several layers: tokenizer, message formatting, model generation, tool parsing and execution. A failure in one layer can appear as a general model problem. Capture a known-good request and response for each layer so you can isolate the cause when an update changes behavior.

Start with the model's documented template and explicit tool definitions. Do not manually concatenate an older model's role markers around a new checkpoint. Verify the serialized conversation in a development environment and confirm that the tool definitions and tool results occupy the intended positions.

Keep the tool schema narrow. A document lookup might accept a query string and a bounded result count. It does not need arbitrary filesystem paths, shell expressions or a free-form instruction for an external service. Smaller interfaces are easier to validate and give the model fewer ways to express an invalid action.

Validate before execution, then validate the returned tool data too. A tool result can contain a missing passage, a malformed identifier or an upstream error. The model should receive that condition as data rather than a fabricated successful lookup. Otherwise it may build an answer on evidence your application never actually retrieved.

Save the schema version with every evaluation run. If you change a field from optional to required, re-run the malformed-argument tests and known questions. An agent framework's successful parsing does not establish that the proposed action complies with the business rule behind the tool.

Build a resource test that reflects agent turns

Use a complete multi-turn trajectory when measuring memory and elapsed time. A single short completion can miss the cost of repeated retrieval, accumulating tool results and longer answers. Keep the same manual and question across configurations so their operating behavior can be compared.

Measure model load time separately from the first task and later warm tasks. If the process remains resident, loading may be rare. If the application shuts the model down between sessions, it becomes part of the user's waiting time. Document which behavior your prototype actually uses.

Record the number of tool calls, generated tokens and total task time. If a quantized configuration finishes each generation quickly but performs more unnecessary turns, it may not improve the complete workflow. Review the trace before changing sampling settings to chase a tokens-per-second figure.

Increase concurrency only after a single request is stable. Two agents can compete for memory and processing time even when each fits alone. Use separate conversation and tool state per request, and verify that source identifiers from one session cannot appear in another session's answer.

Consider a bounded queue when the device cannot serve every request at once. Test the cancellation behavior for queued tasks and show the user that the request is waiting. An apparent hang often creates duplicate submissions, which then make the queue problem worse.

Diagnose tool failures with a small error taxonomy

Separate invalid tool names, malformed arguments, tool execution failures, insufficient evidence and failure to stop. These categories point to different fixes. A parser change can address malformed arguments, but it will not correct a retrieval tool that searches the wrong manual version.

For invalid arguments, keep the raw proposed call and the schema error in a private development log. A bounded correction turn can be useful, but cap it and label it as a retry. If the same invalid call repeats, stop with a useful diagnostic instead of looping until the context fills.

For execution failures, return a clear error result. If the local file reader cannot access a document, do not replace the error with an empty passage that looks like a successful search. The final answer needs to distinguish “no matching policy” from “the lookup service could not read the policy.”

For evidence failures, inspect the retrieval step and the source ranking. The language model cannot reliably cite a passage it never receives. Try a known literal search and compare the returned sources before altering the agent prompt.

For stopping failures, inspect whether the tool result contains enough information and whether the task's completion rule is explicit. A prompt that rewards endless verification can increase unnecessary calls. Define what evidence is sufficient and what uncertainty should be reported to the user.

Compare deployment options without inventing a winner

Choose evaluation criteria before comparing local runtimes or weight formats: correctness on the manual, valid tool calls, resource use and maintenance effort. Keep those criteria tied to the application. A configuration suited to a persistent GPU service may be inconvenient for an occasionally used laptop assistant.

Run the same known-question set with the same schema and limits. Record differences in formatting, defaults and input handling. If a runtime requires a different template, treat that as part of the configuration under test rather than hiding it in a model-only table.

Finish with a decision record explaining which requirements passed and which remain unresolved. A narrow read-only assistant can be ready for a supervised pilot while write actions remain disabled. That is a useful outcome: it lets the team learn from real questions without giving an unvalidated tool loop broad operational permissions.

Conclusion

Evaluate LFM2.5-24B-A2B with a versioned local runtime, one read-only tool and a short correctness set. Extend context and permissions separately so each failure has an identifiable cause. Keep the working environment and event logs before connecting the agent to real write actions.

FAQ

Does A2B describe the full model size?

No. It describes active parameters. Budget the complete weights, quantization, context and runtime memory when planning local deployment.

Should every request use the full 131K context?

No. Use the evidence your task needs and measure the complete workflow. The documented capacity is a limit to evaluate, not a target to fill.

Does tool calling automatically execute actions?

Your application executes them. Validate names and arguments, enforce limits and return tool results in the correct conversation format.