AI Reliability in Practice
AI Reliability in Practice
How Thunk.AI Runs an AI Agent: the AI Guardian
How Thunk.AI Runs an AI Agent: the AI Guardian
Highlights
A good design is not enough if the agent carrying it out is left to its own devices. In Thunk.AI, every agent runs inside a control environment called the AI Guardian, which shapes what the model sees, what it may do, and what happens to its results.
The model acts only through structured tool calls. It never answers in free text, never reads data directly and never updates data directly. Every call is checked before it runs.
Every action carries an explanation. The model must say why it is acting and where its information came from, which keeps its later actions aligned and gives people something to check.
Progress is saved as it goes. Partial results are written to the work item's typed properties, so later steps and later runs build on recorded facts.
Results are verified, and errors are fed back. Tool results and outputs are checked by schema, by AI checks and, where configured, by people. A failed check goes back to the model to correct.
A run ends explicitly. The agent must conclude, ask a person or report an error, and the platform's own gates still apply after it concludes.
Models are certified. Every model offered on the platform passes a certification suite first.
Highlights
A good design is not enough if the agent carrying it out is left to its own devices. In Thunk.AI, every agent runs inside a control environment called the AI Guardian, which shapes what the model sees, what it may do, and what happens to its results.
The model acts only through structured tool calls. It never answers in free text, never reads data directly and never updates data directly. Every call is checked before it runs.
Every action carries an explanation. The model must say why it is acting and where its information came from, which keeps its later actions aligned and gives people something to check.
Progress is saved as it goes. Partial results are written to the work item's typed properties, so later steps and later runs build on recorded facts.
Results are verified, and errors are fed back. Tool results and outputs are checked by schema, by AI checks and, where configured, by people. A failed check goes back to the model to correct.
A run ends explicitly. The agent must conclude, ask a person or report an error, and the platform's own gates still apply after it concludes.
Models are certified. Every model offered on the platform passes a certification suite first.
This article describes the runtime side of reliability: what the Thunk.AI platform does while an agent works. It complements the design approaches in What is in a standard operating procedure, and how each part is made reliable, which decide what each step is asked to do. Here the question is how the platform keeps the agent doing exactly that.
1: An agent is more than a model
A language model, given a prompt, returns a response. An AI agent uses a model repeatedly, in a loop, to carry out a task: it decides what to do next, calls a tool, reads the result, and continues until the task is done. Left to itself, that loop has well-known weaknesses. The model can produce an answer without the information to support it, behave differently on similar inputs, or stop before the work is finished.
In Thunk.AI, the loop is run by the platform, not by the model. The help center calls this control environment the AI Guardian. It decides what context the model sees on each call, which tools it may use, whether each proposed call may run, and what happens to each result.
The diagram shows one step processing an invoice. The platform starts the model with the step's instructions. The model asks for the invoice details, and the platform calls the tool that reads them from the ticketing system and returns the result. The model then asks for the invoice to be read, and the platform calls the document reader. Finally the model asks for the result to be written to the finance system, and then says it is done. Every request and every result passes through the platform, which is what lets it control the loop.
The runtime is the third of the platform's three layers. The App Model defines what each step is asked to do and with what; the Authoring Environment helps the designer get that right; the Execution Runtime makes sure each run stays within it. Each layer catches failures the others cannot.
2: The model acts only through structured tool calls
In a Thunk.AI step, the model's only way to respond is to call one of a small set of tools, each with a strict input schema. Free-text answers are not accepted, because free text is one of the largest sources of variation in a model's behavior. Writing the step's results is itself a tool call, against the step's typed output properties.
Two consequences follow. The model never reads information directly: it asks a tool, and the tool returns exactly what it is designed to return. And the model never changes data directly: every change goes through a tool that can check it. The Guardian vets each proposed call before it runs, so a call with malformed arguments, or to a tool the step is not allowed to use, is refused and the model is told why. A step has access only to the tools granted to it, and each call can act only within the scope it was given.
3: Every action carries an explanation
Each tool call includes an explanation of why the agent is making it, including where its information came from. This is more than logging. Requiring the model to state its reasons constrains the current response, keeps later responses consistent with the reasons already given, and makes low-confidence or unsupported conclusions visible. It also gives a person reviewing the run a direct account of what the agent did and why.
4: Progress is saved as it goes
An agent records its partial results in the work item's typed properties as it works, rather than holding everything until the end. This checkpointing keeps a long task aligned within one step, and across the steps that follow, which read recorded facts instead of a model's recollection. Each step can be configured to save results as it works or at the end; the help center explains the trade-offs, including why saving only at the end combines badly with stopping on the first error.
5: Results are verified, and errors go back to the model
The platform checks the results of tool calls and the outputs of each step. Some checks are deterministic: a value must match its type, a required property must be present, a finish condition must hold. Some are made by a separate model, such as an AI check that the outputs match their descriptions, or that a document uploaded as a receipt is in fact a receipt. Some are made by people, where the process requires approval.
When a check fails, the failure is returned to the agent as information it can act on, so it can correct the mistake within the same run. An output that does not match its schema is rejected before anything downstream sees it, so malformed data never propagates to a later step. Code tools take part in this too: a tool that refuses an action states its reason, and the agent adjusts. Where verification finds an inconsistency the agent cannot resolve, the platform brings in a person.
6: A run ends explicitly
An agent cannot simply stop. It ends each run with an explicit action: conclude the step, ask a person, or report an error. A conclusion can also mean waiting, for a reply to an email or for the next scheduled run. Even after the agent concludes, the platform applies the step's own rules: properties required to finish, finish conditions and human gates. A step that the agent believes is done but that has not met those rules is not done. This is what prevents the "finished with the work undone" failure described in Where unreliable AI behavior comes from.
How a step responds to a failed tool call is also a choice: stop at the first failure, for steps where a wrong result is worse than none; continue with care, the default; or keep going. Design review flags steps that retry actions with side effects.
7: Security is part of reliability
An agent that can be talked into doing something else is not reliable. Agents run with the credentials of the thunk's owner, with no privileged mode. Instructions found inside data, such as an email that tells the agent to do something, are not followed as instructions. Every tool call is logged with its arguments and results, so any action can be traced back to the run, the step and the explanation that produced it.
8: Models are certified before they are offered
The platform's behavior depends on the model following tool schemas and recovering from errors. Before any model is offered on Thunk.AI, it must pass a certification suite covering categories such as recovering from invalid tool calls, handling edge cases and resisting prompt injection. A model can be chosen per thunk, per step and per AI tool, and a change of model can be tested by forcing the new model on test work items and comparing pass rate, cost and time.
9: Why the runtime matters
The benchmarks measure design and runtime together, but the runtime is what makes the design hold. A rule built into a code tool only protects the process if the agent cannot bypass the tool; a required property only helps if the step cannot finish without it. The AI Guardian is what makes those guarantees, on every call of every run.
This article describes the runtime side of reliability: what the Thunk.AI platform does while an agent works. It complements the design approaches in What is in a standard operating procedure, and how each part is made reliable, which decide what each step is asked to do. Here the question is how the platform keeps the agent doing exactly that.
1: An agent is more than a model
A language model, given a prompt, returns a response. An AI agent uses a model repeatedly, in a loop, to carry out a task: it decides what to do next, calls a tool, reads the result, and continues until the task is done. Left to itself, that loop has well-known weaknesses. The model can produce an answer without the information to support it, behave differently on similar inputs, or stop before the work is finished.
In Thunk.AI, the loop is run by the platform, not by the model. The help center calls this control environment the AI Guardian. It decides what context the model sees on each call, which tools it may use, whether each proposed call may run, and what happens to each result.
The diagram shows one step processing an invoice. The platform starts the model with the step's instructions. The model asks for the invoice details, and the platform calls the tool that reads them from the ticketing system and returns the result. The model then asks for the invoice to be read, and the platform calls the document reader. Finally the model asks for the result to be written to the finance system, and then says it is done. Every request and every result passes through the platform, which is what lets it control the loop.
The runtime is the third of the platform's three layers. The App Model defines what each step is asked to do and with what; the Authoring Environment helps the designer get that right; the Execution Runtime makes sure each run stays within it. Each layer catches failures the others cannot.
2: The model acts only through structured tool calls
In a Thunk.AI step, the model's only way to respond is to call one of a small set of tools, each with a strict input schema. Free-text answers are not accepted, because free text is one of the largest sources of variation in a model's behavior. Writing the step's results is itself a tool call, against the step's typed output properties.
Two consequences follow. The model never reads information directly: it asks a tool, and the tool returns exactly what it is designed to return. And the model never changes data directly: every change goes through a tool that can check it. The Guardian vets each proposed call before it runs, so a call with malformed arguments, or to a tool the step is not allowed to use, is refused and the model is told why. A step has access only to the tools granted to it, and each call can act only within the scope it was given.
3: Every action carries an explanation
Each tool call includes an explanation of why the agent is making it, including where its information came from. This is more than logging. Requiring the model to state its reasons constrains the current response, keeps later responses consistent with the reasons already given, and makes low-confidence or unsupported conclusions visible. It also gives a person reviewing the run a direct account of what the agent did and why.
4: Progress is saved as it goes
An agent records its partial results in the work item's typed properties as it works, rather than holding everything until the end. This checkpointing keeps a long task aligned within one step, and across the steps that follow, which read recorded facts instead of a model's recollection. Each step can be configured to save results as it works or at the end; the help center explains the trade-offs, including why saving only at the end combines badly with stopping on the first error.
5: Results are verified, and errors go back to the model
The platform checks the results of tool calls and the outputs of each step. Some checks are deterministic: a value must match its type, a required property must be present, a finish condition must hold. Some are made by a separate model, such as an AI check that the outputs match their descriptions, or that a document uploaded as a receipt is in fact a receipt. Some are made by people, where the process requires approval.
When a check fails, the failure is returned to the agent as information it can act on, so it can correct the mistake within the same run. An output that does not match its schema is rejected before anything downstream sees it, so malformed data never propagates to a later step. Code tools take part in this too: a tool that refuses an action states its reason, and the agent adjusts. Where verification finds an inconsistency the agent cannot resolve, the platform brings in a person.
6: A run ends explicitly
An agent cannot simply stop. It ends each run with an explicit action: conclude the step, ask a person, or report an error. A conclusion can also mean waiting, for a reply to an email or for the next scheduled run. Even after the agent concludes, the platform applies the step's own rules: properties required to finish, finish conditions and human gates. A step that the agent believes is done but that has not met those rules is not done. This is what prevents the "finished with the work undone" failure described in Where unreliable AI behavior comes from.
How a step responds to a failed tool call is also a choice: stop at the first failure, for steps where a wrong result is worse than none; continue with care, the default; or keep going. Design review flags steps that retry actions with side effects.
7: Security is part of reliability
An agent that can be talked into doing something else is not reliable. Agents run with the credentials of the thunk's owner, with no privileged mode. Instructions found inside data, such as an email that tells the agent to do something, are not followed as instructions. Every tool call is logged with its arguments and results, so any action can be traced back to the run, the step and the explanation that produced it.
8: Models are certified before they are offered
The platform's behavior depends on the model following tool schemas and recovering from errors. Before any model is offered on Thunk.AI, it must pass a certification suite covering categories such as recovering from invalid tool calls, handling edge cases and resisting prompt injection. A model can be chosen per thunk, per step and per AI tool, and a change of model can be tested by forcing the new model on test work items and comparing pass rate, cost and time.
9: Why the runtime matters
The benchmarks measure design and runtime together, but the runtime is what makes the design hold. A rule built into a code tool only protects the process if the agent cannot bypass the tool; a required property only helps if the step cannot finish without it. The AI Guardian is what makes those guarantees, on every call of every run.