Crate everruns_engine 

Shared turn planning and Input/Reason/Act execution for hosts in the Everruns ecosystem.

TurnExecution owns the serializable state machine shared by every execution driver. Given a parsed ActivityOutcome and host-resolved HostFacts, it returns the next TurnPlan and ordered TurnLifecycleEffects. Framework applications use everruns; this focused crate lets in-process, durable, and custom hosts share one turn model.

Planning is sans I/O: hosts pass resolved facts and perform returned lifecycle effects. The execution phases are portable async algorithms over injected core/provider contracts such as everruns_core::MessageRetriever, everruns_core::EventEmitter, and everruns_core::ToolExecutor. The crate does not select stores, transports, processes, or deployment services. Execution is the driver boundary. everruns-host implements it with process-local state; everruns-durable implements it with checkpointed state between scheduled activities. Both share phase behavior and turn transitions without introducing an engine-to-host dependency.

Example

use everruns_engine::{TurnPlan, TurnState};

fn accepts_plan(_state: &TurnState, _plan: &TurnPlan) {}

Modules

native_async

Opt-in native-call coordinator for streaming hosts. Normal Reason/Act hosts keep synchronous execution unless they install this coordinator explicitly.

Structs

ActAtom

Atom that executes a batch of tool calls via the [tool_scheduler]

ActInput

Input for ActAtom

ActOutcome

Parsed act activity output the planner decides over.

ActPlan

Engine-owned act scheduling payload.

ActResult

Result of the ActAtom

ActSchedulingFacts

Session facts the host pre-resolves for the reason→act scheduling case.

ClientSideToolHook

Hook that handles client-side tool calls from the ReasonResult.

ConnectionSetupHook

Hook that detects tools requiring user connection setup and emits synthetic setup_connection tool calls so the client can prompt the user.

ExecutionContext

Correlation and resource identity for one execution phase within a turn.

ExecutionTransition

One engine decision and the ordered lifecycle effects it requires.

HostFacts

Host-resolved facts the engine needs but cannot fetch itself.

InputAtom

Atom that retrieves user input for a turn

InputAtomInput

Input for InputAtom

InputAtomResult

Result of the InputAtom

NativeExecutionCounts

Internal continuations accounted as part of one scheduled Reason activity.

OutputHardLimitHook

Infrastructure hook that enforces a hard 64 KiB ceiling on tool result text.

ReasonAtom

Atom that calls the LLM model for reasoning

ReasonInput

Input for ReasonAtom

ReasonResult

Result of the ReasonAtom

ToolApprovalPauseHook

Hook that parks the turn when a hard approval gate deferred a call.

ToolCallResult

Result of a single tool call execution

TurnExecution

Default stateful implementation of the shared turn execution contract.

TurnState

Host-owned state carried across turn phases.

Enums

ActivityOutcome

Typed, parsed activity output the engine plans the next step from.

PhaseEffect

One effect produced during Input/Reason/Act execution.

PostActAction

Action a post-act hook wants ActAtom to perform.

TurnLifecycleEffect

A lifecycle side effect the engine decided must be recorded, described as data rather than performed.

TurnPlan

Generic next-step decision for a host turn.

Traits

Execution

Common contract implemented by immediate and durable turn executions.

PhaseEffectSink

Host-applied sink for live phase effects.

PostActHook

Hook that runs after ActAtom finishes executing tools.

Functions

act_pauses_turn

Whether an act outcome parks the turn, given the session’s pause hints.

capability_usage_records

The capability.usage records for the turn’s resolved capabilities and the tools they expose: the attribution every reason backend reports, whichever loop runs the model.

configured_max_tool_concurrency

Resolve the effective tool concurrency cap, honoring the EVERRUNS_ACT_MAX_TOOL_CONCURRENCY env override (clamped to >= 1).

has_pending_tool_approval

True when an act left a hard approval request pending.

plan_after_act

Plan the next step after an act activity finishes.

plan_after_process_input

Plan the reason step that follows a completed process_input activity.

plan_after_reason

Plan the next step after a reason activity finishes.

plan_next_turn

Plan the next host step after an activity finishes.

reason_schedules_act

Does this reason outcome schedule an act phase?