Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to use
Use when you want to write effectful code that looks and behaves like
synchronous code, while still handling asynchronous tasks, errors, and complex
control flow such as loops and conditions.
Generator functions work similarly to async/await but keep errors,
requirements, and interruption in the Effect type. You can yield* values
from effects and return the final result at the end.
Provides dependencies to an effect using layers or a context. Use options.local
to build the layer every time; by default, layers are shared between provide
calls.
Run agents and attached subagents with in-memory conversation history.
Provide once around the parent program and all child handler Layers so siblings
share history and one reservation ledger. Reuse a Thread ID to continue a conversation.
Conversations can span any number of Runs within the store's capacity limits.
Use scoped for disposable request workflows within this shared store.
Each independent Layer build owns fresh state; state is released when its Scope closes.
Process loss loses history and active execution; this Layer provides no crash recovery.
Models, tool handlers, and provider clients remain application-supplied. Default
IDs need no Layer; enclosing ID and context-preparation overrides are preserved.
For storage-backed history, provide PersistentHistory.layer and a shared
SubagentReservationsMemoryLive instead. Durable hosts own their own assembly.
layer));
Here, planner is an agent definition. Supply its model and tool
services around the program; see getting started for
complete provider setup. No storage package is needed.
Provide the Layer once around the conversation, or use one ManagedRuntime for a
long-lived application. A new Layer acquisition creates a separate store. Reuse the
returned threadId for follow-ups; omitting it starts a new conversation.
InMemory.layer shares conversation history and attached-subagent reservations.
History records complete messages and tool batches as execution advances. If a
later step fails or is interrupted, earlier recorded updates remain available.
State stays available while the application Scope remains open, within the store’s
capacity limits. Closing the Scope or losing the process loses that state. See
in-memory conversations for limits and
history inspection.
@yielded/agent-storage-memory supplies implementations of the canonical
ThreadStore, SubmissionLedger and SettlementPublisher ports. These are useful
for adapter tests and custom runtime assemblies. The ledger and publisher share the
thread store’s mutation boundary. Assemble them with
MemorySubmissionLedgerLive.pipe(Layer.provideMerge(MemoryThreadStoreLive)) so each
assembly owns one store. They are separate from the conversation store supplied by
InMemory.layer; the submission ledger reports itself as non-durable.
When using memoryMessageDeliveryStoreLayer, merge it with the ledger before
providing the same MemoryThreadStoreLive. Thread exports then identify retained
deliveries as external obligations, and import refuses to overwrite delivery work.
MemoryThreadStoreLive, imported from
@yielded/agent-storage-memory/memory-thread-store, provides ThreadStore and
requires a platform Crypto Layer. Providing it to PersistentHistory.layer uses
the whole successful-run commit policy,
while still keeping all records in memory.
For history that survives a restart, choose SQLite or Postgres.
To recover unfinished work as well, use a durable platform.