Reasoning

Most agent failures are not weak writing. They come from poor sequencing, missed prerequisites, fragile tool decisions, and no ability to catch a mistake mid-run. Every serious agent framework now addresses that with some version of plan, act, reflect, revise.

Hyperstruck runs that loop too. But the loop on its own does not tell you whether the run was any good, and an agent that reasons harder is more capable of producing a convincing account of work it never did. So the parts that matter most are the ones that constrain the loop rather than the loop itself.

Two rules the whole engine is built on

Everything below follows from these, and they are worth reading before the mechanics.

Facts move one way. Observation grounds action. Assertion never does, no matter who made it: you, the planner, a retrieved memory, or the model itself.

The plan offers, execution disposes. A plan authorizes intent, a set of tools, and the approvals that must hold. What actually gets done, in what order, with which arguments, is settled where the work meets the world.

The second rule is the one that does the work. A planner has not read the system it is planning against, so some of what it supplies is genuinely useful and some is invented. Rather than trying to stop it guessing, Hyperstruck lets it guess and refuses to let anything downstream treat a guess as a fact.

What happens during a run

Planning

The engine breaks your goal into a structured, multi-step plan organized into milestones. Before it builds the plan it retrieves the learnings and prior plans that fit the task, and binds any claims it already holds about the entities your goal names, so the approach starts from experience rather than from the prompt alone.

A plan here is a declaration of intent, deliberately not a prediction of the actions that will occur. The planner is free to guess, because a guess is often a useful lead; the discipline is downstream, where nothing acts on a guess as though it were a fact. A plan also has to be checkable: it records what must be true and what must be approved, so oversight and budgets have something stable to bind to. A plan that only looks valid because it chains references to steps that could never have executed is rejected rather than run.

Execution

Each step runs against real tools with tracked results and data flowing between steps. A step whose arguments are already known, references to earlier results or literals from the goal, dispatches with no model call at all, because dispatching a bound argument is code.

The executor observes before it acts. An argument that asserts an unread fact about the world is treated as a hypothesis to verify, never an instruction to execute, and if the reading it was handed cannot be vouched for it does its own. When a step fails the engine classifies the error and decides whether to retry, degrade, or stop, and side-effect calls are guarded against firing twice across a retry. A step is finished when its effect has been observed, never because the model said it was.

Reflection

After execution the engine scores the output against the original goal across several dimensions and decides whether it is good enough to return.

Revision

When reflection finds a problem, the engine revises only the affected milestone rather than restarting the task, uses learnings relevant to that specific failure to guide the fix, and detects when further revision has stopped helping.

Then it has to prove it

This is the part a framework loop does not give you. Before a run is allowed to report success, its answer is checked against what the run actually observed. A claim that traces to no observation, or a run whose own output admits a required step was impossible while still claiming completion, is refused. The run terminates honestly, keeps the partial work, and tells your systems exactly what it would not stand behind.

A tighter, deterministic floor runs earlier and governs actions rather than claims: a consequential action targeting a record nobody read does not fire, and a write that depends on a read does not proceed on an invented value when that read came back empty.

Human approval

Approval gates bind a human decision to an action, so an irreversible thing cannot happen without someone accountable saying yes. Gates sit at the plan, milestone, step, tool, escalation levels, and on work an agent hands to another agent, and you can approve part of a plan rather than all of it.

Two properties matter more than the gate list, because they are what makes this survivable in production rather than a demo:

• A resume happens exactly once. A decision lands once even when two workers race for it, even after the run's serialized state has round-tripped through storage, and even if the gate table changed in between. Approved work is not re-executed on resume.
• An approval never widens. Approving one thing does not quietly authorize the next. Autonomy is raised by policy, with progressive trust as a track record builds and decay when it lapses, not by an approval leaking sideways.

See Agents API for resuming a suspended run.

Surviving interruption

At every milestone boundary, and at every approval suspension, the engine writes its full state to durable storage. One interaction is worth knowing: the fast profile turns milestones off, along with reflection, plan validation and plan revision, so a fast agent has fewer checkpoint boundaries. Turning approval gates on puts them back, because a safety floor re-enables milestones whenever gates are enabled, so a fast agent with gates still checkpoints. See Agent configuration. If the process crashes, or the work sat waiting on a human for a day, the run resumes from the last checkpoint and continues with the next pending step rather than redoing completed phases. This is what makes long tasks on ephemeral compute practical, and it is also why a run can wait on an approval indefinitely without holding anything open.

What this means for your agents

• Fewer silent failures. The expensive failure is the confident wrong answer, and that is the one specifically targeted.
• Safe to point at unfamiliar tools. Preconditions and entity grounding mean a tool the agent has not proven itself with cannot fire on a record nobody read.
• Resilient execution. Transient errors, tool failures, and human deliberation do not lose progress.
• Explainable outcomes. Every run produces a structured plan and execution trace, and a refused run carries a machine-readable reason.

Next

Reasoning is how Hyperstruck makes good decisions now. Memory is how it makes better ones next time.