PowerContext: carrying agent context across handoffs

The problem PowerContext is built around

The README opens with a specific observation: 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 the current state stay behind in that conversation. PowerContext exists to keep context attached to the work rather than to the conversation that produced it. When you return, the documentation says you can see what happened and continue from the current state, and a new agent can do the same. The target user is not a single developer chatting with a model. It is a team or an individual running multi-step work across sessions, across agents, and occasionally across people. The topics listed on the repository (agentic, context-engineering, handoff, long-term-memory, multi-agent) match that framing. If your work fits inside one session and one context window, this project is solving a problem you do not have.

Memory, Handoff, Experience and Skill as separate stores

PowerContext splits what it keeps into named categories rather than one undifferentiated transcript. Durable information is stored as Memory. The current objective and state are organized into a Handoff. Reusable approaches can be recorded as Experience or as Skill. The README states that every item stays within the scope of the work and that sources and earlier revisions are preserved. That last part matters more than the category names. If revisions are retained, you can see how a decision changed rather than only what it currently is, which is the difference between a memory store and an audit trail. The design also implies a deliberate act of curation: the README says you decide what will matter later and what needs to move with the task. This is not a system that silently captures everything. It expects you to promote information into Memory or carry it in a Handoff, and that expectation is the main thing to weigh against tools that capture automatically.

Scope is the boundary that makes handoff work

The README refers repeatedly to Scopes: items stay within the scope of the work, setup creates and binds the selected Scopes, and the acceptance check for automatic memory requires recalling a memory in a new session using the same Scope. So Scope is the unit of isolation. Two pieces of work with different Scopes should not see each other's Memory, which is what makes it safe to run several agent tasks against one Server. The practical consequence is that Scope selection is a configuration decision you make before the agent session starts, not something the agent negotiates. The README does not spell out in the supplied material what happens when a task legitimately spans two Scopes, or how Scopes are named and nested. That is a gap. Before adopting, read the Scope documentation and decide whether your work maps cleanly onto one Scope per task, because a mismatch there will show up as memories that cannot be recalled rather than as an error message.

Installing the 1.0.0 release candidate

The README pins the pre-release explicitly. You need Git, uv, and your Agent's CLI, with Python 3.11 or newer, which uv can provision. macOS and Linux are supported; Windows support is described as experimental. The install and configuration sequence is:

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. It writes one .env file plus .env.next-steps.md. If seekdb needs installing, the wizard asks once and installs it in the background. You then start the server in that terminal with powercontext server run --env-file .env. In a second terminal you load only the client settings and check the connection:

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

The Codex integration is installed separately with powercontext setup codex --ref powercontext-v1.0.0rc2, and powercontext doctor codex verifies the integration setup. The README notes that Python dependency downloads can be slow or fail, and points to mirror retry instructions. Note the version coupling: the setup command takes a ref that matches the installed release, so the CLI and the integration are expected to move together.

Basic memory versus full memory capabilities

The wizard offers two memory modes, and the difference is the single most important choice in the setup. Full memory capabilities enables automatic Memory and Topic Memory, and it requires separate Generation and Embedding API credentials. The README is blunt that an Agent subscription does not provide those Server credentials. Basic memory saves and retrieves memories explicitly without additional model APIs. So the cost profile splits cleanly: basic mode is free of extra API spend but pushes the work of deciding what to remember onto you, while full mode automates capture and topic formation but adds two credential sets and a Server-side inference path. If you choose full mode and skip the credentials, the pipeline simply will not run, and the failure will look like missing memories rather than a configuration error. The README's acceptance check for full mode is concrete: verify that a real prompt becomes a Source, produces a Topic, evolves after a related prompt, and can be recalled in a new session using the same Scope.

Remote servers, HTTPS and the insecure-HTTP escape hatch

Running the Server on another machine is supported, but the README directs you to use HTTPS or follow the remote connection guide. Setup recognizes remote HTTP URLs from flags or environment variables and asks for explicit consent before proceeding. For automated setup there is a flag, --allow-insecure-http. That flag is worth treating as a deliberate exception rather than a default. Once a Server is remote, the context it holds (decisions, constraints, evidence, next steps) travels over the network, and the README does not describe encryption at rest or access control beyond the connection layer in the material supplied here. The walkthrough covers Dashboard login and SSH forwarding, which suggests the intended deployment keeps the Server close and tunnels to it. If your threat model requires the memory store to be encrypted or access-controlled per user, that is not something the README answers, and you should confirm it before putting real project context into a remote Server.

Integration tiers and what official actually means

PowerContext labels its Agent integrations. Codex is official. Other hosts and Python Agent frameworks are community. Bub is evaluation only. The README states these tags describe PowerContext integration maintenance and use, and points to a capability matrix for supported features and availability. The honest reading is that official means the maintainers keep that path working and tested, community means it exists but may lag, and evaluation means do not build on it. The README lists Codex, Claude Code, DeepSeek Harness, Hermes Agent, Pi Coding Agent and OpenClaw among the integrations, and the quickstart covers Codex and Claude Code specifically. If your agent is not on the official list, you are on a path the maintainers are not committing to maintain at the same level, and the capability matrix is the document that tells you which features you will actually get. Check it before assuming parity. The repository also links a Discord community, which is where community integration questions presumably land.

Where PowerContext is the wrong tool

Three cases stand out. First, single-session work: if the task finishes in one conversation, the Scope, Handoff and Memory machinery adds setup cost with nothing to hand off. Second, teams without Server-side model credentials: full memory capabilities need separate Generation and Embedding APIs, and if you cannot provision them, you fall back to basic memory, at which point you are manually curating what a simpler notes file could hold. Third, Windows users: the README marks Windows support as experimental, so a Windows-primary team is testing an unproven path. There is also a versioning constraint worth naming. The current release line is a release candidate (v1.0.0rc2, preceded by v1.0.0rc1 and v0.2.0, all within days of each other), and the install command pins the pre-release. Anyone adopting now is adopting an RC, and the setup command's --ref must match it. If you need a stable release, the material here shows only release candidates at the 1.0.0 line.

How this differs from a retrieval layer over a vector store

A common alternative is to embed a project's documents and conversations into a vector store and retrieve relevant chunks at prompt time. That approach optimizes for recall over a corpus. PowerContext optimizes for continuity of a specific piece of work, which is a different shape. Its unit is the Handoff (current objective and state) plus Memory scoped to that work, not a similarity search over everything ever written. The practical difference shows in what you get back: a vector store returns passages that resemble the query, while PowerContext is documented to return confirmed decisions, constraints, progress, evidence and next steps, with sources and earlier revisions preserved. That structure is what lets a second agent continue rather than re-derive. The trade-off is that structure costs you curation and configuration (Scopes, memory mode, model credentials), whereas a vector store is closer to fire-and-forget. Neither is strictly better; they answer different questions.

Licence and maintenance expectations

PowerContext is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is a permissive licence with a patent grant, and for most adopters the obligation is attribution rather than payment. This is not legal advice; if you are redistributing it inside a product, have counsel read the LICENSE file. On maintenance: the repository is not archived, the last push is recent, and the release cadence in the supplied material shows three releases within roughly three days. That cadence is consistent with an active pre-1.0 push rather than a settled project, which cuts both ways. Fixes arrive quickly, and so do breaking changes. The version coupling between the CLI and the Agent integration (setup takes a ref matching the installed release) means an upgrade is a coordinated action across the tool install, the .env file and the plugin, not a single command. Budget for re-running the wizard or at least re-checking powercontext doctor after any version bump.

Editorial conclusion

Adopt PowerContext if your agents work in sessions that get interrupted and you want the confirmed decisions, constraints and next steps to survive the interruption. Do not adopt it if you only need a single chat session with a large context window, or if you cannot supply separate Generation and Embedding API credentials, because automatic Memory and Topic Memory will not run without them. Before committing, run powercontext ready and powercontext capabilities against your own Server, then check that one real prompt becomes a Source, produces a Topic, evolves after a related prompt, and can be recalled in a new session under the same Scope. That four-step check is the acceptance test the README itself names, and it is the only thing that tells you whether the memory pipeline is wired up correctly on your machine.

Official sources

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