What is process-verified reasoning in AI OS?

Process-verified reasoning grades each intermediate step of an agent's work before the next step runs, instead of only checking the final answer. In AI OS a step carries a rationale and, optionally, an action; the action cannot execute unless the step verified. That ordering is structural, not a convention. Verification is three-valued — correct, incorrect, or ambiguous — and an ambiguous step is never treated as a pass. Any pipeline stage can use it with pattern: verified-steps.

What does it mean for AI OS agents to author automations instead of executing tasks?

For repeatable work with a deterministic middle — fetch, transform, deliver — the agent writes the automation once and reviews its output, rather than re-deriving the procedure with a model on every run. The model handles only the parts that need judgment. Measured on one real task, the daily intelligence brief, the automation-authored version cost 16 times less, used 14.5 times fewer tokens, and was more grounded because it read the providers' own changelogs rather than a model's recollection of them. That is one task on one day, offered as a measurement rather than a guarantee.

How does AI OS handle a model reply that was cut off?

Every agent result carries the API's own stop reason, so a reply that hit its token ceiling is reported as truncated rather than passed off as complete. An empty reply is reported as a failure with its likely cause named. Before this, a cut-off answer could parse cleanly and simply be missing its end — the platform met that bug in several disguises before wiring the signal through.

Reasoning & Automation

A language model guesses every token, so every reply carries a margin of error. AI OS treats that as an engineering fact rather than a slogan: it verifies reasoning step by step before anything runs, and for repeatable work it has agents author automations rather than re-derive the procedure on every run. Both are measured, not asserted.

Process-verified steps

Process-verified reasoning grades each intermediate step of an agent's work, not just the final answer. A final answer can be right for the wrong reasons; grading the process catches the broken step where it happens.

In AI OS a step has two parts: a rationale (the thought) and, optionally, an action (the thing the world will feel — a file write, an API call, a command). The verifier grades the rationale before the action is allowed to run. A step that fails verification has its action dropped, not run-then-regretted. This is structural: the execute path is unreachable from any state where the step is unverified.

Three-valued verdicts

A verifier answers CORRECT, INCORRECT, or AMBIGUOUS. Ambiguous is a real answer: a step nobody could judge is marked unverified and stays that way, so "checked and fine" and "nobody knows" never blur. A verifier that could not answer at all approves nothing.

Verifiers are pluggable

A step can be verified by a model, a deterministic rule, or an external checker such as a test run. Rules run first — they are free and cannot be talked out of their answer — and a model is only paid for when the rules have nothing to say.

Reasoning patterns for pipelines

Three patterns are available to any pipeline stage by name. Each turns one agent call into several, so each carries a hard call budget and reports what it spent.

Pattern	What it does	Cost shape
`verified-steps`	Decomposes the task, then executes each step behind the verification gate above.	1 + 2 calls per step
`reflexion`	An actor attempts, an evaluator judges, and on failure a reflector writes one transferable lesson that is carried into the next attempt — a retry that names what went wrong instead of repeating the same coin flip.	up to 3 calls per attempt
`tree-search`	Proposes several candidate next steps, scores them, and searches breadth- or depth-first. A depth-first search that hits a dead end backtracks to the best node it has not yet opened.	1 + breadth per expansion

Every model call inside these patterns passes through one meter. A pattern cannot under-provision a call or exceed its budget, because there is no unmetered path to a model.

Verified against a live model

The patterns depend on a model replying in the shapes the parsers expect. That assumption was tested against a real model rather than a mock: across eight live runs the checks found and fixed a parser too strict for markdown, a call starved of tokens, and a platform-level signal that had been discarded. The final run graded eight formats with zero failures. That is one task on one day — a repeatable check with an exact signal, not a one-time guarantee.

Agents author automations

For repeatable work, an agent that re-derives the procedure on every run pays for it twice: it pays tokens every run, and it accepts the model's error margin every run. A deterministic automation, once correct, costs nothing per run and has no margin. So the agent's job for that work is to write the automation once and review its output, not to be the automation every time. Same agents, new job: authors, engineers, and overseers.

This only applies where the task is deterministic given its inputs. Judgment — a new brief, a support question in someone's own words, a diagnosis — stays with the model. The move is to shrink the model's role inside each recurring task to its irreducibly judgmental core and compile everything around it.

Measured on a real task

The daily intelligence brief was the test case. The original pipeline made eleven model calls, seven of them agents with web-search tools told to go find their provider's news. The automation-authored version fetches each provider's own changelog deterministically, removes what yesterday already reported, and makes one model call to write the statement.

Per run, same day	Eleven-call pipeline	Automation-authored	Ratio
Cost	$1.10	$0.07	16×
Tokens	121,811	8,383	14.5×
Wall time	115 s	about 20 s	about 6×

Cost was the smaller half of the result. The automation-authored statement contained 22 current-week entries from primary sources. The eleven-call pipeline's statement said, in its own words, that it had zero live-verified findings and was restating a stale knowledge pack. On its second run the automation-authored brief surfaced a provider pricing change that four other inputs had missed — and it was verified against the provider's release notes before anyone acted on it, because a model's claim about pricing is exactly the kind that needs verifying.

Scope: one task, one day, one run of each. The automation-authored brief is available as a mode alongside the original pipeline. Whether it becomes the daily default is an operator decision.

The honesty rules that make it safe to trust

Unparsed is not "no updates". A source that fetches fine but yields no dated entries is reported as unparsed — its page changed, the news did not. A model-driven consultant could not tell those apart; it would report quiet with full confidence.
Truncated is not complete. Every agent result carries the API's own stop reason, so a reply that hit its ceiling is reported as cut off rather than passed as finished. An empty reply is a failure with its likely cause named.
Per-source health is written down. Which sources fetched, parsed, timed out, or changed shape goes into the run's record. That is what the overseeing agent — and the operator — reads.

Both halves belong to the management layer: verification before action, and automation where reasoning is not the job. See also Oversight & Approvals and Architecture.