From Prompt to Tool Call: How Reasonix Actually Executes Work
In Reasonix, the important moment is not when a model suggests an action but when that suggestion becomes a concrete tool call. This chapter traces that boundary: how provider output enters the agent loop, how a per-run registry turns names and arguments into a target, which host checks happen before execution, and what the system can honestly say after the tool returns. The result is an operational model for distinguishing model-generated intent from host-admitted work.
Consider a request to update a dependency. The model may need to inspect project files, choose an edit, run a test, and react to the result. From the outside, this can look like one continuous act of intelligence. Inside Reasonix, it is a sequence of interfaces and decisions. The provider produces a response. The host interprets any complete tool call. A registry identifies the available tool. Policy and enforcement decide whether the call may run. The result comes back as data for the next model turn.
The provider proposes; the runtime assembles
Reasonix keeps providers and tools at different layers. A provider is the model-facing component: it accepts a request containing conversation messages and tool schemas, then streams text, reasoning, and, when needed, a tool call. A tool is an executable capability with a name, description, parameter schema, and execution method. The model can choose a tool because the host has described it, but the description is not an execution grant.
The host builds a registry for a particular run. It combines the enabled built-in tools with capabilities supplied through configuration or plugins. Provider factories are also selected through configuration and registries. This is why an OpenAI-compatible endpoint can be another configuration instance rather than a new hardcoded branch in the agent. The same execution loop can work with different providers as long as they satisfy the supported interface.
That separation solves a practical problem. The model needs a stable vocabulary for asking the host to do things, while the host needs room to decide how those things are implemented. A request to read a file can resolve to a built-in reader. An external service can adapt its MCP tool to the same general tool contract. A runtime extension can intercept or replace a stage, subject to its own rules. The model does not need a new top-level mental model for each implementation, but the host still retains the real target and its safety properties.
The basic loop is therefore straightforward:
- Reasonix builds a provider request from the current session and the available tool schemas.
- The provider streams a response. Text can be shown as it arrives; tool-call fragments are accumulated until a complete call is available.
- If there is no tool call, the turn can end normally.
- If there is a tool call, the host parses and checks it, then either blocks it or executes the concrete target.
- The host records the result and appends a bounded representation for the next provider request.
- The provider interprets that result and may choose the next call.
This is not a workflow in which the host dictates every step. The model still decides whether to inspect, edit, test, ask, or stop. The host supplies the conditions under which those choices can acquire effects. That is the first important boundary: a provider response is a proposal inside a controlled loop, not a command line with automatic authority.
What happens before anything runs
The gap between a model tool call and a concrete execution is where Reasonix does most of its control work. The host treats the call as untrusted input even when it came from the configured provider. It must establish what the call means before asking whether it is allowed.
1. Parse and validate the call
A tool call includes a name and raw JSON arguments. Reasonix validates the argument shape before permission prompts, hooks, write leases, process startup, or tool dispatch. This ordering matters because an invalid call should be corrected, not granted a safety exception simply because it reached an approval screen. The host can return bounded diagnostic feedback, including the relevant schema shape, so the model can emit a valid call on its next attempt.
Validation also protects the later stages from ambiguity. A path-aware writer needs to know which path it is being asked to change. A command gate needs to know which command is being approved. A capability proxy needs to know which underlying target and arguments it will resolve. The host does not fill in missing values or silently unwrap an arbitrary argument envelope as part of this diagnosis. The model must correct its own malformed request.
2. Resolve the actual target
Some provider-visible calls are direct: the name identifies the tool that will run. Others are proxies. A proxy can let Reasonix expose a stable interface while the underlying capability is discovered or selected at runtime. In that case, the host resolves the call to the real target and its real arguments before applying the final safety decisions.
This prevents a common category error. A wrapper may advertise itself as read-only because resolving or inspecting it has no side effect. That does not mean every target reachable through the wrapper is read-only. Reasonix re-applies relevant Plan and execution checks after resolution. A target that turns out to be a writer or a destructive capability cannot inherit permission from the wrapper’s superficial classification.
The same principle applies when an extension changes a call. Reasonix validates the original call, allows the extension boundary to rule on it, and validates a replacement again before permission, hooks, leases, process startup, or execution. An extension may participate in the control flow, but it does not get to smuggle an unvalidated payload into the next stage.
3. Apply policy before acquiring a write lease
Once the host knows the target, it classifies the call’s effect. Is it read-only? Does it mutate workspace state? Does it verify something? Does it use a network or execute code? The classification is about the actual call and its arguments, not only the tool’s display name.
Reasonix’s permission policy then evaluates the call. Its general precedence is deny, ask, allow, and finally the configured fallback. A configured deny is a hard block. A call that requires approval can go to an interactive approver, while an unattended run must resolve according to its configured posture. Read-only operations normally have a different fallback from writers. Bash receives additional command-shape scrutiny because a short command can hide an interpreter, redirection, substitution, or another process.
The host performs this permission decision before acquiring a workspace write lease. That prevents a blocked or waiting operation from holding the resource that another safe operation needs. For a file mutation, the lease can then coordinate the relevant workspace or path. For an opaque operation whose write scope cannot be proven, Reasonix does not guess a narrow path merely to obtain more parallelism.
A permission decision is still not the same as a filesystem guarantee. After authorization, the Sandbox checks whether the operation can read, write, execute, or connect within the configured boundary. File tools resolve paths and reject escapes through .. or symlinks. On systems with an available OS backend, Bash can be jailed as well. The documented Windows behavior is more limited: file tools retain in-process confinement, but Reasonix does not claim an OS-level Bash sandbox there.
Only after these decisions can preparation continue. The host may coordinate a write, run an approved pre-tool hook, attach the current call context, and provide the execution environment. The sequence is intentionally uneventful when everything is safe. Its value appears when the same model request is malformed, denied, outside the workspace, or broader than its declared scope: the call stops before the concrete effect.
Execution is a feedback loop, not a success assumption
After the checks, Reasonix dispatches the concrete tool. The outcome is not reduced to a single vague status. A call can be blocked before it runs, fail while running, or complete successfully. Those cases have different meanings for the model and for the user.
A blocked call is a host decision that execution did not happen. The model receives a reason such as a permission denial, an unavailable planning target, or a Sandbox refusal. That feedback can help the model choose another approach, but it is not evidence that the requested operation was attempted. Treating a block as an ordinary tool failure would invite the model to retry an action that the host has already ruled out.
An invalid argument is another pre-execution case. If the JSON does not match the tool contract, Reasonix can return correction advice and the schema without running anything. This is a model-generation problem, not a permission approval. The host does not need to wait for a new user turn merely because the first argument shape was wrong.
A real execution failure is different again. The tool ran and reported an error, or the provider or operating environment prevented completion after dispatch. Reasonix returns that failure to the model as part of the tool result and keeps the failure in its execution record. The model may use the information to correct a path, change a command, or report a genuine blocker. The host does not rewrite the failure into success because the model sounds confident.
A successful result is bounded before it becomes provider-visible. This protects the next request from being overwhelmed by a large tool response while preserving the host’s ability to record what it received. For structured operations, the host can attach its own receipt and source information. For a file-oriented change, it can compare the observed target with the identity used during preparation. For an opaque shell or external capability, it records the limits of what it could observe instead of inventing a precise scope.
The loop then returns to the provider. This is where model initiative matters again. A test failure may cause another inspection. A blocked write may cause an explanation or a different route. A successful edit may cause the model to stop or to run a check. Reasonix does not force every turn into the same number of reads, edits, or tests. Its host boundaries are applied to actual effects, while the model chooses the investigation appropriate to the request.
That design also explains why “ordinary request” and “complex request” do not automatically imply different execution engines. The current policy is fact-driven rather than keyword-driven. A request that sounds simple may still produce a risky shell command and receive strict treatment. A request that sounds complex may remain an ordinary executor turn if no explicit planning route was selected. The host responds to the concrete call and the active user-selected controls.
What the host knows after a call
Suppose the model says, “The dependency update is complete.” Reasonix should not treat that sentence as the whole record. After a tool call, the host may know that a particular call was received, that its arguments passed validation, that permission and Sandbox checks produced a decision, that the tool did or did not execute, and what result or failure it returned. A structured writer may also provide evidence about a target version, path, or observed mutation.
Those facts support useful conclusions, but they do not establish everything a reader might want to know. A receipt shows what the host delivered or observed; it does not show that the model understood the result. A successful command is not necessarily a complete review. A partial read is not a whole-file proof unless the operation explicitly required and reached full coverage. An opaque script may have side effects outside the host’s precise view. A clean model stop is not a host certification that the repository is correct.
Keeping these meanings separate is not bureaucratic overhead. It prevents a failure in one layer from being silently upgraded by another. A model can be good at reasoning and still choose an incomplete check. A permission gate can be correct while the permitted command fails. A Sandbox can contain a file writer while an external service performs an effect that local rewind cannot undo. The execution record must preserve those distinctions if the user is to decide what happens next.
The practical mental model is simple: the provider supplies intent and interpretation; the host supplies admission, enforcement, persistence, and observation; the tool supplies an effect or an error; the next model turn receives evidence about that outcome. Once this path is visible, Reasonix’s higher-level controls become easier to understand. Plan changes when state-changing work may begin. Goal changes how normal turns continue. Context and evidence change what survives between turns. Rewind changes which structured states can be restored. None of them needs to be a mysterious “smart mode”; each changes a specific boundary in the execution path.