Runs

What a run records

A run holds when the work ran, who asked for it, the goal in their own words, the capabilities that ran in order, the services those reached, and the workflow if there was one.

A workflow is the reusable process. A run is one execution of that process. Tasks that are not saved as workflows still create runs.

Approvals inside a run

When a capability uses an Ask policy, the run pauses before the action. HexaHQ shows what it plans to do and waits for approval.

If the action is approved, the run continues. If it is declined, or denied by policy, the run records that and says so.

Why there are no status badges

A run does not mark each step passed or failed, and this is deliberate. Your AI retries, recovers, and works around problems on its own, so a step marked failed in a task that finished correctly tells you something untrue.

What does appear is your organization's own decisions, in plain language: this was blocked by your rules, this is waiting for approval, someone declined it, this needs a tool nobody has connected. Those are the notes worth acting on, and they sit under the goal.

Who can see which runs

You can see the work you ran yourself. Administrators can see the whole organization's history, in the Hub under Activity Log, which is the oversight surface for what the company's AI did on the company's systems.

Runs are never shared, granted, or published. A collection does not reach them.

Use runs to understand problems

Look at the run when a task stopped early or could not reach a tool. The steps show how far the work got and which service it was heading for, and the notes say whether your rules blocked it, an approval is still waiting, someone declined, or a tool is not connected yet.

Runs are also the audit history for work done through HexaHQ. They answer who asked for the work, which capability ran, under which identity, and when.