modules/crates

The runtime workspace is split by responsibility: pure protocol, async runtime, remote service DTOs, protocol drivers, provider transports, plugin/tool catalogs, tracing, and application-facing support crates. The first-party CLI Host Application is shown as an external consumer.

Crate Families

The high-value responsibility groups to inspect before changing behavior. For reviewable dependency and ownership rules, see the per-crate invariants.

Pure protocol

lash-sansio

Owns TurnMachine, Effect, Response, TurnDriverPreamble, prompt templates, messages, attachments, the TurnOutcome::{Finished, AgentFrameSwitch, Stopped} contract, canonical tool-call output, and tool definitions/output contracts. It does not depend on Lashlang; runtime-facing protocol build input lives in lash-core, while Lashlang host environments live in the RLM/Lashlang runtime path. Top-level files cover turn, prompt, plugin, attachment, session, turn drivers, tool contracts, tool output, and tool catalogs; the sansio/, session_model/, and llm/ subdirectories hold the state machine, durable model, and provider request types.

lash-sansio
Async runtime

lash-core

Owns LashRuntime, Session, SessionGraph, EffectHost / RuntimeEffectController, ProcessRegistry, ProtocolBuildInput, ProcessEngine, and the RuntimePersistence contract, plus tool dispatch, live provider handles, attachments, tracing, runtime controls, and AgentFrame switch-following turn execution. Process support is explicit host configuration: core owns the generic process registry, worker, leases, observer edges, and opaque engine dispatch; protocol/language runtimes decide which language abilities those mechanisms expose. No knowledge of MCP, user config files, provider credential files, or any host concerns; those live in higher layers. lash-restate supplies the first-party durable EffectHost; the same controller boundary can be implemented by other workflow runtimes.

lash-core, lash-restate
Facade

lash

App-facing API on top of lash-core. Provides LashCore, LashCoreBuilder, LashSession, SessionBuilder, TurnBuilder, mode presets, and typed-plugin binding helpers. Host applications use this crate (not lash-core directly) for runtime construction, chat/task sessions, persistence wiring, and semantic turn streaming.

lash, examples/*
Remote service DTOs

lash-remote-protocol

Owns versioned serde/schemars DTOs for exposing Lash through service boundaries: RemoteTurnRequest, RemoteTurnReport, RemoteLlmRequest, RemoteLlmResponse, RemoteTurnActivity, RemoteSessionObservation, RemoteSessionObservationEvent, RemoteLiveReplayGap, prompt layer patches, trigger occurrence/subscription envelopes, and remote tool grants. Tool execution is not a remote DTO path; hosts run remote work from their own ToolProvider. The facade reexports the DTO surface as lash::remote; optional core-conversions helpers live in the standalone crate.

lash-remote-protocol
External Host Application

terminal host

An independent host repository owns its binary, configuration, TUI, resume/fork, autonomous flows, provider materialization, concrete plugin composition, export, file indexing, and product-specific profiling.

external repository
Protocol plugins

standard + rlm

Standard drives native provider tool calls. RLM extracts lashlang code fences, runs persistent REPL state with read-only host bindings projected into scope (history and ProjectionRef-backed app globals), renders execution instructions only from the effective LashlangHostEnvironment, masks fence streaming, provides the continue_as AgentFrame switch control tool, and records the RLM trajectory. Both protocols return terminal outcomes; shared runtime code writes final prose transcripts.

lash-protocol-standard, lash-protocol-rlm, lashlang, lash-rlm-types
Provider plugins

OpenAI, Codex, Anthropic, Google

Each provider implements state, auth, readiness, transport, and model policy components behind ProviderHandle. The CLI wires provider factories for the compiled-in kind names (anthropic, openai, openai-compatible, codex, google_oauth) directly. Shared HTTP plumbing lives in lash-llm-transport (client build, timeouts, SSE framing, usage merge), and OpenAI-style JSON Schema projection in lash-provider-openai’s schema module.

lash-provider-*, lash-llm-transport
Tools + plugin crates

default tools + subagents + LLM helpers + MCP + tool-output budgeting

Standard tools (shell and web search/fetch), subagents, llm_query, prompt context, rolling-history compaction, MCP servers, and the built-in tool-output budgeter register through tool providers or plugin factories. lash-tool-support holds shared argument/schema and static-provider helpers. The fff-backed local grep provider and large-catalog discovery pipeline are Host Application policy, owned outside this workspace.

lash-standard-plugins, lash-subagents, lash-llm-tools, lash-tools, lash-tool-support, lash-plugin-*, lash-plugin-tool-output-budget
Persistence

Store interfaces + first-party adapters

RuntimePersistence, ProcessRegistry, TriggerStore, artifact stores, and attachment stores are generic host seams. lash-sqlite-store is the local first-party implementation; lash-postgres-store is the shared-worker first-party implementation; lash-s3-store stores attachment bytes in S3-compatible object storage; and lash-core’s FileAttachmentStore backs attachment blobs on disk. Hosts can implement the same traits for another database or object store as long as the advisory session execution lease, head-CAS commit, claim-ownership, idempotency, and blob-reference semantics hold. In-flight effect replay belongs to the active EffectHost.

lash-sqlite-store, lash-postgres-store, lash-s3-store
External host UI

CLI, TUI, UI surfaces

A terminal host bootstraps runtime, plugins, and providers, then renders the authoritative SessionReadView through ChronologicalProjection into UiTimeline.

external host workspace
Inspection tools

trace + runtime performance

lash-trace defines standard and extended JSONL trace records, opt-in Lashlang process-tracking records, and the optional OpenTelemetry sink. lash-perf owns reusable runtime profiling scenarios, phase measurement, stack-size matrix probes, aggregation, and guard reports. Product export, file indexing, and CLI profiling live in the external Host Application repository.

lash-trace, lash-perf
Applied workflows

external host workflows

Autoresearch is a host-owned plugin and UI extension. Generic optimization, evaluation, candidate worktrees, and mutable Harness Packages live in the separate lash-evolve repository so Lash and the evaluator remain external to candidate mutation.

external host, lash-evolve

Module Dependency Direction

Provider crates depend on runtime contracts; mode and plugin crates register behavior; the CLI composes the concrete app.

Crate families
flowchart TD CLI["external Host Application"] --> Facade["lash (facade)"] Facade --> Core["lash-core (runtime)"] Examples["examples / apps"] --> Facade Evolve["lash-evolve (external)
Harness Packages + evaluation"] --> Facade Facade --> Remote["lash-remote-protocol
versioned DTOs"] Core --> Sansio["lash-sansio"] Store["lash-sqlite-store
lash-postgres-store
lash-s3-store"] --> Core Modes["lash-protocol-standard
lash-protocol-rlm"] --> Core Modes --> Sansio Modes --> LangRuntime["lash-lashlang-runtime"] LangRuntime --> Core LangRuntime --> Lang["lashlang"] Modes --> Lang Modes --> RlmTypes["lash-rlm-types"] Plugins["lash-plugin-*
lash-llm-tools
lash-standard-plugins"] --> Core Mcp --> Core Subagents["lash-subagents"] --> Core Subagents --> RlmTypes Providers["lash-provider-*"] --> Core Perf["lash-perf"] --> Facade Perf --> Core Core --> TraceCore
read on ·