AI agents can now run businesses around the clock. But the operator’s job — watching what’s happening, steering when needed, resolving decisions only humans can make — has no plane built for it. management.studio is that plane.
Infrastructure-as-Code built a $500B software industry. Business-as-Codedoes the same for the $50T services economy — but someone has to fly the plane.
The work is no longer the bottleneck. AI agents can already handle most service workflows: intake, research, drafting, reconciliation, dispatch, customer communication. The hard part is now everything aroundthe execution — knowing what Workers are doing, steering them when they drift, approving decisions they cannot make alone, and reading the financials in real time.
Today, people stitch together Slack channels, Stripe dashboards, spreadsheets, and gut feel. That works at one business. It does not work at ten. It fails at a hundred.
management.studio is the observe / control / respond plane for businesses run on Business-as-Code. One cockpit. Every Worker, Workflow, Action, and dollar.
90seconds
designed for
Full context. One queue. One decision. Business keeps moving.
In 2026, a founder can boot a Business and have AI agents handling intake, customer communication, research, scheduling, and billing within hours. The technical capability is real. The question is no longer can AI do the work? It’s who watches the AI doing the work?
The operator’s job is not glamorous, but it is load-bearing. Someone must:
Today’s operator does this by stitching together a Slack workspace, a Stripe dashboard, a spreadsheet, a few n8n automations, and judgment calls made from incomplete information. That patchwork works at one Business. It starts to crack at three. It fails completely when you are operating a portfolio.
The tooling has not kept pace with the capability. Frontier AI can run a business. There is no instrument panel to run it from.
Real-time worker state is lost in notification noise. There is no unified view of what any Agent is actually doing, what Actions have been taken, or what is in flight. Operators find out about failures after the fact.
Stripe, QuickBooks, and spreadsheets reconcile after the fact. By the time an operator reads a P&L, the Business has made hundreds of financial decisions without human visibility into real-time margin or burn.
Bespoke automations handle individual escalation types. There is no unified queue, no SLA enforcement, no escalation engine. Decision coverage is accidental, not systematic.
None of these failure modes are fatal at a single Business run by a founder who has memorized every corner. They are structural failures the moment the Business is autonomous enough that the operator cannot hold the whole thing in their head.
Business-as-Code is the paradigm in which a Business is defined as a composable, inspectable runtime object — not a collection of people, documents, and tools, but a typed system with explicit contracts. The Business executes against code. It can be observed programmatically, controlled through a typed API, and reasoned about the same way you reason about a distributed system.
The primitives are:
The key insight is not just that a Business can be modeled this way. It is that when a Business is modeled this way, the operator gains a control surface that has never existed before. Every state is inspectable. Every steer is a typed API call. Every financial number is derived from the same ledger.
But the operator still needs a cockpit. Having a programmable Business and having a CLI are not the same thing. management.studio is the cockpit layer: the instrument panel, the control surface, and the decision queue, built on top of the Business-as-Code execution backend.
The analogy holds tighter than it sounds.A pilot does not rewrite the aircraft’s flight computer mid-flight. They read instruments, adjust controls, and decide when human judgment is needed. An operator does not rewrite the Business’s Workflow contracts during a live run. They observe the fleet, steer Workers, and resolve the decisions that require human authority. The cockpit is the interface between the runtime and the human.
The three verbs of management.studio. Every instrument, control, and queue maps to one of these.
The first job of the cockpit is to show you what is happening. Not a summary from six hours ago. Not a hand-curated Slack update. The live state of every Worker, every in-flight Workflow, every recent Action, and the current P&L — all in one view, role-gated by Vantage.
The data is federated from the execution backend: management.studio reads state, it does not own it. This is a deliberate architectural choice. The source of truth for Worker state, Workflow execution, and the Action ledger lives in the runtime. The cockpit presents a materialized, real-time view of that ground truth. Operators with different Vantage scopes see different slices:
Cross-business fleet view. All Workers across all Businesses in the Studio. Aggregate P&L, burn rate, runway. Suitable for a portfolio operator or an engineering lead watching the whole system.
One Business at a time. Full Worker fleet for that Business, all in-flight and completed Workflows, the live Action log, the Respond queue, and the Business-level P&L: revenue, cost, margin, burn, runway.
A team of Workers within a Business. Assignments, active Workflows, recent Actions, goal progress. Financial view is scoped to team-attributable costs and output.
One Worker’s own state. Assigned Workflows, pending HITL decisions they authored, their own Action history. No cross-Worker visibility.
The observability layer was the first thing we built and the thing we have rebuilt most. Real-time fleet state is deceptively hard: you need a materialized view that is consistent enough for operators to trust, responsive enough to surface emergencies before the window closes, and scoped tightly enough that a Business Operator cannot accidentally see another Business’s data. Vantage resolver handles the scoping; the federated read layer handles the freshness.
The result is a cockpit where the most common operator question — “what is happening right now?”— has a deterministic answer at any given moment.
Observation without control is a monitoring wall. management.studio is a cockpit, which means operators can act. The control surface is deliberately minimal: a small set of typed operations that cover the cases that actually arise when running an autonomous Business.
worker.pause // halt a specific Worker's active Workflow worker.resume // resume after a pause or HITL resolution worker.setMode // full-auto → supervised → manual business.pause // halt all Workers in a Business simultaneously workflow.abort // terminate an in-flight Workflow and log reason worker.reassign // move a Worker to a different Workflow
Each of these is a Tool invocation at the execution backend. The cockpit is the interface; the execution backend is the authority. State changes propagate to the runtime; the SVO Action recording the control is written to the Business ledger simultaneously. Every steer is auditable. If an operator paused a Worker, there is a record: who, when, with what reason.
The architecture is federated in the write direction too. management.studio does not own Worker state; it issues typed commands to the backend that owns it. This is not a paperwork distinction. It means the cockpit can be authoritative about what was requested without having to be the system of record for what actually happened. The execution backend resolves conflicts, the cockpit surfaces results.
The single most important control is business.pause. When something goes wrong — a pricing error, an Agent going off-script, a downstream API returning bad data — an operator should be able to freeze the entire Business in one action, with confidence that every Agent stops, every in-flight Workflow is suspended, and no further Actions are taken until they lift the pause. That is the emergency brake. It exists.
Autonomy modes are not binary. The transition from full-auto to human oversight is a dial, not a switch. worker.setMode moves a Worker along that dial: full-auto (Agent proceeds without confirmation), supervised (Agent proceeds but notifies), manual (Agent pauses for every non-trivial decision). Different Workers in the same Business can be at different points on the dial.
A fully autonomous business is a useful fiction. In practice, there is a class of decisions an Agent should not and cannot make alone: high-stakes financial authorizations, legal commitments, regulatory edge cases, situations where the Agent correctly recognizes it is operating outside its competence boundary and escalates.
The Respond surface is the queue for those escalations. An Agent pauses mid-Workflow, attaches full context — what it was doing, what it encountered, what the candidate responses are, what the consequences of each choice are — and surfaces the decision to the appropriate human operator, with a clock running.
Card authorizations above the auto-approve threshold. Invoices that exceed the Workflow’s pre-authorized spend. Wire transfers. Refund decisions above policy limits. These arrive with the full transaction context, the Stripe event, and the relevant Business policy.
A customer request that falls outside the Workflow’s scope. An Agent that has reached its confidence boundary. An input that the Workflow contract explicitly requires human review for. The escalation includes the conversation or event transcript.
Contract signature, regulatory sign-off, policy exception. These are not latency-sensitive, but they are authority-sensitive. The HITL queue routes them to the operator with the right Vantage scope to resolve them.
The SLA is real. If an escalation is not resolved within the window — 90 seconds for financial authorizations, configurable for other classes — the escalation engine bumps it up: to a senior operator, to a phone notification, to a Business-level pause. The Business does not silently drift while a decision sits unattended.
Every resolution is itself an SVO Action: who resolved it, what they decided, at what time. The ledger is continuous. An operator reviewing the history of a Business can reconstruct exactly which humans made which decisions and when, alongside every Agent action.
1,711 tests cover the HITL subsystem, across four phases of implementation. The testing surface includes escalation creation, routing by Vantage scope, SLA tracking, escalation on timeout, resolution recording, and the financial authorization flow end-to-end. The system is not aspirational; it is tested.
The most novel piece of management.studio is the financial layer. Every other cockpit shows you operational state. This one shows you the money, live, derived from the same Action stream that drives everything else.
Each Business gets one or more virtual Stripe Issuing cards, with per-Business spending limits. When an Agent needs to make a purchase — a tool subscription, a vendor payment, a contractor invoice — it uses the Business’s virtual card. The card issuer evaluates the authorization request against the card’s configured limits before the charge goes through.
High-risk authorizations — a vendor the Business has not transacted with before, a charge near the card limit, an amount flagged by the risk evaluator — are escalated to the Respond queue using the same HITL mechanism as operational decisions. The operator sees the pending authorization, the merchant details, the risk flag, and the relevant Business context. They approve or decline in the same queue where they handle other HITL decisions. Financial control and human oversight share one flow.
This is the integration that matters. It is not a separate payments dashboard, a separate risk console, and a separate operations view that an operator has to tab between. The card authorization is a Business event; it arrives in the Business event queue; it is resolved the same way every other Business event is resolved.
The accounting model is honest about its current state.The live P&L is a cash-basis approximation: revenue on receipt, costs on incurrence. Double-entry general ledger, accrual accounting, and LLM-assisted bookkeeping are on the roadmap — they are not shipped yet. What is shipped is a real-time view of cash in, cash out, and the resulting margin and runway. For early-stage autonomous businesses, that is more useful than a quarterly closing.
management.studio is one product in a family. Understanding where it sits makes the design choices legible.
The important property is that management.studio does not care how the Business was built. A Business minted by startups.studio, a Business configured by hand against the substrate API, a Business assembled by a different tool entirely — if it speaks the .studio primitive contract (Workers, Workflows, SVO Actions, financial primitives), management.studio can observe and operate it.
This is the operating layer of the autonomous business stack. Not the only layer, but the one that stays on screen the longest after launch.
Build it in the factories.
Run it here.
The current system covers the critical path: observe the fleet, control Workers, respond to HITL decisions, read the live P&L, issue virtual cards, gate high-risk authorizations. That is the cockpit at Phase I. The shape — observe / control / respond — will not change. What fills in around it will.
Move from cash-basis P&L to a proper general ledger: credits and debits, chart of accounts, period closing, accruals. LLM-assisted bookkeeping that classifies transactions against the GL automatically and surfaces exceptions for human review. The Respond queue becomes the bookkeeping review queue.
Define new Workflows from the cockpit itself: describe the task in natural language, let the system scaffold a Workflow contract, review and approve the typed output, deploy to a Worker. The cockpit becomes the authoring environment, not just the operating environment.
Full Business generation from the cockpit: define the Business’s purpose, its Worker roles, its revenue model. The system scaffolds the Business-as-Code object, instantiates the Workers, and hands off a running Business. No separate factory needed for simple Business shapes.
Two non-obvious things on the roadmap that are worth naming:
Terminate and enforce. Today an operator can pause a Worker. A future version will support a harder enforcement mode: if a Worker in manual-mode takes an Action outside its sanctioned scope, the system automatically revokes its execution credentials, terminates the session, and generates an incident report. The cockpit enforces the contract, not just reports on it.
Cross-Business intelligence. A Studio Operator running multiple Businesses sees patterns that no individual Business Operator can see: which Workflow shapes recur, which escalation classes appear across multiple Businesses, which cost structures are high compared to peers. The Studio view becomes an analytics surface, not just an aggregate operational view.
The plane gets instruments we have not built yet. The cockpit shape — observe, control, respond — is not going to change. That is the right shape for running an autonomous business, and we are confident in it.
management.studio is not a slide deck. It is a running system. The observe plane is live, the control surface is wired to a real execution backend, the HITL queue works end-to-end, and the financial layer reads from Stripe in real time. If you have a Business on the .studio substrate, you can operate it from the cockpit today.
The system has been built in four phases, with 1,711 tests across the full surface — HITL routing, Vantage scoping, financial categorization, control operations, escalation engine, virtual card authorization flow. We test what matters and report the real number.
If you are building an autonomous business and want to see what operating one from a real cockpit looks like, sign in. If you are building on the .studio substrate and want to wire your Business to the management layer, the integration is straightforward — your Workers, Workflows, and Actions are already the right shape.
Frontier AI can run a business. What it cannot do is watch itself, steer itself when it drifts, approve the decisions that require human authority, or read its own P&L in real time. That is the operator’s job. And the operator needs a cockpit, not a stack of dashboards.
management.studio is that cockpit. Built on Business-as-Code, federated from the execution backend, wired to real financial data, with a HITL queue that has SLAs and an escalation engine. The plane is built. The instruments are live. Get in.