Skip to main content
Async state stores provide non-blocking key-value and hash persistence so native-async backends never block the event loop.
The user asks a follow-up; an async state store fetches cached preferences without blocking other agents on the same loop.

Quick Start

1

Subclass AsyncStateStore

Implement a native-async backend by inheriting from AsyncStateStore:
2

Wire It Into an Agent

Pass the store through the persistence config so the agent dispatches async calls natively:
These ABCs give third-party native-async backends a formal interface to subclass. Shipped async backends (e.g. AsyncMongoDBStateStore) still subclass the sync StateStore and route through run_sync wrappers; they will migrate onto the async ABC in a follow-up PR. Dispatch via PraisonAIDB._dispatch_async continues to work for both styles.

How It Works

A sync caller inside a running loop dispatches to the async store through PraisonAIDB._dispatch_async.

Abstract Methods

Concrete helpers — get_json(key), set_json(key, value, ttl=None), __aenter__, __aexit__ — ship on the ABC and need no override.

Configuration Options

Persistence API Reference

Complete method signatures for AsyncStateStore and sibling stores

Common Patterns

Custom Async Backend Inheritance

Subclass AsyncStateStore (not StateStore) when your backend is natively async:

async with Context Manager

The ABC defines __aenter__ / __aexit__, so async with closes the store automatically:

get_json / set_json Helpers

The concrete helpers serialize to JSON on write. On read, a stored str is parsed with json.loads; any non-str value is returned as-is:

Best Practices

Inherit the async ABC so isinstance() dispatch awaits your methods directly:
Use async with or await store.close() to release connections:
Keep a single store async end-to-end:

Async Conversation Store

Sibling async pattern for conversation sessions

Persistence Overview

Architecture and backend options