Most agent platforms begin with an agent and a task.

The agent receives a goal, uses a model and a set of tools, produces an artifact, and perhaps asks a person for approval along the way. This is enough to demonstrate agency. It is not enough to construct an organization.

Organizations need to know more than what an actor is trying to accomplish. They need to know which role authorized the work, what resources are available, which effects are legitimate, what evidence must survive, when responsibility changes hands, and who can turn a proposed action into an organizational commitment.

These properties cannot be compressed into a single agent object. An agent is not its role. A role is not a permission set. A permission set is not an execution environment. An approval is not a handoff. When these ideas collapse into each other, the platform may coordinate activity while leaving authority and accountability implicit.

I have been thinking about agentic collaboration through five objects: the Role, the Agent, the Harness, the Habitat, and the Handoff. Not as a complete ontology, but as a way of keeping different institutional decisions from being welded together.

Organization Role
        │
        ▼
      Agent ── operates through ── Harness
        │
        ▼
     Habitat
        │
        ▼
 Handoff Policy

The framework is built around one distinction:

Competence is not authority, and activity is not accountability.

Five Objects, Five Questions

The Role is the institutional position. It defines why the work exists, which decisions belong to it, what obligations accompany those decisions, and where responsibility lands. Researcher, release manager, account owner, reviewer, and risk acceptor are roles before they are people or agents.

The Agent is the continuing actor. It has an identity, goals, task history, working state, and a record of actions. An agent may occupy different roles at different times. A role may be performed by a human for one task and an agent for another. Keeping the two separate prevents the actor’s accumulated history from silently becoming accumulated authority.

The Harness is the machinery of agency. It determines how the agent perceives, reasons, remembers, plans, uses tools, checks results, recovers, delegates, and escalates. Models, system instructions, memory, planning loops, task queues, retries, checkpoints, verifiers, and stopping conditions belong here.

The Habitat is the bounded field of legitimate action. It binds an actor in a role to resources, capabilities, effect policies, enforcement boundaries, and an expiry condition for a particular scope of work. The harness determines how effectively the agent acts. The habitat determines what action is institutionally possible.

The Handoff Policy governs a transition. It defines what must be true when work moves between actors or changes status: what artifact is being transferred, which evidence accompanies it, what uncertainty remains, whose attestation is required, what authority is granted next, and what happens if the receiver rejects or escalates it.

These objects constantly interact. The discipline is to keep them distinct enough that each can change without silently changing the others.

Identity Is Not a Role

Human organizations already understand part of this distinction. A person retains an identity while moving from project to project. Their role determines what they may do in a particular context. Changing teams should change their authority without changing who they are. Leaving a role should revoke its access without erasing the history of what they did while occupying it.

Agent systems often collapse these layers. We create an agent called “Researcher,” place its instructions, tools, credentials, memory, and permissions in the same configuration, and treat the bundle as one thing. Over time it receives new tasks and new access. The name remains stable while the effective authority grows.

This makes both governance and improvement difficult. If the agent performs badly, was the role unclear, the harness weak, the habitat too broad, or the handoff underspecified? If its permissions are excessive, can they be reduced without changing its reasoning machinery? If another agent needs to perform the same role, can the institutional expectations move without copying credentials and private memory?

Separating identity from role makes these questions answerable.

A role should say what the organization expects. An agent should say who acted. A harness should say how the work was performed. A habitat should say under what authority it occurred.

A Habitat Is Larger Than a Sandbox

When the conversation turns to agent safety, we usually reach for a sandbox. The sandbox restricts processes, filesystem visibility, network interfaces, compute, memory, and isolation from other workloads. It is a necessary part of an agent’s environment.

It is not the whole environment.

A container cannot decide whether an agent may merge a pull request. A restricted runtime does not know whether it may send an email. Network policy does not determine whether it can read one application folder but not another. These are not only properties of execution. They are properties of institutional authority.

sandbox ⊂ habitat

The same is true of IAM. Identity and access management can bind a principal to permissions, but a habitat also needs to represent purpose, duration, permitted consequences, approval boundaries, evidence requirements, and what happens when the task ends.

A habitat is therefore not simply everything an agent can technically reach:

Habitat =
    resources
  + capabilities
  + effect policy
  + enforcement boundaries
  + temporal scope
  + accountability context

An agent may be technically able to write to a repository while being authorized only to create a branch. It may possess enough information to contact a customer while being authorized only to prepare a draft. Access describes reach. The habitat describes legitimate effect.

The question is not only, “Can the agent do this?”

It is, “Under whose authority does this action become ours?”

Habitats Should Be Dynamic

Authority should follow the work rather than accumulate around the actor.

A persistent research agent might normally have access to a handbook, general research tools, and a private workspace. When assigned to a project, it could enter a task habitat that adds one requirements folder, one repository, and permission to publish into a draft directory. When the task closes, those capabilities disappear while the agent’s identity and task history remain.

Organizational boundary
└── Department context
    └── Project context
        └── Task habitat
            └── Run sandbox

This is not necessarily a simple inheritance tree. A task may narrow departmental access while temporarily adding a project capability. Different authorities may govern different parts: security controls secrets, finance controls spending, a project owner controls scope, and a release role controls deployment.

The important properties are composability, expiry, and revocation.

Within a habitat, it is also useful to distinguish ambient authority from invoked authority. Ambient authority is continuously available: inspect the assigned task, read project documentation, use local computation, and write to the task workspace. Invoked authority is issued for a specific operation: access one customer record, use one secret for ten minutes, deploy one reviewed commit, or send one approved message.

The safer design is not to make the agent permanently powerless. It is to keep ambient authority modest while making narrow authority available when the work actually requires it.

The Handoff Is the Unit of Governance

Work becomes consequential at transitions.

A draft becomes a message. A branch becomes a release. An analysis becomes a recommendation. A recommendation becomes a decision. At each junction, the work changes institutional status. New people may rely on it. New authority may be exercised. Reversal may become more expensive.

This is what a handoff policy should make explicit.

Handoff
├── outgoing role
├── incoming role
├── artifact or state transferred
├── evidence and checks completed
├── unresolved uncertainty
├── required attestation
├── authority granted or revoked
└── rejection and escalation path

A handoff is more than a notification. It is a contract for changing who may rely on the work and what may happen next.

This also clarifies the relationship between habitats and handoffs. The habitat governs what can happen while the work is being performed. The handoff governs when the work leaves that context or acquires a different institutional meaning. A successful handoff may close one habitat and provision another.

Without explicit handoffs, responsibility leaks through informal transitions. A human assumes the agent checked the sources. The agent assumes the human will inspect the details. A reviewer sees the output but not the uncertainty. Everyone participates, but no one can say which condition they accepted.

Coordination happened. Accountability did not.

Approval at the Boundary, Not at Every Step

There are two tempting ways to govern an agent, and both fail for opposite reasons.

The first is to place the rules inside the harness. A system prompt says, “Do not access unrelated files,” while the tools retain credentials that make the access possible. The agent knows the rule, but nothing outside it enforces the boundary.

Prompts shape judgment. They do not create authorization.

The mirrored failure is to put a human approval dialog in front of every command. The agent asks to read a file, run a process, or invoke a tool, and a person presses “Allow” or “Allow always.” This looks like supervision because a human remains in the loop.

But a human click is not the same thing as human judgment.

If a person must approve hundreds of low-level operations, they cannot investigate each one. The approval becomes habitual, and “Allow always” becomes the practical path to completing the work. The interface can prove that someone clicked. It cannot prove that someone understood or accepted the consequence.

Commands are usually too granular and too context-poor to be useful units of institutional judgment. The better principle comes from sociotechnical design: specify only what must be specified, and preserve local discretion everywhere else.

Specify the boundary completely. Do not specify every movement inside it.

An agent should be able to inspect files, run tests, revise a plan, and create artifacts inside an already authorized habitat. Human attention should appear when the nature of the effect changes: when private work becomes public, a proposal becomes binding, authority expands, sensitive information crosses a boundary, or reversal becomes materially harder.

Good governance watches the boundary, not every movement inside it.

Reversibility Buys Autonomy

Not every action needs the same control because not every action produces the same kind of consequence.

Editing a temporary file is easier to reverse than merging a branch. Merging a branch is easier to reverse than disclosing private data. A draft can be deleted. A message already read cannot be unsent in the same sense. A database may be restored while a damaged relationship cannot.

This gives us a basis for deciding where prevention and review belong:

reversible and contained       → act locally, preserve a trace
reversible but consequential   → act with evidence and monitoring
difficult to reverse           → require review or explicit authority
irreversible or catastrophic   → prevent or require formal risk acceptance

Reversibility does not mean that an action is harmless. Rollback may restore state without restoring trust. But it tells us how much room the organization has to learn after acting rather than blocking before action.

Reversibility is what buys autonomy.

A mature habitat combines both strategies. It places hard constraints around catastrophic effects and creates recoverable freedom around ordinary work. It does not force every action through the control appropriate to the worst possible action.

Logs Are Not Attestations

Agent platforms tend to produce abundant traces. They can record prompts, tool calls, arguments, outputs, tokens, latency, retries, and model decisions. This is useful, but volume is not the same thing as accountability.

Three objects need to remain separate.

A log records that something happened. Evidence makes the consequential change understandable: what was considered, what checks ran, what uncertainty remained, and what result followed. An attestation states that an authorized human or machine checked a condition and accepted it.

An approval button is an attestation stripped to its thinnest possible form. If the reviewer cannot see the relevant evidence, does not know what condition they are affirming, or is not responsible for the resulting decision, the click creates ceremony rather than control.

An approval should attest to a consequence, not merely acknowledge a command.

This does not require presenting every internal step. A useful evidence package is itself a designed view. A release reviewer may need test results, changed interfaces, known risks, and rollback readiness rather than the complete transcript of the agent’s reasoning. An accountable role needs the information required for its decision, at the scale at which that decision is made.

Auditability is not recording everything. It is preserving what another actor needs to reconstruct and contest the consequential act.

The Control Plane Builds the Organization

Something outside the agent must compose these objects. That is the role of the control plane.

The control plane assigns an actor to a role, provisions a habitat, selects or configures a harness, evaluates handoff conditions, grants invoked capabilities, records attestations, and revokes authority when the work ends. Different organizational authorities may contribute policies, but the resulting boundary must be legible and non-bypassable.

The harness receives the habitat. It should not be able to redefine it unilaterally.

This matters because self-modification and self-authorization are different powers. An agent might be allowed to revise its plan, reorganize memory, create subagents, or select a better tool. None of those adaptations should silently expand its institutional perimeter.

The same separation applies to learning. Inside the task, feedback helps the agent correct its work. Outside the task, traces and outcomes help the organization change future role definitions, harnesses, habitats, and handoff policies. A repeated failure may look like an agent mistake but reveal a missing check, a weak interface, or authority placed at the wrong layer.

The agent learns inside the habitat. The organization learns by changing the next one.

An Institutional Operating System

An agentic collaboration platform is not complete when several agents can exchange messages and complete tasks. That is orchestration. An organization also needs roles that give work meaning, habitats that bound authority, handoffs that change institutional state, evidence that makes decisions legible, and accountable parties who can accept or contest consequential effects.

The five objects provide a starting point:

Role     = institutional position
Agent    = continuing actor
Harness  = machinery of agency
Habitat  = bounded authority
Handoff  = governed transition

The framework does not make agents responsible in the human sense. It makes their participation governable. It lets an organization separate who acted from who authorized, how work was produced from what effects were permitted, and routine autonomy from consequential commitment.

The harness gives an agent agency. The habitat gives that agency a legitimate field of action. The handoff determines when the result becomes ours.

An agentic platform is not complete when agents can work together. It is complete when the organization can explain how their work became its own.