Skip to content

The LLM-workflow runtime (executor B)

Executor B runs an intent as an in-band model workflow: a Hub-hosted Claude Messages-API loop whose every tool call passes the same gate and can escalate to you. It is the alternative to spawning a Commander, for work that is "read, reason, act" rather than "get a machine and build."

The defining property is in-band by construction: because the Hub itself makes every model call and dispatches every tool, it sees and controls every step. There is no external session to observe through a side channel — the loop is the Hub.

Status

The underlying model tool-loop, the Messages-API client, cost accounting, and the cron/event triggers are live in the platform. The workflow definition, the run executor, the universal HTTP connector and its SSRF-safe egress path, and the A/B selector described here are merged on main but NOT WIRED, and are not available in this release. Nothing in the server constructs the runtime's implementations, so there is no flag, setting or configuration that turns them on. You can create and list workflow definitions; they will not execute.

Corrected 2026-09-15 (HIVE-1273): this note previously said the run executor was "dark behind a default-OFF flag". No such flag exists. The distinction matters — a flag implies an operator can enable it, and nobody can. The same note also listed the SSRF-safe egress path as live; it guards the HTTP connector above, which is itself unwired, so it has been moved to the unwired list. The four remaining items called live were not re-measured and are unchanged.

The worked example

"Every morning, summarize the newsfeed list and post it to my site."

A saved workflow with a schedule trigger: the model reads the list (a fetch action), summarizes it (a model step), and posts it (an HTTP action). Each action is gated allowed / needs-approval / denied. If the post is gated needs-approval, it escalates to you and resumes on approval. No Commander is ever spawned — a "post to my site" job needs only the model plus the gate.

The runtime loop

At heart the runtime is a bounded model-plus-tools loop:

flowchart TD
    T[Trigger fires] --> R[Resolve model + build system prompt<br/>role · injected knowledge · trigger context]
    R --> L[Build tools = the workflow's allowed actions]
    L --> C[model call]
    C --> S{stop reason}
    S -->|tool_use| G{{gate each action}}
    G -->|allow| DISP[dispatch → tool_result]
    G -->|deny| DR[model-readable denial → tool_result]
    G -->|needs approval| PAUSE[pause + escalate]
    PAUSE -->|approved| DISP
    DISP --> C
    DR --> C
    S -->|stop| OUT[emit result to destination]

Each turn: build the request with the allowed tools, call the model, and for each tool-use block the model emits, gate the action. On allow, dispatch it and feed the result back. On needs-approval, pause the run and escalate. On deny, feed a model-readable denial back as the tool result and let the loop continue in a degraded state — it never bypasses. The loop is bounded by a maximum iteration count and a per-run cost budget.

What a workflow is

A workflow is a saved, per-user definition — one row per saved workflow, owned per user (the tenancy key lives here). Its fields:

  • model — an explicit model or a role/task-type the router resolves, plus a thinking level.
  • role / prompt — the system prompt and persona for the loop.
  • allowed_actions — the action allow-set: an explicit list of tool names, integration verbs, and named HTTP-connector actions the workflow may call. Default-deny: only listed actions are offered to the model as tools, and each is independently gated at call time.
  • trigger — one of schedule (cron), event (a bus predicate), or on_demand.
  • output / destination — where the result goes: a result message, a report, an alert push, or a named HTTP destination.
  • gates — the per-workflow, per-action policy, composed with the estate's gate model.
  • budget — a per-run cost ceiling (and optionally per-day).
  • cred_refs — references to the credentials the workflow may use, never inline secrets (see Credential scoping).

Each execution is a separate run record, moving through pending → running → awaiting_approval → done / failed / denied, stamped with trigger provenance, the accumulated token usage and cost, and a transcript pointer.

The action vocabulary

A workflow's tools come from one uniform vocabulary so that everything is "configured the same way":

  • Hub tool surface — the existing set of agent-action tools.
  • Integration verbs — per-integration outbound connectors with encrypted credentials.
  • A universal HTTP/webhook action — a typed http_request{method, url, headers, body} for "post to my site" / "curl," behind SSRF protection and the gate.

Spawn is optional: if an allowed action happens to be a spawn action, the loop dispatches it exactly like any other action, through the same gate — and only then is a Commander spun up. Executors A and B are not mutually exclusive at the action level; the selector only picks the top-level executor.

Safety properties

The runtime inherits the platform's invariants and adds none weaker:

  1. Default-deny at every action — only allow-set actions are offered; each is independently gated; anything unlisted is denied.
  2. The workflow model never self-approves — it can propose a gated or irreversible action, never approve it. Prod deploys and external publishes always pause for you.
  3. Fail-closed — an approval timeout defaults to deny; a gate or resolution fault denies; a denied action degrades the run, it never bypasses.
  4. Verified identity, injected — the action's credential is injected server-side over the model-supplied params; the model never sees a raw secret (the confused-deputy defense).
  5. Bounded — per-run cost and budget caps, bounded loop iterations, a per-turn dispatch budget, and a timeout.
  6. SSRF-safe egress — every external action is pinned through resolved-IP classification with DNS-rebind defense.
  7. Audited and observable in-band — every action, gate decision, and approval is on the tamper-evident audit chain, and the whole run is visible in the Hub.
  8. Irreversible ⇒ human — prod, irreversible, or external-publish actions always escalate to you.

Provider note

Tool-use workflows run on the Claude Messages API, which is where the multi-turn tool loop lives. Non-tool "summarize" steps can use provider-flexible completion; a multi-provider tool-use bridge is a larger, separate effort and is out of scope for the first version.