Requisite Variety: Why One AI Agent Cannot Run a Company

7 min read Agents Workflows

Ashby's law explains why reliable AI operations need roles, tools, constraints, and escalation instead of one general agent.

A general AI agent can write code, summarize a contract, draft an outreach email, and inspect a spreadsheet. That breadth makes a single-agent operating model tempting. Give one model every tool, every policy, and every task, then let it decide what to do.

The model soon faces more situations than its instructions can distinguish. A refund request may involve customer history, legal terms, payment state, fraud risk, and an exception approved last month. Adding more context expands the prompt, but it does not create the authority, specialist checks, or escalation paths needed for every combination.

W. Ross Ashby described the underlying constraint as the law of requisite variety: only variety can absorb variety. A regulator needs enough possible responses to counter the relevant states of the system it controls. For AI operations, this means reliable capacity comes from an organized set of roles, tools, policies, workflows, and human judgments rather than one agent persona.

What is requisite variety in AI operations?

Requisite variety means the operating system must distinguish and handle the meaningful situations its environment can produce.

Variety is not a count of prompts or model parameters. It is the range of states that require different responses. Consider a small agency preparing a client release:

  • the build passes or fails
  • the change is routine or security-sensitive
  • the client has approved copy or has not
  • the deployment is reversible or destructive
  • the worker has the required credentials or does not
  • the result fits the budget or exceeds it

These conditions combine. A regulator that knows only “release” and “do not release” lacks the variety to handle them safely. It needs branches, checks, authority boundaries, and somewhere to send cases it cannot resolve.

Why does one general agent fall short?

A capable model can reason across many domains, but the surrounding operation still has limits.

Limit What the single agent lacks Operational consequence
Context Current, scoped information for every decision Stale or irrelevant material influences action
Tools Deterministic access to every required system The agent guesses, narrates, or stops
Authority A legitimate right to take each action Access becomes broader than responsibility
Verification Independent ways to judge different outputs The agent grades its own work with the same blind spots
Attention Capacity to inspect every exception deeply Rare cases receive generic treatment
Accountability A clear owner for policy and outcome Failures become difficult to diagnose and correct

Changing to a larger model may improve reasoning within these constraints. It does not remove them. Model capability is one source of regulatory variety, not the whole regulator.

How do roles and workflows create useful variety?

Useful distributed variety comes from differences that correspond to real operational states.

A support agent may have current product guidance and permission to draft replies. A finance reviewer may evaluate credits above a threshold. A workflow may require a deterministic account-state check before either acts. A human may decide cases involving contractual ambiguity.

Each part handles a range it can model and passes the rest onward.

incoming case
  | routine and verified -> agent action
  | specialist condition -> specialist role or workflow branch
  | missing evidence -> request information
  | authority exceeded -> human approval
  | unknown condition -> stop and escalate

This structure creates more possible responses without giving every participant every capability.

What are amplification and attenuation?

Ashby treated regulation as a balance between amplifying the regulator's possible responses and attenuating the disturbances that reach it.

Amplification adds useful response variety:

  • a specialist model or role
  • a tool that exposes current state
  • a workflow branch for a known exception
  • a verifier suited to the artifact
  • a human with legitimate judgment

Attenuation reduces irrelevant or unsafe variety before it reaches the decision:

  • scoped permissions that hide unrelated data and actions
  • schemas that reject malformed inputs
  • queue filters that group equivalent cases
  • budget and time bounds
  • approved policy versions rather than an unbounded document dump

Attenuation is often more valuable than another agent. A worker preparing a client report does not need every document in the workspace. It needs a small set of potentially relevant paths and the ability to fetch an exact source deliberately. Restricting context reduces the number of accidental states the model must interpret.

When does distributed variety become uncontrolled complexity?

More agents, tools, and branches can create a system nobody understands. Variety is useful only when its ownership and coordination are explicit.

Useful distribution Uncontrolled complexity
Roles correspond to distinct authority or evidence Personas differ only by name and prompt tone
A workflow explains handoffs Agents message one another through hidden conventions
Each verifier has a defined claim Several agents produce overlapping opinions
Escalation has a destination and context Failure bounces between participants
Versions identify which policy ran Instructions change in place without history

A one-person builder may need one agent, one deterministic check, and one approval. A small team may need specialist roles for finance, product, and customer operations. Requisite variety does not prescribe a large hierarchy. It asks whether the available responses match the disturbances that matter.

How should humans add variety?

People are most useful where a case is novel, values conflict, evidence is incomplete, or consequences exceed delegated authority. Human judgment adds responses that the automated regulator does not have.

That judgment remains scarce. Management by exception keeps people from becoming the default branch for every case. Routine work should absorb routine variety below the human level, while the inbox receives cases that genuinely require interpretation.

A good escalation also teaches the system. It records why the existing regulator was insufficient. Repeated cases can justify a new check, clearer policy, specialist role, or workflow branch. The change should still be proposed and reviewed rather than inferred silently from one answer.

How can a team audit its regulatory variety?

Choose one recurring operation and list the disturbances seen in recent executions. For each disturbance, identify the current response and its owner.

Question Evidence to inspect
Can the system detect the condition? Inputs, state records, verifier outputs
Does it have a distinct response? Workflow branch, tool, policy, escalation
Is that response authorized? Role and permission boundaries
Can it establish the result? Independent check or attributable review
Can unresolved cases stop safely? Retry bound, budget cap, inbox action

Gaps reveal missing variety. Duplicate responses reveal complexity that can be removed.

How does Task Machine distribute variety?

Task Machine lets humans and agents share work through explicit agents, teams, tasks, workflows, permissions, skills, connectors, verifiers, and approvals. Its three surfaces separate strategic direction in Chat, decisions in the Inbox, and detailed intervention in Tasks. These constructs are one way to organize variety around real work rather than one all-purpose agent.

The product cannot decide which distinctions matter for a company. A team still has to define policy, choose checks, and decide where human authority belongs. Task Machine records and runs those choices so they can be inspected and revised.

The complete cybernetics for AI operations series

Continue with the good regulator to examine the internal model an agent needs before any of those responses are trustworthy.

Put the work you just read about on rails

Join the waitlist and we will send early access when the first private beta spots open.

Private beta. We invite teams in batches and never share your email.