Runifold frequently asked questions
Get concise answers about APIs, providers, Runs, Tools, state, reliability, production use, and versions.
Starting and choosing
Is Runifold only an Agent framework?
No. Agent is one surface over the same execution kernel. You can use the model
protocol, Provider Runtime, typed Tools, retrieval, MCP, evaluation,
observability, or durable Workflow runtime independently.
Should I depend on runifold or a narrow crate?
Start with the runifold facade and enable only required features. Use narrow
crates when you are building an adapter, minimizing a specialized dependency
boundary, or publishing reusable infrastructure.
Which API should I start with?
Use prompt_text for one text result, prompt when you need the full outcome,
stream for incremental events, and run with an explicit RunContext at
production boundaries. See Choosing an API.
Providers and models
Can I switch providers without changing application code?
Core requests, Runs, Agents, and Tools are provider-neutral, but capabilities
are not identical. Switch the client and model configuration, then rerun
capability and quality verification.
Does OpenAI-compatible mean identical behavior?
No. It means an endpoint resembles a wire protocol. Streaming event shape,
Tool behavior, structured output, usage, reasoning, and errors can differ.
Why does Runifold not read credentials automatically?
Applications own secret ingress. Explicit construction makes server, test,
gateway, browser, and multi-tenant boundaries visible and prevents a library
from silently reading ambient authority.
Runs, Tools, and state
What is the difference between an Agent and a Run?
An Agent describes model behavior, Tools, and turn policy. A Run is one
execution tree with identity, budget, deadline, cancellation, capabilities,
and journal state.
Does registering a Tool authorize it?
No. Registration says the Tool exists. The Run capability set decides whether
this execution may call it.
Is conversation history the same as a checkpoint?
No. Conversation history is model context. A checkpoint records recoverable
execution state. An event journal records what happened.
Reliability and production
Does Runifold guarantee exactly-once external effects?
No general runtime can guarantee that for an arbitrary remote system.
Runifold coordinates write-ahead records, idempotency keys, result replay, and
conservative recovery so applications can handle ambiguity explicitly.
When should I use a Workflow instead of an Agent?
Use an Agent when the model chooses the next model/Tool turn. Use a Workflow
when the application owns ordered steps, branches, waits, recovery, or durable
task state.
Is Runifold production-ready?
The project is pre-1.0. Production adoption should pin the release, verify the
exact Provider/model/features in your environment, and use the published
reliability evidence instead of assuming every surface has equal maturity.
Versions and support
Which version do these docs describe?
The current site and compile-checked examples target runifold 0.9.0.
How should I upgrade before 1.0?
Pin an exact minor release, read the changelog and migration notes, update all
Runifold crates together, compile examples, run deterministic tests, then run a
narrow live Provider smoke test.
For build or runtime failures, continue to Troubleshooting.