See the proposal
A connector, called an adapter, submits the action with its project and session details. Policy routes it to automatic allowance, review, or blocking.
Supporting software: BigBoss
Human review for local coding-agent actions
BigBoss is a local queue for proposed agent actions. Policy routes each request; a person reviews the ones that need it; the proposal and decision are kept.
I am building the Consumption Engine, a way to keep a project's sources and corrections attached to the work agents do with them. BigBoss provides approval controls and decision records as a separate tool. Connecting it to the engine is still in development.
Working local prototype / One human reviewer per instance / Public implementation (399 author-run CI tests at v0.1.0 / inspected source 5615b72)
The problem
Reviewing requests from several agents in one queue
Permission requests can arrive across several coding sessions. A useful decision needs context: the proposed action, the workspace, and the request it belongs to. BigBoss brings connected requests into a local dashboard and keeps their decision history.
Review when required
For requests that need human review, approve, reject, or request changes. A decision refers to a specific proposal.
Keep the decision
Requests, decisions, and events persist in a local SQLite store, so the review record can outlast a terminal session.
Read the implementation case study for the policy, store, and adapter evidence.
Illustrative walkthrough: about two minutes
Follow one request from proposal to decision
Illustrative walkthrough with example data; nothing runs on this page.
-
An agent proposes a file change
A connected adapter submits a request to update a README in an example workspace. BigBoss records the proposal and its context.
-
Policy sends it for review
The default policy routes file changes to human review. The dashboard shows the request so the reviewer can inspect what is being proposed.
-
The reviewer makes a decision
The reviewer approves this proposal once. The decision refers to an
action_hashderived from the proposal, workspace, and policy version. -
The decision stays available
The local store retains the request, decision, and events. The adapter receives the outcome and is responsible for applying it to the matching action.
| Stage | Input | Recorded Output | Current MVP Limit |
|---|---|---|---|
| 1. Proposal intake | Command or file edit, workspace, run ID, policy version | Request row and SHA-256 action_hash | Only covers actions submitted by the adapter |
| 2. Policy routing | Normalized proposal and active policy rules | Classification: allow, pending review, or block | Static rule matching; does not sandbox host processes |
| 3. Human review gate | Pending request in local SSE web queue | Reviewer decision (approve, reject, or revise) with device ID | One human reviewer per local instance; LAN phone alerts opt-in |
| 4. SQLite persistence | Decision event and target action_hash | Persisted SQLite decision history and returned hash | Adapter must enforce hash match; does not verify task completion |
What if the proposal changes?
An approval to edit the README does not cover a different proposal to install dependencies. The adapter contract requires the executed action to match the approved proposal. BigBoss alone cannot enforce that boundary against a bypassing adapter or an agent with access to its local approval API.
Run the local demonstration request, Inspect the evidence and limitsDeployment & integration
Start on one machine, with a supported adapter
Current deployment
BigBoss runs locally, with one human reviewer per running instance. By default, the dashboard is accessible only from that machine. Phone access is opt-in over the local network, and alerts require the web app to remain open.
No hosted BigBoss service is offered. The public quickstart requires Python 3.12 or newer and uv. Release v0.1.0 (10acc53) passed 399 author-run CI tests; the developer guide inspects source 5615b72.
Approval depends on the integration
The public implementation includes an HTTP interface, a local Model Context Protocol (MCP) interface, a hook adapter, and a Codex app-server bridge. Their coverage differs. Receiving a status update is not the same as gating execution.
BigBoss does not isolate the agent from the computer it runs on. Keeping that agent away from the approval API is an operator responsibility.
Read the security modelResearch evaluation
Evaluate BigBoss with your own harness
If you want to test BigBoss with your own agent harness, the adapter contract is documented and I am glad to compare notes on what your integration gates and what still bypasses it. Email me.
Current development & open questions
Connecting approvals to the evidence workflow
What is built: a local queue, policy routing, hashed proposals, SQLite history, four adapters. What I am investigating next: simpler local setup, broader adapter coverage, and how approval records should sit beside the Consumption Engine's task checks. Current implementation and evidence, related work in Council.
Before you start
Practical questions
How can I access BigBoss?
The public repository provides the source, setup instructions, and current limitations. You can try the local demonstration request before connecting an agent.
What is available to evaluate?
The current software is public source you can run locally. If you want help with a specific approval integration, email me.
Does BigBoss prove an agent completed its work?
No. It retains proposals, decisions, and related events. Execution enforcement depends on the connected adapter. Evidence-based completion evaluation remains a research objective.
Who develops BigBoss?
I am Jonathan Simone, the solo founder and developer at Simone Systems Research LLC, directing the team (the AI coding agents I direct across more than one tool). BigBoss is a working prototype I use myself. The evidence page separates implementation, author-run checks, and external evaluation.