crates.io
crates.io listing for langcontinuation, a continuation-passing workflow engine for durable Rust programs and AI agent systems.
Last verified:
What is crates.io?
crates.io hosts langcontinuation, a continuation-passing workflow engine for durable Rust programs, especially designed for AI agent systems that need to call models, run client-side tools, wait for people, fork into concurrent branches, serialize their exact state, and resume later. It is not a large agent framework but rather provides a small set of durable control-flow primitives while leaving prompts, tools, storage, scheduling, and provider policy in your code.
Key features include workflows as ordinary Rust functions made durable through explicit continuations, a Workflow struct that stores a stable run id, JSON environment, current step, and continuation stack, a Trampoline that runs local steps until the workflow halts or reaches a suspension boundary, and support for Anthropic messages, client-side tools, human input, and fork/join operations. The crate supports both a live executor (default) and a Postgres-backed batch executor (behind the batch feature).
This crates.io listing is for developers who want the building blocks behind an agent runtime without handing over the shape of the application. It is ideal for agent applications needing durable chains, tool loops, human review, branch isolation, retries, or a choice between live and batch execution. Use it when you want durable memory, checkpointing, inspection, replay, or routing through provider batch APIs.
crates.io pricing
Pricing model: Freemium
Free - This is an open-source Rust crate available on crates.io with no pricing tiers. The crate is free to use with the live executor included by default. The Postgres-backed batch executor is available behind the optional 'batch' feature flag.
crates.io pros
- Durable execution state serialization across local calls and external suspensions
- Supports Anthropic messages as first-class built-in boundary
- Client-side tool calls run inline with registered Tool values
- Human input suspension with durable persistence and resume_human support
- Fork/join parallel branches with isolated branch workflows
- Batch executor with Postgres-backed Anthropic Message Batches
- Stable run id for replay-deterministic execution
- Typed environment with push_env and from_env macros
- generate_goto macro for trampoline-compatible functions
- Lightweight control-flow primitives without hidden agent loop
- Checkpoint any Workflow returned in any WorkflowResult
- Choice between live Executor or batch Executor or custom runtime
- ToolCallId provides idempotent deduplication for side-effecting tools
- Observability context for workflow event summarization and validation
- Cancellation-safe batch execution with recoverable database transitions
crates.io cons
- OpenAI live execution intentionally not implemented yet
- Live executor does not handle OpenAI (only batch persistance)
- Macros encode keys from identifiers and type-token spelling as string convention
- generate_goto macro currently supports limited forms (1-2 inputs plus continuation)
- Batch executor assumes single worker process per database queue
- At-least-once tool execution (no checkpoint between tools and resume)
- Orphan provider batch can exist if future canceled before batch id committed
- No type-level schema for environment keys (string convention only)
Frequently asked questions about crates.io
What is langcontinuation and what does it do?
langcontinuation is a continuation-passing workflow engine for durable Rust programs, especially AI agent systems. It makes ordinary Rust functions durable through explicit continuations, allowing workflows to serialize their exact state and resume later after calling models, running tools, waiting for humans, or fork/join operations.
When should I use langcontinuation?
Use langcontinuation when you want the building blocks behind an agent runtime without handing over the shape of the application. If you need durable chains, tool loops, human review, branch isolation, retries, or choice between live and batch execution, those are first-class here. For single prompt to one provider, just call the provider API directly.
What is the difference between live and batch executors?
The live executor (available by default) runs workflows immediately through built-in live provider integrations like Anthropic messages. The batch executor (behind the 'batch' feature) is SQLx/Postgres-backed for Anthropic Message Batches, storing work in Postgres and flushing provider batches according to configuration for lower-cost batch execution.
How does human input work in langcontinuation?
Human input is first-class at the trampoline boundary. Use Continuation::human to record a HumanRequest and the function that should receive the answer. The scheduler can match WorkflowResult::Human, persist the paused workflow, show the prompt to an operator, and later call Trampoline::resume_human with the answer. The live executor returns 'human-input-required' when a workflow reaches a human request.
How do fork/join branches work?
Fork/join branches inherit the parent environment and start at caller-provided function names. Each branch is a separate Workflow with its own run id. Both branches must halt to resume the parent. The live executor runs branches concurrently. The batch executor stores the parent, tracks children, and resumes the join when both halt. Environment merging accepts one-sided changes, identical writes, but rejects conflicting writes to the same key.
How are tool calls handled?
Client-side tool calls are first-class. Register a Tool with Trampoline::register_tool under the name the model uses. When an Anthropic response calls tools, the receiver raises a Continuation::tool_call suspension (often through dispatch_tool_uses). The runtime resolves each tool_use by name, runs it, and resumes with ToolResultBlock values. Each tool receives a durable ToolCallId for replay-deterministic deduplication.
How does continuation and resumption work?
Continuation choices make the next step explicit: Continuation::goto continues with what's on the continuation stack, Continuation::halt ends the workflow, Continuation::call schedules another named function, Continuation::anthropic records an Anthropic request, Continuation::human records human input, Continuation::tool_call records tool_use blocks, and Continuation::fork_join creates two branches and rejoins through a named function.
What examples are available?
Examples include: three_stage_support_pipeline (local example, no model needed), durable_tool_call (minimal tool-calling agent live), tool_calling_and_web_searching (larger fork/join tool-calling demo live), and durable_human_example (shows durability boundary without model API key). Run with 'cargo run --example <name>' or 'cargo test' for test suite.
What are the known limits and limitations?
Current macros encode keys from identifiers and type-token spelling as string convention rather than type-level schema. generate_goto supports limited forms (1-2 typed inputs plus continuation). Live executor handles Anthropic and fork/join but OpenAI live execution is intentionally blocked until suitable Rust OpenAI client exists. Batch executor has at-least-once tool execution and assumes single worker per queue. Provider submission is at-least-once with possible orphan batches if canceled before commit.