The agentic organisation

The agentic organisation is AR Labs' framework for designing a company in which roles can be carried out by AI agents (language models run in a loop with tools, so they can act, not only reply) as well as by people. Its premise is that a corporation is a kind of software: a set of roles, information flows and decisions that can be specified precisely enough for an agent to take a role on. The design work is in the management layer between strategy and tasks, which in a conventional company is done informally by middle managers, and which agents need written down.

The gap it fills

A one-person company with AI agents typically has two layers in good order: a strategy that says why, and a task list that says what. The layer between them is missing. That is where approach gets decided, where decisions are recorded with their reasons, where blockers are investigated, and where context survives interruptions. People fill it with meetings and memory. An agent that starts each session fresh cannot, so the layer has to exist as documents and records an agent can read and write.

Existing management systems cover parts of this. The Entrepreneurial Operating System from Gino Wickman's Traction, for example, gives small companies vision documents, quarterly priorities and a weekly meeting rhythm, but it assumes a person at every node. The agentic organisation asks what changes when the person running the weekly review, or the department reporting status, is an agent.

Design principles

Design the organisation to produce the system you want. In 1968 Mel Conway observed that organisations build systems that mirror their own communication structures. Matthew Skelton and Manuel Pais, in Team Topologies (2019), describe the inverse move: structure the teams to produce the architecture you want. We apply the inverse move to agents: design the management layer as if agents already ran it.

Build the small version with the shape of the large one. Today one person may fill every role. If the cadences, records and handoffs are designed so that the same structure works whether a role is filled by a founder, by an assistant, or by an autonomous agent, nothing has to be redesigned as agents take roles on. What changes is who acts at each node.

Status flows up, direction flows down. Departments write their operational status upward; a coordinating layer reads it, assesses it against strategy, and writes direction downward. Each is a defined interface between layers, like a contract between software components.

flowchart TD
  F["Founder: governance, vision, approval of pivots"] --> O["Coordinating agent: reads status, writes direction"]
  O -->|"strategic direction"| D1["Engineering"]
  O -->|"strategic direction"| D2["Content and marketing"]
  O -->|"strategic direction"| D3["Research and infrastructure"]
  D1 -->|"operational status"| O
  D2 -->|"operational status"| O
  D3 -->|"operational status"| O
  O -->|"decisions beyond its authority"| F

Delegation has levels. A delegation model states which decisions an agent may take on its own, such as ordering routine tasks, and which it must escalate to a person, such as strategic changes or commitments outside the company.

Threads, seats and handoffs

The agent model at the centre of the framework uses five terms.

Term	Meaning
Thread	A durable line of discussion or work that outlives any one device, session, agent or model
Seat	An organisational role, such as chief executive or systems architect, with a mandate, authority limits, required context, tools and an expected output
Occupant	The agent or model temporarily filling a seat
Channel	A replaceable way in: a terminal, a chat app, voice, a visual canvas
Handoff	The explicit record made when a thread crosses from one seat to another, carrying decisions, open questions, linked work, constraints and the exact next action

The state belongs to the organisation, not to whichever device, application, model or session is in use. The durable thread, not a chat session, is the unit of continuity. When work crosses a boundary of responsibility, it produces a handoff rather than the current agent stretching into another discipline. And unified access does not mean one undifferentiated database: threads own conversation, seats own role context and authority, the task system owns task lifecycle, and memory systems help retrieval but never become the authority on tasks or approvals.

Build and rent

We separate what we build from what we rent. We expect much general agent tooling to become commodity, and put our effort into what we expect to stay hard: governance, a person's view and control of agent work, and interfaces that fit how people think. So we build the presentation and orchestration layers, the interface through which a person supervises agents, and rent the execution layer: agent sessions, the task database, networking and code hosting come from existing tools.

What exists today

Our own records follow a version of this design: a coordinating strategy agent with review cadences from daily to quarterly, one shared document for status flowing up and another for direction flowing down, and all work held in a single dependency graph of tasks. More than one agent now runs independently, and agents exchange messages through a shared mailbox. The shared substrate of threads, seats and handoffs is at the architecture-exploration stage; its first proof is planned as a single thread that starts in one session, passes through a second seat, and returns its decision to the place it began without being restated.

How work is ordered and routed between these seats is the subject of the intelligence is in the ordering. How each agent's instructions are kept coherent is the subject of logical levels.