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
| Variant | Syntax | Purpose |
|---|---|---|
ask ... using | ask name, using: "provider:model" | Send a task to an LLM |
ask ... from | ask name, from: "machine_path" | Call an effect machine |
ask ... of | ask 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
| Config | Required | Description |
|---|---|---|
from | Yes | Machine path. Stdlib: "@mashin/actions/http/get". Org: "@myorg/billing/charge". Local: "my_helper". |
| Input keys | Varies | Key-value pairs passed as input to the target machine. |
returns | No | Output schema. Fields the called machine should return. Used for compile-time validation. |
assuming | No | Mock return values for test/simulate mode. |
to | No | Interpretation 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 itask description, from: email_triage, to: explain
// Estimate execution cost without runningask 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 metricsask metrics, from: email_triage, to: evaluate dataset: test_emailsWith 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):
- Permission check: the machine must have
machine.callcapability (or the specific capability required by the target machine) - Directive emission: the call emits a directive mediated by the governance interpreter
- Behavioral ledger: the target machine, input keys, and execution result are recorded
- Transitive governance: the called machine runs under its own governance rules. Governance does not “leak” across machine boundaries.
- 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
| Language | Keyword |
|---|---|
| English | ask |
| Spanish | pregunta |
| French | demande |
| German | fragt |
| Japanese | 聞く |
| Chinese | 问 |
| Korean | 묻다 |
See also
- ask … using - Send tasks to LLM providers
- action - Alternative effect step syntax
- ask … of - Query running machine state
- implements - The section where ask steps live
- ensures - Permission declarations