implements

implements

The behavior section of a machine. implements is where all execution logic lives: steps, flows, state declarations, runtime configuration, lifecycle hooks, event subscriptions, and scheduling. It is the largest and most important section, containing everything the machine does (as opposed to what it accepts, returns, ensures, or verifies).

When to use

Every machine that performs work has an implements section. It is required for any machine with steps. The only machines that might omit it are pure type definitions or domain schema declarations.

Syntax

implements
  <subsections and steps>

Structure

The implements section contains several optional subsections (in recommended order) followed by steps or flows:

Configuration subsections

Subsection	Purpose	Example
state	Mutable state initialization for reactive machines	counter: number, default: 0
runtime	Operational configuration	timeout: 30000, max_retries: 3, streaming: "enabled"
lifecycle	Before/after step hooks	before_step: validate
schedules	Cron, interval, and webhook triggers	cron: "0 9 * * *"
subscribes	Event subscription handlers	on "order.created" run process
publishes	Event names this machine emits	"order.processed"

Step types

Step	Syntax	Purpose
compute	compute name	Pure computation
ask ... using	ask name, using: "provider:model"	LLM reasoning
ask ... from	ask name, from: "machine"	Call effect machine
ask ... of	ask name, of: "machine"	Query running machine
action	action name type	Side effects (http, db, call, exec, file)
decide	decide name	Conditional branching
recall	recall name	Memory retrieval
remember	remember name	Memory storage
launch	launch name	Async fire-and-forget
wait for	wait for name	Suspend and resume

Control flow

Construct	Syntax	Purpose
flow	flow name	Named flow (group of steps)
flows	flows	Container for multiple named flows
run	run flow(name)	Execute a flow (call-and-return)
goto	goto flow(name)	Jump to a flow (tail-call)
for each	for each var in expr	Iterate over a collection
on failure	on failure	Error handling block
together	together	Parallel step execution
match	match expr	Pattern matching

Implicit vs explicit flows

For machines with a single linear sequence of steps, place them directly under implements (implicit main flow):

implements
  ask classify, using: "anthropic:claude-haiku-4"
    with task "Classify this text"
  compute format
    {result: steps.classify.category}

For machines with multiple execution paths, use the flows container with named flow blocks:

implements
  flows
    flow extract
      action fetch http
        url: input.source_url
    flow transform
      compute normalize
        {data: steps.fetch.body}
    flow load
      action store db
        query: "INSERT INTO results VALUES ($1)"
        params: [normalize.data]

Examples

Minimal implementation

machine greeter
  accepts
    name as text, is required

  responds with
    greeting as text

  implements
    compute greet
      {greeting: "Hello, " + input.name + "!"}

Full implementation with state and lifecycle

machine conversation_agent
  accepts
    message as text, is required

  responds with
    reply as text

  implements
    state
      messages: list, default: []
      turn_count: number, default: 0

    runtime
      timeout: 30000
      streaming: "enabled"

    lifecycle
      before_step: validate_input

    ask respond, using: "anthropic:claude-sonnet-4-6"
      with role "You are a helpful assistant."
      with task "${input.message}"
      returns
        reply as text
      assuming
        reply: "Hello! How can I help?"

    compute update_state
      {
        reply: steps.respond.reply,
        messages: [...state.messages, {role: "user", content: input.message}, {role: "assistant", content: steps.respond.reply}],
        turn_count: state.turn_count + 1
      }

Reactive machine with subscriptions

machine order_monitor
  responds with
    failed_count as number
    last_failure as text

  implements
    state
      failed_count: number, default: 0
      last_failure: text

    subscribes
      on "order.failed" run handle_failure
      on "order.created" run log_order

    publishes
      "order.monitored"

    flows
      flow handle_failure
        compute increment
          {
            failed_count: state.failed_count + 1,
            last_failure: event.order_id
          }

      flow log_order
        compute log
          {logged: true}

Multi-flow with error handling

implements
  flows
    flow main
      ask analyze, using: "anthropic:claude-sonnet-4-6"
        with task "Analyze this data"
        returns
          result as text
        assuming
          result: "Analysis complete"
      run flow(store_results)

    flow store_results
      action save db
        query: "INSERT INTO analyses (result) VALUES ($1)"
        params: [steps.analyze.result]
      on failure
        compute fallback
          {status: "storage_failed", result: steps.analyze.result}

Governance

The implements section itself is not governed. Individual steps within it are governed according to their type:

• Pure steps (compute, decide): no governance required
• Effect steps (action, ask ... from, launch): require declared permissions, mediated by the governance interpreter
• Reasoning steps (ask ... using): require reason capability, subject to token budgets
• Memory steps (remember, recall): require memory capability
• Control flow (run, goto, for each, on failure): not governed, but recorded in the behavioral ledger

Every step execution, regardless of type, produces a StepRecord in the behavioral ledger with timing, inputs, outputs, and hash chain data (Inv 0, Inv 6).

Translations

Language	Keyword
English	implements
Spanish	implementa
French	implemente
German	implementiert
Japanese	実装
Chinese	实现
Korean	구현

See also

• compute - Pure computation steps
• ask … using - LLM reasoning steps
• action - Effect steps
• decide - Branching logic
• accepts - Input contract
• responds with - Output contract
• ensures - Governance rules