The Problem
Most agent builders treat the database as an afterthought. The result: message storage schemas that choke on multi-modal LLM traffic, agent state that lives in ad-hoc JSON blobs, and zero visibility into whether the agent actually completes tasks. Acontext targets teams building agents at scale (think 100k+ users) who need a purpose-built context layer instead of bolting one onto a generic Postgres instance.
What This Does
Acontext is a context data platform with three pillars: store, observe, and learn. The Python SDK (src/client/acontext-py/src/acontext/) provides typed resource clients for sessions, disks, skills, and spaces—each with sync and async variants. The Go CLI (src/client/acontext-cli/) handles local development setup, spinning up the full stack via Docker Compose (src/client/acontext-cli/internal/docker/docker-compose.yaml).
The platform core runs on Postgres, Redis, and S3, with a Helm chart (charts/acontext/) for Kubernetes deployment. The observe layer tracks tasks per session and exposes success rates through a dashboard. The learn layer turns successful runs into reusable tool-use SOPs via an "experience agent."
How To Use It
Setup: The Python SDK is a standard pyproject.toml package—install with pip install acontext or uv. The CLI is Go-based; build via the Makefile in src/client/acontext-cli/.
Configuration: The CLI's create.go command scaffolds a local environment. Environment variables for Docker setup live in src/client/acontext-cli/internal/docker/env.go. For production, charts/acontext/values.yaml is the config surface—set Postgres, Redis, and S3 credentials there.
Running it: The CLI entry point is src/client/acontext-cli/main.go. The create command bootstraps the stack; upgrade handles version bumps. Python usage is straightforward:
from acontext import Acontext client = Acontext() session = client.sessions.create() client.messages.add(session.id, role="user", content="Hello")
Real-World Use
A customer-support agent handling thousands of concurrent sessions. Each session gets a dedicated Acontext session ID. Messages stream in via the async client (async_client.py), artifacts save to disk resources, and the dashboard shows task completion rates per session. When the agent nails a complex resolution, the experience agent captures it as a skill—next time, the agent reuses that SOP instead of reasoning from scratch.
Code Health & Issues
Med - Python SDK lacks type stubs for most resources: client.py and resource files have no return type annotations on several public methods, which hurts IDE support and runtime validation. Med - No integration tests for the core platform: 15 test files exist, but they cover CLI internals (template download, git init) and Python client unit tests. No tests exercise the actual Postgres/Redis/S3 stack. Low - Docker Compose bundles three heavy dependencies: Postgres, RabbitMQ, and Redis in one file (docker-compose.yaml). Local dev requires significant memory; no resource limits specified. Low - Helm chart pins third-party subcharts: Chart.lock and .tgz files for Postgres, RabbitMQ, and Redis are vendored, which is safe but makes upgrades awkward. Low - The onboard/ directory mixes Python and TypeScript: onboarding.py and onboarding.ts suggest parallel implementations that could drift.
The Bottom Line
Acontext is a serious attempt at solving a real problem—context persistence and observability for production agents. The SDK surface is well-organized and the CLI lowers the barrier to local development. It's early-stage (0 stars, no tagged releases visible), so expect rough edges and missing operational tooling. Best suited for teams already running agents in production who want a managed context layer rather than building one in-house.