Pure protocollash-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 runtimelash-core
Owns LashRuntime, Session, SessionGraph, EffectHost / RuntimeEffectController, ProcessRegistry, ProcessCancelAbility, 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, handle grants, 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
Facadelash
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 DTOslash-remote-protocol
Owns versioned serde/schemars DTOs for exposing Lash through service boundaries: RemoteTurnRequest, RemoteTurnResult, 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 Applicationlash-cli
The independent lash-cli repository owns the lash binary, configuration, TUI, resume/fork, autonomous flows, provider materialization, concrete plugin composition, export, file indexing, and CLI-specific profiling.
external: SamGalanakis/lash-cli
Protocol pluginsstandard + 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 pluginsOpenAI, 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 cratesdefault tools + subagents + LLM helpers + MCP + tool-output budgeting
Standard tools (file read/glob/edit/write, shell, web search/fetch), subagents, llm_query, plan mode, prompt context, observational memory, rolling-history compaction, MCP servers, and the built-in tool-output budgeter register through tool providers or plugin factories. lash-tool-support holds shared path-resolution and static-provider helpers. The fff-backed local grep provider and large-catalog discovery pipeline are Host Application policy owned by the external lash-cli workspace.
lash-standard-plugins, lash-subagents, lash-llm-tools, lash-tools, lash-tool-support, lash-plugin-*, lash-plugin-tool-output-budget
PersistenceStore 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 session execution lease, fenced commit, claim, 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 UICLI, TUI, UI surfaces
The CLI bootstraps runtime, plugins, and providers, then renders the authoritative SessionReadView through ChronologicalProjection into UiTimeline.
external: lash-cli workspace
Inspection toolstrace + runtime performance
lash-trace defines standard and extended JSONL trace records, opt-in Lashlang process-tracking records, and the optional OpenTelemetry sink. lash-trace-viewer is a standalone tool that renders JSONL traces into a self-contained HTML browser. 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-trace-viewer, lash-perf
Applied workflowsexternal host workflows
Autoresearch is a CLI-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: lash-cli, lash-evolve