A smaller local model is easy to criticise for mistakes it never needed to make. Ask it to count thousands of files, compare version strings, remember an entire project's state and decide whether a disk write really happened, and even a capable language model can become the weakest part of the system.
Many of those jobs have precise answers. Ordinary software should own them.
In the ARKTOR approach, controlled execution and outcome verification are deliberately separated from the chosen AI model.
Start by separating interpretation from calculation
The model is useful when the user says, 'Find the slow part of this workflow and suggest how to test it.' It can interpret the goal, propose a sequence and identify ambiguous decisions.
The model is not the right authority for checking that a SHA-256 digest matches, sorting versions, validating a JSON schema or confirming that a target file now has the intended contents. Those operations have deterministic implementations.
Moving them out of the prompt doesn't weaken the agent. It reduces avoidable errors and inference calls.
Give the model a narrow result contract
Instead of asking for a free-form essay that contains instructions and conclusions, ask for a structured proposal:
- Goal understood
- Proposed action
- Required tool
- Expected result
- What must be checked afterwards
- Reasons to stop or ask for approval
Validate the structure before doing anything with it. Missing values should not be silently guessed.
The operating-profile experiment shows why tool instructions should be tested on the actual model rather than assumed to be universal.
Our local-agent survival run is a concrete example of an output that needed deterministic code checks.
Let the execution layer say no
A model can request a file operation. That does not mean it should have direct operating-system authority. A separate execution layer should evaluate the target, permission, allowed capability and current state.
Test denial paths as carefully as successful operations. For example, a model that asks to leave a sandbox should receive a clear rejection and adapt within the authorized workspace.
Store state outside the model's conversational memory
Long workflows need a durable record of completed steps, remaining tasks, evidence and failures. Do not rely on the next prompt to reconstruct that information from chat history.
When a job resumes, the model should receive the small part of the state relevant to its next decision. The controller can verify what remains unfinished without asking the model to guess.
Score the final result separately
A tool may report success while writing the wrong data. The model may congratulate itself while an independent checker finds a mismatch. Keep those outcomes visible and separate.
The Model Runtime vs Controller vs Node guide explains the architecture, while Independent Read-Back Verification explains why tool receipts are not enough.
Small models become more useful when they are asked to do the part where interpretation actually matters. The rest belongs to predictable code, explicit permissions and measured results.