Skip to content

ask ... from

ask … from

Request data or an operation from an effect machine. The second variant of the ask step, ask ... from invokes another machine and optionally declares a returns schema for the response. It is the declarative alternative to action ... call, reading more naturally when the intent is “ask this machine for something” rather than “perform this action.”

When to use

Use ask ... from when you need to:

  • Call another machine and expect structured output
  • Compose machines together (one machine calling another)
  • Invoke stdlib effect machines with a clear request/response contract
  • Use interpretation modes (to:) to explain, simulate, or evaluate a machine

Use action ... call when the emphasis is on performing a side effect rather than requesting data. Use ask ... using when the task requires LLM reasoning. Use ask ... of to query the current state of a running reactive machine.

Three ask variants

VariantSyntaxPurpose
ask ... usingask name, using: "provider:model"Send a task to an LLM
ask ... fromask name, from: "machine_path"Call an effect machine
ask ... ofask name, of: "running_machine"Query running machine state

Syntax

ask <name>, from: "<machine_path>"
<input_key>: <value>
...
returns
<field> as <type>
assuming
<field>: <mock_value>

With interpretation mode

ask <name>, from: "<machine_path>", to: <mode>
<input_key>: <value>

Built-in modes: explain, cost, simulate, evaluate, verify, improve. Any other value resolves as a user-defined interpreter machine.

Configuration

ConfigRequiredDescription
fromYesMachine path. Stdlib: "@mashin/actions/http/get". Org: "@myorg/billing/charge". Local: "my_helper".
Input keysVariesKey-value pairs passed as input to the target machine.
returnsNoOutput schema. Fields the called machine should return. Used for compile-time validation.
assumingNoMock return values for test/simulate mode.
toNoInterpretation mode. Changes how the target machine is processed (e.g., explain, simulate).

Examples

Call a stdlib effect machine

machine data_fetcher
accepts
api_url as text, is required
responds with
items as list
total as number
implements
ask fetch_data, from: "@mashin/actions/http/get"
url: input.api_url
headers: {"Accept": "application/json"}
returns
body as map
status as number
assuming
body: {items: [{id: 1, name: "Item 1"}], total: 1}
status: 200
compute extract
{
items: steps.fetch_data.body.items,
total: steps.fetch_data.body.total
}

Compose machines

machine order_pipeline
accepts
order_id as text, is required
implements
ask validate_order, from: "@myorg/orders/validate"
order_id: input.order_id
returns
valid as boolean
errors as list
assuming
valid: true
errors: []
ask calculate_shipping, from: "@myorg/shipping/calculate"
order_id: input.order_id
destination: input.destination
returns
cost as number
estimated_days as number
assuming
cost: 9.99
estimated_days: 3
compute summary
{
order_id: input.order_id,
shipping_cost: steps.calculate_shipping.cost,
delivery_estimate: steps.calculate_shipping.estimated_days
}

Interpretation modes

// Explain what a machine does without executing it
ask description, from: email_triage, to: explain
// Estimate execution cost without running
ask projection, from: email_triage, to: cost
// Run with mocked effects (no real API calls)
ask dry_run, from: email_triage, to: simulate
email: "test message"
// Evaluate against test cases and metrics
ask metrics, from: email_triage, to: evaluate
dataset: test_emails

With reasoning chain composition

machine research_with_reasoning
accepts
question as text, is required
implements
ask think_through, from: "@kits/reasoning/chain_of_thought"
question: input.question
returns
reasoning as text
conclusion as text
assuming
reasoning: "Step 1: Consider the question..."
conclusion: "The answer is..."
compute format
{
answer: steps.think_through.conclusion,
reasoning_trace: steps.think_through.reasoning
}

Governance

Every ask ... from step is governed (Inv 3: Governance Mediation):

  1. Permission check: the machine must have machine.call capability (or the specific capability required by the target machine)
  2. Directive emission: the call emits a directive mediated by the governance interpreter
  3. Behavioral ledger: the target machine, input keys, and execution result are recorded
  4. Transitive governance: the called machine runs under its own governance rules. Governance does not “leak” across machine boundaries.
  5. Trust ceiling: the caller’s trust level constrains what the callee can do

In test mode, assuming values are returned instead of calling the real machine.

Translations

LanguageKeyword
Englishask
Spanishpregunta
Frenchdemande
Germanfragt
Japanese聞く
Chinese
Korean묻다

See also