Execution Semantics & The Four Primitives

Not every model call has the same authority or lifecycle.

The Four Primitives

Primitive	Question	Authority
app.agent()	What does the user mean now?	Produces conversation text or proposes one of the currently valid runtime actions
.reason()	What bounded semantic result should this execution derive?	Produces structured model output that becomes state only after the runtime accepts it
.step()	What can deterministic application code derive?	Returns an object merged into execution state
.capability()	What external effect should the host perform?	Executes only after command intent is committed when storage is configured

Agents and reason nodes can be probabilistic. Neither directly owns application truth.

Conversation vs. Execution

Agent turn
conversation + projection + valid actions
        │
        ▼
action proposal
        │ schema and fresh-boundary validation
        ▼
workflow transition
        │
        ▼
durable execution fact

Conversation is temporary reasoning input. Once a validated action advances a workflow, the resulting events and execution state—not the transcript—are authoritative.

Reasoning in the Current Beta

workflow.reason("classify-request", {
  instruction: "Classify the support message in execution context.",
  schema: {
    type: "object",
    properties: {
      category: { type: "string", enum: ["BILLING", "TECHNICAL", "OTHER"] },
    },
    required: ["category"],
  },
});

The current Session host dispatches the compiled instruction, schema, and accumulated kernel context to the configured model adapter. Dynamic prompt, context, and projection selectors remain reserved authoring fields and are not evaluated by this Beta host.

This limitation is important: do not claim that a .reason() projection is an enforced data-minimization boundary today. Use a dedicated workflow with intentionally narrow state if model-visible data must be restricted.

Events vs. Traces

Execution events and diagnostic traces serve different purposes:

Durable event log	Diagnostic trace
Records what became execution truth	Explains handler/model activity
Reduced into ExecutionState	Never participates in transitions
Required for replay	Optional operational telemetry
Stored through RuntimeStore	Sent to configured trace sinks

The SDK can capture model request/response information according to observability settings. It does not currently persist the cryptographic reasoning-attribution hash record described in earlier designs.

Schema Boundaries

• Workflow input is validated before the start transition.
• Wait input is validated before INPUT_RECEIVED is committed.
• Agent actions are checked against the fresh action surface.
• Model/provider output must not be treated as application truth outside these runtime boundaries.

Next Steps

• Workflows — Exact node behavior.
• Agents — Action authority and projections.
• Observability — Events versus traces in practice.
• Durability Guarantees — Contractual Beta guarantees.