Inspiration
Most personal AI agents are built to do more. solo-power is built for something harder: an always-on assistant for one person that you can leave running and still trust. An agent that acts for you all day needs three things. It should only touch what you gave it. It should leave receipts, so you can see what it did. And it should keep your data under your control.
The demo scenario is a small bakery owner with a daily stream of orders, supplier messages and scheduling. The agent can draft and queue routine work on its own. Anything with consequences waits for a person.
What it does
solo-power is a single-user agent loop with a local control tower called AXIOM:
- The agent proposes, AXIOM decides. The agent sends proposed work to AXIOM, which decides what happens next.
- Routine proposals go through automatically. AXIOM accepts them under policy and records why (AUTO_BY_POLICY).
- Consequential proposals are held for the human. A draft is created, marked pending approval, and not authorized to execute. Change tools need a person to approve them.
- Every tool call leaves a receipt. A hash-chained effect journal records that a call is about to run, then seals it when it ends. A call that never sealed is reported as unresolved and is never retried automatically. Edits, deletions and reordering are detectable by a verifier.
- The agent can't act on stale authority. AXIOM reports the agent UNAVAILABLE when no health report arrives inside a 120-second window, and refuses agent proposals unless the runtime has fresh health or a person has made a time-limited, human-attested bootstrap. The bootstrap is recorded as the person's statement. AXIOM does not verify it.
The demo video walks through the code, runs the test suite (48 tests pass), runs the journal verifier on a clean journal (ok, with one unsealed call flagged), then edits one entry and shows the verifier catch it (bad hash at the edited entry, broken link at the next).
How we built it
- AXIOM is a Python backend with a TypeScript UI: persistent work, human approvals, receipts and a guarded runtime interface. It binds to loopback by default.
- The agent is Hermes. A tool-call hook writes the effect journal, and a verifier checks the chain.
- Agent-side tools are an MCP tool server for AXIOM, the effect journal and verifier with published test vectors, a file-based anchor store, and a small reference guard.
- The model. solo-power is designed to call an NVIDIA open model hosted on Nebius. The exact model ID has not yet been confirmed in a Hermes run record, so we treat the model call as unverified in this submission.
- The data is synthetic. The repo ships with a synthetic seed only. There are no real customer records, credentials or business data in it.
- License: MIT.
Challenges
- Honest claims. The hard part was writing only what we could reproduce. We kept a list of things that sound good but are not yet true, and kept them out of the story.
- Authority that expires. Making "the agent may act" a short-lived, recorded human decision took more design than letting it run freely.
- Windows long paths break a compiled dependency, so clone into a short path such as C:\darla.
Accomplishments we're proud of
- An approval model where routine work flows and consequential work waits for a person, with unknown outcomes left unresolved instead of retried.
- An effect journal and verifier with published test vectors that catch edits, deletions and reordering.
- A public tree that was scanned for private material before export.
What we learned
A receipt is only as useful as its limits are clear. Our journal detects edits, deletions and reordering. Detecting truncation requires an anchor stored where the agent can't reach. The AXIOM-backed anchor store is not yet active against AXIOM, so we say so. Likewise, our reference guard is not fail-closed.
Honest limits
- The model call is unverified until a run record shows the model ID.
- The AXIOM-backed anchor store and the reference guard are not yet active against AXIOM. The build in this repo does not have the routes they need.
- The reference guard is not fail-closed: if the guard process stops, nothing locks.
- The Hermes hook adapter is tested against the hook's documented payload. Coverage of every Hermes tool type has not been tested yet.
- The journal is not tamper-proof. It does not protect against someone who controls the machine holding both the journal and any anchors, and it only covers calls that reach the hook.
An operator can plug in a stricter guard.
What's next
- Confirm the model ID in a run record.
- Turn on the anchor store and guard against AXIOM and test them live.
- Make the guard fail-closed.
- Reuse the same setup for other single-user deployments by swapping the persona card.
Links
- Code (MIT): https://github.com/ldr-Fulcrum/solo-power
- Video (under 3 minutes): [VIDEO URL]
Built With
- agent
- ai
- context
- docker
- fastapi
- hermes
- model
- nebius
- nemotron
- node.js
- protocol
- python
- react
- studio
- typescript
- vite
- wsl
Log in or sign up for Devpost to join the conversation.