Guides
Operate and debug session documents
Keep an accessible operational record for every conversation, diagnose incidents from one document, and reproduce failures safely without a separate PicoFlow observability service.
Every PicoFlow turn restores and saves one versioned session document. That document is both the durable conversation record and the first place an operator should look when something goes wrong. It contains the active step, business state, named model memories, transition sequence, effective model configuration, token totals, status, and structured log, warning, error, debug, and verbose records.
PicoFlow does not require a separate PicoFlow cloud or observability control plane for this baseline. Keep the application and its session store in the enterprise-approved network and database boundary. Model requests still follow the provider you choose; an air-gapped deployment needs an internally hosted model or an approved private endpoint.
Start with one incident record
For a slow, failed, or surprising customer turn, load the session document by its session ID. Read these fields together before changing code or retrying a request:
| Question | Fields to inspect |
|---|---|
| Is the session live, complete, or aborted? | runStatus, saveOn, createdOn |
| Which workflow and stage own the case? | flow.name, flow.currentStep, flow.sequence |
| What facts and customer/model context were present? | flow.steps[].state, flow.memory, flow.context |
| Which model behavior was in effect? | flow.model, per-step model overrides, tokens |
| What did the runtime record? | log, warn, error, debug, verbose |
| Could another writer have won? | revision, conflict errors, saveOn |
This is an application-readable case file, not a replacement for every distributed trace, metric, alert, or retention policy. It answers the high-value question first: what happened to this customer conversation?
Build internal operational metrics from the document database
All PicoFlow flows use the same outer document shape. A database query or scheduled aggregation can therefore build portfolio views without first normalizing each workflow’s custom graph state.
Useful metrics include:
- running, completed, and aborted sessions by
flow.name; - error and warning rates over
saveOntime windows; - active sessions grouped by
flow.currentStepto find stalled stages; - token totals by flow, model, tenant field, or time period;
- long-lived sessions from
createdOntosaveOn; and - repeat failures grouped by error code, active step, or model selection.
Choose indexes and retention rules for the queries your operations team actually runs. The runtime supplies a stable document shape; it does not provision indexes, dashboards, alerts, or governance policy automatically. Treat message histories, tool payloads, and diagnostic records as potentially sensitive data when assigning access and retention.
Reproduce a production failure safely
The session document makes a rare production-only failure portable. Copy the evidence into an isolated environment rather than trying to reconstruct a conversation from screenshots, logs, and a trace ID across several systems.
production session document
-> copy and redact under incident controls
-> import into isolated test storage with a new session ID
-> set a runnable status
-> choose flow.currentStep
-> restore or deliberately trim relevant step state and memory
-> replace live credentials and side-effecting tools with sandbox/test versions
-> replay the triggering request
-> compare the response, saved state, logs, tokens, and transition sequence
Never replay a production document in place. A replay can otherwise repeat a booking, payment, email, or other external effect. Use a new ID, isolated storage, test credentials, and mocked or idempotent tools.
Resuming is not automatic rollback
Changing flow.currentStep chooses where a copied session resumes. It does not rewind step
state or message history. Exact rollback requires an earlier retained document snapshot. Without
one, deliberately restore or trim the relevant state and memory before replaying.
The flow.sequence trail explains the path that led to the current state, but it is not a full
history of state snapshots. For a prior-state replay, retain a versioned copy under your own
incident and retention policy.
A simpler observability default, not a capability claim
LangGraph can run privately, use a checkpointer, and integrate with LangSmith, OpenTelemetry, application logs, or another internal observability platform. PicoFlow’s distinction is that a session document already supplies a common case-record and diagnostics baseline for every flow.
With a direct graph, a team can build an equivalent operational view. It must decide what state, model metadata, logs, token records, session identifiers, retention, metrics, and replay workflow to capture—and then standardize that work across applications. PicoFlow supplies the outer document and lifecycle convention before a second or third conversation is built.