PowerContext: handoff-ready context for work that humans and agents pass back and forth

The handoff problem PowerContext is built around

The README opens with a plain observation: work rarely ends with whoever starts it. A person hands a task to an agent, the agent gets part of the way, and later someone else takes over. The reasoning and the current state stay behind in that first conversation. PowerContext's answer is to keep context with the work rather than with the conversation, so that returning to the task shows confirmed decisions, constraints, progress, evidence and next steps without rereading the full history.

The intended audience is teams whose tasks cross a boundary between a human and a coding agent, or between two agents. The project organizes durable information as Memory, the current objective and state as a Handoff, and reusable approaches as Experience or Skill. Each item stays within the scope of the work and keeps its sources and earlier revisions. That last part is the design claim worth noticing: this is not a chat log store, it is a structure that expects to be edited, superseded and cited.

Memory, Handoff, Scope and Source: the pieces the Server keeps

The vocabulary in the README maps onto distinct stored objects. Memory holds information meant to last. Handoff holds the current objective and state, which is what a new agent or colleague reads first. Experience and Skill hold reusable approaches. Every item is bound to a Scope, and the quickstart instructs the reader to create and bind the selected Scopes before launching an agent session. Scope is what prevents a note from one project leaking into another, and it is also the unit the recall check uses: the README says a memory can be recalled in a new session using the same Scope.

Source is the other structural idea. The README describes a real prompt becoming a Source, which then produces a Topic that evolves after a related prompt. So the pipeline is prompt to Source to Topic to recall, with the Topic as the evolving unit rather than the individual message. The package metadata in pyproject.toml shows the machinery underneath: pydantic and pydantic-ai-slim for models, SQLAlchemy with aiosqlite for storage, sqlite-vec for vector search, and pyobvector in the dependency set. The Server also exposes MCP, since .env.example sets POWERCONTEXT_SERVER_MCP_ENABLED=true and POWERCONTEXT_SERVER_MCP_PATH=/mcp.

Installing PowerContext 1.0.0rc2 and running the configuration wizard

The README states that Git, uv and your agent's CLI are prerequisites, that Python 3.11 or newer is required, that uv can provision it, and that macOS and Linux are supported while Windows support is experimental. The install command pins the pre-release and then opens the interactive wizard in a dedicated directory. The wizard writes one .env file and a .env.next-steps.md file.

uv tool install --force "powercontext[cli,server]==1.0.0rc2"
mkdir -p powercontext-config
cd powercontext-config
powercontext config init --language en --output .env

The wizard asks about storage, local or remote access, memory capabilities, Dashboard, model APIs and agent connections. The choice that matters most is between Full memory capabilities, which the README says requires separate Generation and Embedding API credentials and enables automatic Memory and Topic Memory, and Basic memory, which saves and retrieves memories explicitly without extra model APIs. An agent subscription does not provide those Server credentials. If seekdb needs installing, the wizard asks once and installs the dependency in the background.

Starting the Server and confirming the connection before you wire up an agent

Once the wizard has finished, the README says to follow the printed connection details and start the Server in the same terminal, keeping it running. In a second terminal you return to the configuration directory, load only the client settings, and check the connection. The ready command and the capabilities command are the two probes; capabilities is the one that tells you which features the Server will actually serve.

powercontext server run --env-file .env

set -a
. ./.env
set +a
powercontext ready
powercontext capabilities

The README then points to .env.next-steps.md for creating and binding the selected Scopes, installing the matching plugins and launching a new agent session. For Codex, which the README tags as the official integration, the documented pair is a setup command pinned to the same release reference and a doctor command that verifies the integration.

powercontext setup codex --ref powercontext-v1.0.0rc2
powercontext doctor codex

The acceptance check the README gives for automatic memory is concrete: a real prompt should become a Source, produce a Topic, evolve after a related prompt, and be recallable in a new session using the same Scope.

Remote access, insecure HTTP and the access control switch

Running the Server on another machine changes the security posture, and the README is unusually direct about it: use HTTPS, or follow the remote connection guide. Setup recognizes remote HTTP URLs from flags or environment variables and asks for explicit consent, and automated setup uses --allow-insecure-http. The .env.example file repeats the warning in stronger terms, calling direct cleartext HTTP a development and proof-of-concept escape hatch and telling operators to keep POWERCONTEXT_SERVER_ALLOW_INSECURE_HTTP false on public or untrusted networks. The receiver must also enroll with the same flag, so consent is required on both ends rather than one.

Access control has a single supported switch, POWERCONTEXT_SERVER_ACCESS_MODE, which .env.example sets to disabled by default. The legacy static bearer settings, POWERCONTEXT_SERVER_AUTH_ENABLED and POWERCONTEXT_SERVER_AUTH_TOKEN, are described as compatibility only, and an injected Authentication Provider takes precedence over them. Binding to a non-loopback address without Server-wide bearer authentication requires a second, independent opt-in through POWERCONTEXT_SERVER_ALLOW_UNAUTHENTICATED_NON_LOOPBACK. Two separate flags for one risky configuration is a reasonable design, and it also means a misconfigured deployment has more than one place to go wrong.

Where PowerContext is the wrong tool, and how it differs from a vector store

The clearest limitation comes from the wizard itself. Automatic Memory and Topic Memory need Generation and Embedding API credentials that an agent subscription does not supply. If you want the prompt-to-Source-to-Topic pipeline, you are paying for and configuring a second set of model APIs on the Server side, independent of whatever you use to drive the agent. Basic memory avoids that cost but drops you back to saving and retrieving memories explicitly, which is a different product in practice.

Windows is labeled experimental, so a Windows-first team is outside the supported path. The release line is also pre-release: the newest entry is powercontext-v1.0.0rc2, published on 2026-09-10, and the README's own install command pins that release candidate rather than a stable version. Anyone who needs a frozen, long-supported dependency should wait.

The comparison that matters is with a general vector store or a plain retrieval library. A vector store indexes text and returns nearest neighbors; it has no notion of a Handoff, no Scope that binds an item to a unit of work, and no revision history attached to each item. PowerContext's README describes exactly those as the stored model, and it adds an explicit objective-and-state object that a retrieval index does not have. The trade is that you must adopt its vocabulary and run its Server, where a vector store is a library call. If your problem is searching documents, PowerContext is overhead. If your problem is that the sixth agent to touch a task does not know what the first five decided, the structure is the point.

Licence, maintenance and the cost of tracking a release candidate

The repository is licensed Apache-2.0, with the licence header carried in source files such as pyproject.toml and a .licenserc.yaml at the top level. Apache-2.0 permits commercial use and modification and includes an explicit patent grant; it also requires that notices and the licence text be preserved in redistributed copies. If you embed PowerContext in a product, the obligations that matter are attribution and change notices, not royalties. That is a description of the licence, not legal advice, and the LICENSE file is the authority.

Maintenance is visible but young. The last push to the default branch was on 2026-09-10, and the repository is not archived. The release history is compressed: powercontext-v0.2.0 on 2026-09-07, then powercontext-v1.0.0rc1 and rc2 both on 2026-09-10. Three releases in four days, all inside the same week as the last commit, tells you the 1.0 line is being assembled quickly. It does not tell you how often the interfaces will move afterward, and the README does not document a deprecation or upgrade policy, so pinning the exact version in your own tooling is the only guarantee available.

Upgrade cost also depends on the integration you choose. The README tags Codex as official and says other hosts and Python agent frameworks are community, with Bub marked evaluation only. Those tags describe PowerContext integration maintenance and use, which is a useful signal: if you build on a community integration, the compatibility surface is maintained by someone other than the core project.

Editorial conclusion

Adopt PowerContext if your work moves between people and coding agents and you want the decisions, constraints and next steps to travel with the task instead of being retyped. Do not adopt it if you only need a key-value scratchpad inside one session, if you cannot supply separate Generation and Embedding API credentials for automatic memory, or if you need Windows support in production, which the README labels experimental. Before trusting it, run the acceptance check the README gives: confirm that a real prompt becomes a Source, produces a Topic, evolves after a related prompt, and is recalled in a new session under the same Scope.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. oceanbase/powercontext on GitHub
3. Project website
4. README
5. Releases