Sevenbox
Decision audit for AI agents
Open-sourced in October 2026 and in private evaluation with AI engineers at fintech companies.
Sevenbox is an open-core Python library and a local Operations Center that record why an AI agent made each decision, what that decision depended on, and whether acting on it can be undone.
When a belief turns out to be wrong, it finds every decision that relied on it, including actions that have already left the system, and shows what still needs a person's attention.
- Client
- Any team running AI agents, on Microsoft Agent Framework, OpenAI Agents SDK, LlamaIndex, LangGraph, smolagents or no framework at all
- Role
- Solo designer and developer
- Timeline
- June 2026 to present
- License
- Apache 2.0
- Stack
- Python · JavaScript · HTML/CSS
When an agent gets it wrong
AI agents increasingly take actions with consequences, such as approving a refund, sending a payment or escalating a case. Each of those actions rests on beliefs the agent formed along the way, some from a model's inference and some from a tool's answer, and any of them can later turn out to be wrong.
When that happens, teams have no reliable way to find every decision that depended on the wrong belief. Logs and traces record what ran and in what order, but they do not record which earlier claim a decision actually relied on, and they say nothing about which actions can still be reversed. The common practice I heard from engineers was that a person reads the logs and decides what to undo, which can work for a single incident but does not scale to agents making thousands of decisions a day.
Before
After a correction
Gap
I started by mapping what existing tools already answer. The analysis covered four categories of tools, and each of them is strong at its own job while leaving the same question open, namely which actions that already ran were compromised once a belief proved false.
Listening to the engineers who live with it
In parallel I reached out to engineers who run agents in production. I reviewed more than forty profiles, and only four or five of the people I spoke with described the problem as something they had actually run into.
The filter that worked was individual engineers at companies where agents already execute irreversible actions, such as fintech and payments. Teams that were still prototyping, or whose agents only read data, had not yet met the cost of a wrong belief reaching the outside world.
Some things can't be undone
One engineer validated the problem and also pushed back on it. Their view was that a team that needs this often should redesign its system around forward fixes, correcting state going forward instead of tracing back through what happened.
I agreed for actions that can be reversed and drew the line at actions that have already left the system, such as a payment that was sent or a refund that was issued, and they accepted that exception. That conversation shaped the design, because it meant Sevenbox should not treat every decision the same way but classify each action by how it can be undone and save a person's attention for the cases that truly need it.
A Warrant records why a decision was made, what it depended on, and whether acting on it can be undone.
No effect outside the agent, so there is nothing to undo when a belief changes.
The effect can be rolled back directly, so a correction can simply undo it.
The effect cannot be rolled back, but a separate compensating action can offset it.
The effect has already left the system, so a correction creates an obligation a person has to resolve.
Trust layer
An audit tool is only useful if its answers can be trusted in the moment they matter most. Sevenbox is built on a formal model whose guarantees are proved rather than estimated, and the library is checked against that model, so when it reports which decisions a correction affects, the answer rests on a guarantee instead of a pattern that might miss a case.
Searches logs for what looks related, so the list of affected actions is a best guess that can be incomplete.
Follows what each decision depended on, so the list of affected actions follows from a guarantee and can be checked.
Designing for the people who use it
Finding the right words
Sevenbox is the brand people see, and Warrant is the technical term for the record each decision produces. I kept Warrant fixed across the code, the documentation and the interface, so that a word learned in one place means the same thing everywhere else.
One keypress to get started
The compiled engine ships under evaluation terms, and the first import asks the person to accept them. I chose a single keypress over a typed confirmation phrase, because a phrase adds friction at the exact moment someone is deciding whether to try the tool, and scripts or CI can accept the terms through an environment variable instead.
$ python my_agent.py … evaluation terms … Press Enter to accept, or type anything else to cancel: ▍ All set -- you're ready to use Sevenbox.
Plain, friendly language
I rewrote every error message the engine shows so that it states what happened and what the person can do next, instead of exposing internal state. The Operations Center follows the same rule, and each alert ends with the action that resolves it.
Operations Center alertAn irreversible action's justification was corrected after it happened, and nothing has been recorded yet to compensate for it. Review the pending obligations and record a compensation.
Operations Center alertThis decision doesn't have a recorded source name, so replaying it could be confused with another parallel call. Record a source name to fix this.
First import without a terminalNo interactive terminal was detected, so Sevenbox cannot prompt for acceptance here. Set the environment variable SEVENBOX_ACCEPT_TERMS=1 to accept the terms non-interactively (CI, a script, a container), or run once from an interactive terminal to accept them there.
Deciding what to share
Releasing Sevenbox meant deciding what to show and what to keep. I made the SDK, the fourteen framework adapters, the demo and the Operations Center public under Apache 2.0, because those are the parts people need to read, trust and integrate, and I kept the engine and the formal model private, with the engine distributed as compiled wheels.
I approached it as a question of disclosure as much as one of engineering, since every public file is also a statement about how the product works.
Public · Apache 2.0 on GitHub
Private · integrates through the public API
Black box for agent reasoning
The name comes from two places. Seven is the day I was born, and box comes from the black box, the recorder that keeps what happened on board so it can be understood afterwards. Sevenbox is meant to be that box for the reasoning of AI agents.
Logo
The logo puts both halves of the name into one shape. It is a cube, the box, cut by a single diagonal that reads as a seven, drawn in a soft sky blue with rounded corners.
That blue became the accent for everything else, from the buttons on the website to the interaction color inside the Operations Center.
A quiet night instead of a dashboard
Most developer tools open on a screenshot of their product. The Sevenbox site opens on a pixel-art night scene instead, with a campfire, a cabin and a city across the water, and the copy sits over it in a calm, reflective voice.
The manifesto reads as three short lines about what we have already learned to preserve, followed by the one thing nobody has built a structure for yet.
We learned to preserve facts. That discipline is called a database.
We learned to preserve intent. That discipline is called version control.
We learned to preserve computation. That discipline is called logs, traces, and spans.
We have never had a structure that preserves why an autonomous system believed something, and what to do when that belief turns out to be wrong. Sevenbox is that structure.
Little lights along the way
A rail of eight pixel-art objects runs down the side of the site, one for each section, and lights up as the reader scrolls past it. They come from the same night world as the scene, so navigating the page feels like walking through it.
Section labels are set in uppercase blue with a blinking underscore, like a cursor waiting in a terminal, and sections are divided by a single hairline that ends in a glowing star.
IBM Plex MonoLocal control room for decisions
The Operations Center is a local web interface started with a single command. It runs next to the agent, reads the decision store directly and sends nothing outside the machine, and it is organized around eight views that move from a health overview of what needs attention to the irreversible actions that still need a person.
Quiet by design
Surfaces are near-black and separated by hairline borders, text uses one hue at three opacities, and color is reserved for meaning. Blue marks interaction and comes straight from the logo, while green, amber and red mark health, so a critical state reads as one saturated block and everything else stays quiet. The values below are taken from the interface's stylesheet.
Surfaces
--bg-0#060708Page and shell--bg-2#0b0d10Panel--bg-3#16181cHover lift--bg-well#050608Recessed wellSemantic color
--accent#a0d8fcInteraction, sampled from the logo--success#7ee787Healthy--warning#f2cc60Degraded, pending--danger#ff7b72CriticalDecision kinds
Text
--text-primaryAa --text-secondaryAa --text-tertiaryType · Inter and IBM Plex Mono
--text-2xl · 30px--text-xl · 22px--text-lg · 18px--text-md · 16px--text-base · 15px--text-sm · 14px--text-xs · 13pxIBM Plex Mono 400 / 500 / 600Components
Radius and spacing
sm · 8pxmd · 14pxlg · 20pxfull · full4 · 8 · 12 · 16 · 24 · 32 · 48 pxMade to fit what teams already use
Each integration followed the same method. I researched a framework's real internals first, then built the adapter, then tested it against the actually installed package instead of a fully mocked one, and real framework bugs surfaced along the way.
A fifteenth case ran the same workload with no framework at all and needed no adapter code, compared with roughly 450 lines for each framework adapter.
agent architectures validated, fourteen frameworks plus a plain Python loop
public tests passing (1 skipped) for the SDK and all fourteen adapters
tests passing in total including the private engine suite (1 skipped)
compiled wheels per release, for macOS, Linux and Windows on Python 3.10 to 3.13
Where the evidence is weaker it is labeled as weaker rather than presented as equal.
What testing taught me
Each bug below was found by writing the test that would prove a claim instead of assuming the claim held. A security review of the Operations Center also found five stored cross-site scripting vulnerabilities where decision content, which can come from a model or from free-text human input, was rendered without escaping, and every affected view now goes through the same escaping helper.
Listening after launch
I started building Sevenbox in June 2026, and it was released publicly on GitHub in October 2026 as v0.1.0 under Apache 2.0 with a compiled engine, and shared on Reddit and LinkedIn.
The first community feedback came from Reddit and asked how obligations get resolved once they appear and what happens when an irreversible action becomes moot before anyone acts on it. At that point Sevenbox only reported obligations, so a developer could reach a list of pending items and have nowhere to go next.
Five days after the launch, v0.1.1 added discharge_obligation() and session.discharge(), which mark an obligation as resolved either because a compensating action was taken, with that action's own record required as evidence, or because it turned out not to be needed. Building the feature also exposed a bug in which a directly replaced obligation kept showing as pending after it was resolved, and the fix shipped in the same release, whose notes credit the feedback directly.
- Oct 18v0.1.0 releasedPublic on GitHub and shared on Reddit and LinkedIn
- Days 1 to 5Questions from RedditHow are obligations resolved, and what if an irreversible action becomes moot
- Issue #2A gap, written downThere was no API between a list of pending obligations and resolving them
- Oct 23v0.1.1 shippeddischarge_obligation() and session.discharge(), plus a bug fix found while building them
A separate question asked whether Sevenbox can tell a decision that needs two earlier claims together from one that either claim supports on its own. I ran the test that would show the answer, using two cases with the same dependencies and opposite intended meanings, and both produced the same result.
That limit is now a public issue with the code and output attached and credited to the person who raised it, and I left it unimplemented on purpose because a real fix means recording richer intent than a flat list of dependencies.
Where it's headed
Two directions are next. An MCP server would let an agent check whether a belief is still valid before it acts on it, and optional compensation handlers, still under discussion in an open issue, would let a developer attach the compensating action to the decision it offsets.