Safe by design

A workflow’s structure is data that the runtime compiles, so its boundaries live in the architecture, not only in a prompt. Step types, topology, tool access, typed inputs and outputs, assertions, model rules and action policy are all validated before a run starts.

What the runtime enforces

Boundary	What it means
Typed steps and fields	Each of the ten step types has a defined contract.
Per-step tool gating	Agentic steps see only their declared tools; deterministic tool steps call the one named tool.
Deterministic topology	Step order and declared branches compile before the run.
Typed dataflow and references	Upstream dependencies are explicit; large data moves by durable reference.
Assertions and bounded retries	Result checks and limits prevent unbounded validation loops.
Model boundaries	Step types that never call a model reject model pins.
Action policy	Approved actions run the frozen plan; turning approval off is explicit.
Sandbox isolation	Python runs away from application credentials, with resource limits and optional `nsjail`.
Auditable execution	Runs and action decisions produce durable records.
Explicit reuse	Skills are attached to steps, and subworkflows name a saved workflow.

When to use a compiled graph

One agent with every tool, deciding what to do and in what order, is useful for exploration. For regulated, audited, production workflows, where a wrong tool, a runaway loop or an ungoverned write-back has real consequences, a compiled graph gives a stronger operating boundary. It’s the difference between a workflow you can ship and one you can only demo.

Last modified on October 1, 2026

AgentFlow

Get started

Set up a project

Ask

Automate

Extend

Operate

Concepts

Reference

What the runtime enforces

When to use a compiled graph

​What the runtime enforces

​When to use a compiled graph

What the runtime enforces

When to use a compiled graph