DecisionAct v0.1.2: Building Multi-Tool Agents with Decision Models Instead of LLMs

An Agent Framework That Doesn't Depend on LLMs

Most agent frameworks treat large language models as the reasoning core, but the open-source project DecisionAct takes a different path: it uses decision models (such as JEV and Cloudflare Clef) to drive task-oriented agents. Developers only need to define Python tools, input parameters, intents, and response templates; the decision model handles selecting actions and inputs, while functions handle execution. According to the Reddit post, v0.1.2 focuses on improving the reliability of multi-tool calls and the input parsing mechanism.

The direct benefit of this design is reduced dependence on LLMs—the reasoning step is handed to a lighter-weight decision model, while tool execution is entirely handled by developer-controlled Python functions. For task scenarios with clear workflows and structured inputs, this is easier to debug and audit than letting an LLM improvise freely.

Decision Model is the core concept here, and it differs from generative large language models: it doesn't produce free-form text, but instead makes a classification-style choice among a given set of candidate actions/parameters. JEV and Cloudflare Clef both fall into this category—they receive structured context and output a discrete decision (which tool to pick, what parameters to fill in), so reasoning overhead is low, outputs can be constrained, and behavior is more predictable. This also explains why the framework suits tasks with clear workflows: the decision space is pre-limited by the developer, and the model only needs to discriminate among a finite set of options rather than generate openly.

Intent in conversational agents usually refers to the semantic categorization of a user request, such as "query order" or "calculate value." The framework uses this to determine which tools and parameter templates can be invoked. Decoupling intent recognition from tool execution ensures each request first lands in a clear processing branch, and then the decision model handles multi-step tool orchestration within that branch—which is also why it supports only a single intent per request.

What Changed in v0.1.2

Repeated Calls No Longer Reuse Old Parameters

Previous versions could carry over the parameters from a prior call when the same tool was invoked consecutively. The new version re-parses inputs on every repeated call, avoiding the error of "calculating new results with old values."

Tool Results Can Serve as Subsequent Inputs

A more practical change is support for chained execution. The example given in the post is "first calculate 4 plus 5, then multiply the result by 2"—the return value of one tool can become an input parameter for the next. This allows multi-step tasks to be completed within a single request, without making the user ask in two separate turns.

Clearer Execution Context

The new version separates instructions, messages, and completed tool calls within the context, reducing the chance of the model confusing information from different sources. This is especially critical for multi-turn, multi-tool interleaved workflows.

Verify Before Asking When Inputs Are Uncertain

When there is uncertainty in input selection, the framework gives the model a chance to double-check; if it still can't determine the answer, it automatically asks the user for clarification. This adds a buffer between automatic execution and human intervention, reducing the cost of erroneous execution.

Longer Tool Sequences and Resumption After Human Approval

The framework allows longer tool-call sequences but sets a hard limit, and it improves the ability to continue the flow after human approval. This mechanism is practical for sensitive operations that require mid-process confirmation.

Three Ways to Parse Inputs

According to the post, input parsing supports three kinds of candidates: regex candidates, predefined classification options, and text candidates selected based on parameter descriptions. Whether the model chooses correctly depends heavily on how clear the parameter descriptions are and whether the context is set up appropriately. The author also acknowledges that the framework currently supports only one intent per request combined with multiple tool calls, and that the model's choices can still be wrong—this is where users need to build in fallback logic.

Candidate-based input parsing is fundamentally different from free-form LLM generation: regex candidates suit strictly formatted values (order numbers, dates); predefined classification options suit enumerated parameters (such as "urgent/standard"); and text candidates based on parameter descriptions have the model match on the semantics of the description. What all three share is that they first narrow the space of possible values, then let the decision model pick within it—so the clarity of parameter descriptions directly determines accuracy. In practice, descriptions should be written as distinguishable discriminating features whenever possible, and a failure fallback should be set for each candidate type—for example, triggering a clarification question on parse failure rather than forcing a guess.

Getting Started and Scope

The install command is pip install -U decisionact, and you'll need credentials for your chosen decision model provider before use. The official documentation provides a quick start along with three examples: a calculator, order support, and a flight counter.

Note that DecisionAct is positioned as a task-focused agent, not a general-purpose conversational assistant. When task boundaries are clear and tool interfaces are well-specified, the decision-model-driven approach has advantages in reliability and interpretability; conversely, open-ended tasks may still require LLM involvement. At the end of the post, the author also jokingly emphasizes that "no LLMs were harmed," highlighting the project's differentiating direction.

For developers who want to try a non-LLM agent approach, this project offers a lightweight, highly readable starting point, and the author openly welcomes contributions and feedback.

One-line Summary

DecisionAct replaces LLMs with decision models to drive task-oriented agents, and v0.1.2 strengthens multi-tool call reliability.

Paragraph Summary

DecisionAct is an open-source agent framework that doesn't depend on large language models; it uses decision models such as JEV and Cloudflare Clef to handle reasoning and selection, while developers only need to define Python tools, input parameters, intents, and response templates. v0.1.2 focuses on improving multi-tool call reliability: re-parsing inputs instead of reusing old parameters when repeatedly calling the same tool; supporting prior tool results as subsequent inputs for chained execution; separating instructions, messages, and completed calls within the execution context; double-checking once when inputs are uncertain and automatically asking the user for clarification if still unresolved; and allowing longer tool sequences and resumption after human approval. Input parsing supports three approaches: regex candidates, predefined classification options, and description-based text candidates. The framework is positioned as a task-focused agent, suited to tasks with clear boundaries and well-specified interfaces, while open-ended scenarios still require LLMs.