Maverick
Maverick started as plans and files because agents needed somewhere durable to understand a company. It grew into a product I use to turn an idea into evidence, decisions and a company plan before I start building the expensive parts.
Writing about Maverick
All related writing01
Planning started in files.
The first useful version kept plans, conversations, decisions and artifacts in a local .maverick directory. I rebuilt the runner several times, but the directory kept the company context available to the next person or agent.
02
Those files became the FlightPlan.
The useful material became one company record: market evidence, customer learning, pricing, brand, and the decisions behind them. I could change the interface without making the agents rediscover the company each time.
03
Maverick became a product.
The internal workflow became a product for shaping a company. Formation is one concrete path. Maverick can prepare a reviewable draft, explain the reasoning, and stop before anything is filed or paid for.
04
Agents can use the same workflow.
Maverick exposes the formation and advisory workflow through MCP. An agent can bring the project context it already has, prepare the work, and hand the result back for review instead of forcing the founder to repeat it in another form.
05
Voxelbox runs Maverick's local agent operations.
Maverick's site and services run in the cloud. Voxelbox runs locally as my agent runtime: it schedules founder briefings, carries company context into each agent session and brings decisions back for review. The site and the local operating layer have separate jobs.
See how Voxelbox organizes agent operations →- 01Voxelbox schedules the work
The routine starts with the current Maverick company context.
- 02Maverick supplies product context
The agent uses the product's MCP surface where it needs structured data.
- 03The result returns for review
No filing, payment, or company action happens from this flow.
