The Control Plane for AI Autonomous Companies: Three Lanes That Keep Agents Controllable

"Autonomous company" sounds like a model-selection question—pick the right model and everything runs on autopilot. But in practice, what matters isn't the model itself, but the design of a control plane. Based on a technical blog post that sparked discussion, this article breaks down a control plane designed for a small services company: every task is sorted into one of three lanes—workflow, agent, or human—and the boundaries are enforced at the code level.

Why the control plane matters more than model selection

The original article uses a small services company doing lead intake as an illustrative scenario (the author explicitly notes this is an example, not a customer case, and shares no outcome data). The core argument: what really determines the success of a so-called "autonomous company" is how tasks are routed, how tool permissions are restricted, and which actions must be decided by a human—and none of this should live in prompts. It should live in code.

This judgment cross-validates with mainstream industry views. Anthropic's guidance notes that codified workflows offer predictability on well-defined tasks, while agents introduce higher costs and compounding errors, and should therefore be tested in sandboxes with guardrails. Salesforce's "hybrid reasoning" likewise advocates combining deterministic logic with adaptive AI. The three lanes are a minimalist way to achieve exactly this kind of hybrid.

Control plane: The term is borrowed from networking and cloud computing, where it originally refers to the core component responsible for system configuration, routing decisions, and policy distribution, as opposed to the data plane that carries the actual data flow. In the AI agent context, the control plane refers to a scheduling layer implemented in deterministic code outside the model: it decides which processing path a task flows into, which tools may be called, and when a human must step in. Separating control logic from prompts means these rules no longer depend on the model's probabilistic compliance, but can be versioned, audited, and tested like infrastructure configuration. This is the technical meaning behind the original article's emphasis on "code rather than prompts"—the control plane corresponds to the policy layer, not to the intelligence itself.

Three lanes: workflow, agent, human

The original article defines three task categories using an enum type:

• WORKFLOW: Fixed steps; the model makes no decisions. E.g., capturing a lead, sending a template email.
• AGENT: The model chooses steps within defined limits. E.g., reading the CRM and drafting a reply.
• HUMAN: A person makes the decision. E.g., pricing a quote.

Each task is modeled as a data structure carrying a name, its lane, a list of callable tools, and a flag for whether approval is required. In the sample code, capture_lead and send_reminder belong to the workflow lane and may only touch crm.create and email.send_template; draft_reply belongs to the agent lane and can read/write the CRM and draft emails; quote_price is handed entirely to humans with no tools exposed.

The value of this division is that it turns "who can do what" into static, auditable configuration rather than relying on the model to restrain itself at runtime.

The key difference between workflows and agents is the determinism of decisions. A workflow is an orchestration of predefined steps; each step's inputs, outputs, and tool calls are fixed at design time, and the model plays no part in branch selection, making behavior predictable and costs controllable. An agent lets the model choose its next action at runtime based on context—more flexible, but it introduces compounding errors: a deviation in an earlier step can be amplified by later steps, and token consumption rises with each additional step. Assigning a task to a lane is essentially a trade-off between determinism and flexibility. The original article's enum design makes this trade-off explicit, turning each task's degree of autonomy into a reviewable configuration item rather than something implicit in vague prompt descriptions.

The router: writing boundaries into code, not prompts

At the heart of the control plane is a routing function. It logs at task start, then decides in order: if the task belongs to the human lane or is flagged as requiring approval, it goes straight to the human queue; if it belongs to the workflow lane, it executes the fixed steps; otherwise it goes to the agent, with the task's declared tool list passed in as allowed_tools.

The original article stresses that three things live in the router rather than in prompts: which tools a task may touch, which tasks require approval, and which actions get logged. This is the key distinction of the entire design—prompts can be "talked around" or ignored by the model, but branches in code cannot.

allowed_tools is a capability whitelist mechanism: a task declares in its data structure which tools it may call, the router passes that list in before execution, and the agent can only act within that scope. This aligns with the security principle of least privilege—each task receives only the minimal tool set required to fulfill its responsibility, compressing the possibility of unauthorized actions down to the configuration layer. Compared with soft constraints like "don't send emails" written in a prompt, a whitelist is a hard block: even if the model is induced or hallucinates, tool calls not on the list simply cannot happen. This mechanism makes permission boundaries independent of model behavior, turning them into a statically checkable security property.

Incident handling: a pause switch and accountable owners

The control plane also includes a minimal incident-handling mechanism: maintain a set of paused tasks, provide a pause function that adds the task name to the set and records who performed the pause. The routing function checks this set at start, and paused tasks no longer execute automatically.

The original article lays out two hard requirements: pausing must have an accountable human, and the log must record who flipped the switch. This seems simple, but it is the missing piece in many "autonomous" systems—when something goes wrong, no one can say who to contact.

Three red lines to encode first

The original article offers three red lines that should be prioritized in code:

1. Money, contracts, and customer commitments always go to a human. The cost of errors in these actions is irreversible and unsuitable for a probabilistic system.
2. Every agent action has a log entry containing inputs and outputs. Traceability is a prerequisite for post-hoc audits and incident retrospectives.
3. Every task has a named owner and a kill switch. Tasks without ownership should not exist.

These three align with Anthropic's recommendations on sandboxes and guardrails, and echo Microsoft's 2025 Work Trend Index description of "humans set direction and step in as needed"—the control plane is precisely how "stepping in as needed" becomes an executable mechanism rather than a slogan.

What this is not

The original author draws clear boundaries: this design cannot prove that a company can run itself. It solves a control problem, not a capability problem. Humans still set direction and step in when needed; the control plane's role is to give that intervention a concrete landing point—a pause button, an approval queue, a log with accountable owners.

For teams bringing agents into business processes, the takeaway from this framework is: design the lanes and red lines first, then talk about degrees of autonomy. Models will change; the structure of the control plane can remain.

(The original author is Tej Pandya, founder of GrowEasy.ai.)