PowerContext

Context that stays with the work — across sessions, agents, and people.

English · 中文 · 日本語

Website · Quickstart · Manual startup · Integrations · Benchmarks · Interfaces

What is PowerContext?

PowerContext is an open-source context service for AI agents. It keeps the durable part of your work — decisions, constraints, evidence, progress — outside any single conversation, so the next session, the next agent, or the next person can pick up from the current state instead of rereading the transcript.

You can use it as a ready-to-run Server or embed the same contracts in another application:

Layer	What it owns	Use it when
Core protocol	Source, Artifact, and Trigger contracts	Embedding PowerContext or adding a component
Builtin runtime	Memory, Handoff, Experience, and Skill services, scheduling, inference, and supported storage backends	Running the standard local Server
Server and integrations	HTTP/MCP, Python Client, CLI, Dashboard, and Agent plugins	Connecting an Agent or application

Work rarely ends with whoever starts it. You hand a task to an agent, the agent gets part of the way, and later you or someone else takes over. The reasoning and current state often stay behind in that conversation. PowerContext moves them out of the conversation and into revisioned artifacts you can inspect:

Everything belongs to a Scope — one isolated Source journal, Memory lifecycle, review inbox, and Handoff history. A Scope ID selects data; it does not prove user identity, grant tool access, or authorize execution.

Scope
├── Source journal    # evidence: prompts, documents, work contracts, task outcomes
├── Memory            # atomic-memory/ARTIFACT_ID@REVISION — decisions, constraints, next steps
├── Review Inbox      # pending Experience and Skill candidates awaiting a decision
├── Handoff history   # handoff/ARTIFACT_ID@REVISION — work continuity across sessions
└── Topic Memory      # extracted in the background from eligible Sources

For Kubernetes deployments with external OceanBase, see the Helm chart and deployment guide.

Recordings show the running Dashboard and native Desktop preview in their light themes, using synthetic demonstration records.

Memory — decisions and constraints that outlive a session

Memory is a revisioned Artifact family for reusable decisions, constraints, facts, state, and next steps. An entry is active, forgotten, merged, or retired. Forgetting one through POST /v1/atomic-memory/lifecycle takes it out of active recall while its content and history stay available and restorable, without advancing the content revision. Explicit Memory writes need no model at all; extraction from captured Sources needs a configured generation pipeline.

"Don't refactor the old auth module — mobile is still using it." Context this expensive shouldn't depend on someone repeating it in every session.

Handoff — the current state, not the whole transcript

Handoff records work continuity as a four-step loop:

Work Contract → Prepared Handoff → Acknowledgement → Task Outcome

handoff_current_work captures an inspected boundary and returns a temporary Prepared Handoff. Committing it creates a durable Revision only when the user wants a milestone. The receiver resolves the Handoff and records an Acknowledgement; a Task Outcome preserves the final status and checks as Source evidence. The Handoff Report projects the latest Revision in each selected Scope — read-only, and it never rewrites Memory.

Experience — what worked, reviewed before it is reused

An Experience records a situation, an action, an observed outcome, and a reusable lesson. It enters a scope-local Review Inbox as a pending Candidate. Review writes use expected_version, so a decision cannot silently apply after another writer changes the proposal. Approval writes an immutable Revision; rejection records a reason. Both are terminal, and only the approved current head takes part in recall — pending, rejected, and historical Revisions are excluded.

Skill — a reviewed procedure, exported on purpose

A managed Skill holds a name, a discovery description, instructions, validation checks, and lineage. Approval does not install or execute it: an exact approved Revision must be exported explicitly before an Agent host can discover the host-local projection.

This is the beginning of the README. Read the rest at the original. Read the full README ↗