The instrument panel for AI work.

What AgentFlow runs for you

AgentFlow's first job is to be a pipeline orchestrator. You define a sequence of work; AgentFlow executes it as a Step Functions state machine, manages the human and external decision points along the way, and records what was decided.

The four primitives:

App contains Pipelines. Pipelines are Step Functions state machines whose nodes are Steps. Each Step launches into a Container — that's where your code runs. Pipelines end at (or contain) Gates. AgentFlow does not enter the container.

What AgentFlow does NOT do

AgentFlow does not interfere with how you build your apps or your agents.

• No SDK to import inside your agent code
• No framework conventions inside the container
• No context to propagate, no headers to thread
• Your agents can be LangGraph, CrewAI, raw OpenAI SDK, custom Python, anything
• Step kinds match natural deployment shapes: function / skill for Python that runs in our pooled runners; workspace for whatever Docker image you ship to Fargate; lambda for an ARN you hand us; external_runner for runtimes outside our launch path that report back

AgentFlow is the launcher and the recorder. It launches the container, waits for the step to finish, routes the gate to the right human or system, records the decision, then advances the state machine. Your code stays yours.

How decisions get made

Pipelines incorporate gates — points where a decision happens (approve, reject, hold). Two kinds today:

llm_gate — LLM-as-decider

A Bedrock-backed Lambda evaluates the step's output against a decision_schema. Useful for deterministic rule-checks expressed in natural language ("does this PR contain a breaking change?"). Decision lands in DecisionV2.

yaml
- id: cp1-rerun-decider
  kind: llm_gate
  on_event: cost-opt.cp1.proposed
  scope: ticket
  model: anthropic.claude-3-haiku-20240307-v1:0
  decision_schema: { ref: cost_opt.schemas.RerunDecision }
  decided_by: cost-opt-cp1-rerun-decider:v1
  on_rerun: { ... }
  on_park: { transition_to: Awaiting-CP1 }

external_gate — human or external system as decider

Three sources:

yaml
# Jira: a state transition in a Jira issue resolves the gate
- id: production-approval
  kind: external_gate
  source: jira
  config:
    actor_field: assignee
    state_to_decision:
      Approved: approved
      Rejected: rejected
    timeout_seconds: 86400
  on_approved: { ... }
  on_rejected: { ... }

# github_label: applying a label resolves the gate
- id: pr-review
  kind: external_gate
  source: github_label
  config:
    actor_field: actor
    label_to_decision:
      lgtm: approved
      blocked: rejected

# webhook: any system that POSTs to AgentFlow's resume endpoint
- id: custom-approval
  kind: external_gate
  source: webhook
  config: { ... }

The gate's underlying mechanism is a Step Functions task token — the pipeline pauses at the gate state until the source system reports a decision via the configured resolver. The decision lands in DecisionV2 regardless of source. The pipeline cares about the decision, not where the human was when they made it.

The Inbox — a cross-app view of pending decisions

For human-resolved gates that don't have an external system attached, AgentFlow exposes an Inbox — a console view that aggregates tickets across all apps that are sitting in Awaiting-* or Pending-* stages. Backed by the list_pending_decisions MCP tool (queries each app's data layer for stage-pending tickets).

The Inbox is a view, not a gate kind. Operators use it to see "what needs me, across every product, right now."

How to use it

You can run AgentFlow as just an orchestrator. No bead enrichment needed. Five steps:

That's the orchestrator surface. No beads required. A reader who stops here understands why they'd use AgentFlow.