Build Loop

Abstract

The wrong way to think about AI is as a passive feature that sits in the background and waits for commands. In real organizations, agents behave more like actors. They respond to signals, shape behavior, leave traces, alter review patterns, and change how responsibility moves through the workflow. Once that happens, the question is no longer whether the agent exists. The question is what role it plays in the system.

This essay argues that Reworking Order should treat agents as participants in an operating environment, not as decorative add-ons. That means designing the scripts, permissions, review paths, and accountability structure around them. It also means keeping humans in control of the most consequential moves while allowing agents to operate as real contributors inside bounded systems.

The practical takeaway is simple: if AI is going to change the work, it has to be treated as something with behaviour, not just output.

Not A Feature, A Participant

Most business language about AI is still too shallow. It treats the system as a feature: something you turn on, use, and move past. That language works for utilities. It does not work for agents.

An agent is different because it acts inside a workflow. It receives signals, interprets context, generates output, and influences the next step. Even when a human remains in charge, the agent can still change the shape of the work by altering the pace, the review burden, the quality threshold, and the amount of explanation required downstream.

That is why "participant" is the better word.

A participant is not independent. It is not sovereign. But it is also not inert. It is part of the coordination system. It changes what other actors do. In that sense, an agent is more like a coworker with a script than a tool on a shelf.

That framing matters because people keep trying to manage agents as if they are static utilities. They are not. They are active inside the system whether the organization admits it or not.

Once the agent is treated as an actor, the design questions get more serious:

What is it allowed to do?
What signals can it respond to?
What does it escalate?
What does it leave for humans?
What traces does it create?
What happens when its output becomes the input for another actor?

Those are actor questions, not feature questions.

Scripts, Roles, And Responsibility

The agent becomes meaningful through the script it is given.

If the script is vague, the system becomes noisy. If the script is too rigid, the agent adds little value. If the script is well designed, the agent can absorb work without breaking the surrounding process.

This is why the right comparison is not "human versus agent." The right comparison is different configurations of actors inside a shared system.

For example:

In support, an agent can triage, draft, and classify, while a human handles exceptions and emotional edge cases.
In product work, an agent can generate options, summarize feedback, and test assumptions, while a human defines the feature and owns the release.
In operations, an agent can monitor, flag, and propose actions, while a human validates risk and approves consequential moves.

In each case, the agent is acting. But it is not acting alone. It is acting inside a role.

That is why the human-centred principle still matters. Humans should define the objective and authorize consequential action. Agents can expand the option space, compress execution, and make the system more responsive. But if the human does not own the role definition, the system becomes harder to explain and harder to trust.

That trust issue is not superficial. People do not just want results. They want to know why the result exists and who stands behind it. An actor model makes that legible.

It also gives leaders a better way to think about delegation. Instead of asking whether the agent is "smart enough," ask whether the role is bounded well enough for the agent to act without creating hidden risk. That is a much more useful business question.

Traces Make The Actor Visible

If an agent is an actor, it leaves traces.

Those traces are what make the system legible:

prompts
versions
comments
approval logs
exception paths
handoff points
audit history

That is also where the organizational value sits. Traces show how the actor behaved in context. They show which signals it responded to. They show where the workflow bent. They show where the human had to intervene.

This is one reason actor language is more useful than feature language. A feature disappears into the interface. An actor leaves evidence.

The practical implication is that organizations should design for traceability from the start. If the traces are weak, the system becomes difficult to govern. If the traces are strong, the system becomes easier to improve.

This is where the ideas from actor-network theory become useful. Not because the business needs academic theatre, but because the theory helps explain something simple: work is distributed across humans, systems, policies, and artifacts. Agency is not trapped inside a single person or a single machine. It is carried by a network.

That network is the real object of design.

When leaders understand that, they stop asking only "What can the agent do?" and start asking "What network of actors does this change create?"

That is a better operational question.

It also explains why the same agent can work well in one setting and badly in another. The issue is not just capability. It is the surrounding environment. The actor behaves differently depending on the signals, constraints, and review paths around it.

Power, Visibility, And Control

Treating agents as actors also makes power more visible.

An organization that says humans are in control may still have a workflow where the agent shapes the options, the dashboard shapes attention, the policy shapes what can be attempted, and the review process shapes what survives. Power is not always where the title says it is.

That is where a Foucauldian lens helps. Power often works through visibility, normalization, and examination. The important question is not only who issues commands. It is what the system rewards, what it makes legible, and what it trains people to do repeatedly.

In AI work, that matters a lot. If an agent makes certain actions cheap and others expensive, the system begins to normalize a new behaviour pattern. If a dashboard shows one class of performance and hides another, the system teaches people what matters. If a review gate catches certain errors every time, it changes how the team thinks about risk.

In other words, the agent does not just participate in work. It participates in the shaping of power inside the work.

That should not be treated as a critique in the abstract. It should be treated as an operating fact. Every AI deployment changes the distribution of attention, approval, and responsibility. If you do not design that explicitly, the system will design it implicitly.

This is also why the actor frame is preferable to a pure automation frame. Automation implies a one-way replacement. Actors imply relationship, response, and interaction. In business settings, that is closer to reality.

The Practical Rule

The practical rule for Reworking Order is this:

Treat agents as actors inside a designed system, but keep humans as the source of intention, authorization, and accountability for consequential change.

That rule gives you the right kind of flexibility.

It lets agents participate in real work. It lets humans remain responsible. It keeps the system legible. It preserves room for trust calibration. It makes the traces meaningful.

It also fits the broader thesis of the practice. We are not trying to build a world where agents replace people. We are trying to design a world where work is rebundled intelligently, where actors have clear roles, and where the human still owns the change that matters.

That is the difference between treating AI as a feature and treating it as a participant.

Diagram

Each actor changes the next step, and the outcome feeds back into the next round of intention. The workflow, not the isolated actor, is the system.