Distributed Responsibility Is Still Responsibility

Distributed systems create a recurring moral and managerial mistake: because no participant controls the whole result, each participant begins to feel responsible only for a small local action.

Daniel Dennett’s account of distributed competence helps expose the mistake. A system can produce coordinated behaviour without a central controller. Its outcome emerges from many local contributions, feedback loops and learned routines.

But distributed causation does not make responsibility disappear. It changes how responsibility must be recorded and exercised.

“I only did my part” is not a control mechanism

Technical organisations divide work for good reasons. Product, engineering, security, operations and external specialists cannot all make every decision together.

The division becomes dangerous when it also divides awareness of consequences.

An engineer implements a requested feature. A reviewer checks style and tests. A manager approves the deadline. An automated service performs the release. Every local step can be procedurally correct while the combined action still creates harm or violates an obligation.

The sentence “I only wrote the code” describes a role boundary. It does not prove that the action was neutral.

Separate proposal, authorisation, execution and result

Reliable accountability begins by refusing to collapse the whole chain into one status such as done.

For a consequential action, preserve four distinct facts:

  1. Proposal — what action was suggested and on which assumptions.
  2. Authorisation — who accepted the action and under which policy or boundary.
  3. Execution — what was actually committed to the external system.
  4. Result — what became observable after execution.

The distinctions matter even more when AI participates. A model may propose one action, a policy layer may permit a narrower action, a tool may execute something different because the state changed, and the external result may still fail.

If the record contains only the model output or the successful tool response, the organisation cannot reconstruct the decision.

Give AI room without giving away responsibility

AI should be allowed to do substantial work while a human subject retains control and responsibility.

That does not require a confirmation dialog before every reversible step. Excessive approval requests merely teach people to click through them.

A fresh human decision is needed when at least one of these conditions changes:

  • the goal of the work changes;
  • the action becomes difficult to reverse;
  • the action communicates or commits on behalf of a person or organisation;
  • the consequences can no longer be adequately inspected and repaired by the responsible owner;
  • the evidence supporting the original authorisation is stale or no longer applies.

Within a stable goal and a reversible boundary, automation can act autonomously. Outside that boundary, it must stop with enough context for a real decision.

Responsibility needs named owners

“The team owns it” is often too vague for an operational system.

Ownership should identify at least three roles:

  • the person accountable for the obligation being protected;
  • the person or service authorised to execute the action;
  • the person responsible for observing the result and initiating recovery.

One person may hold more than one role, but the roles should not be implicit.

This is especially important for external specialists. They may contribute code or analysis without owning the product’s final commitment. The organisation must define what they may decide, what evidence they must provide and who accepts the resulting change.

A compact accountability record

For changes with external or irreversible consequences, keep a small durable record:

  • action identifier and idempotency key;
  • intended outcome;
  • relevant assumptions;
  • authorising owner and policy version;
  • exact executed action;
  • public or system receipt;
  • observed result;
  • recovery owner and next review time.

This is not paperwork for its own sake. It prevents a retry from inheriting an obsolete permission, distinguishes an intended action from a completed one and makes failure recoverable without guesswork.

The managerial test

Ask one simple question after a significant action:

Can we reconstruct why this happened, who accepted it, what the system actually did and what happened next?

If the answer depends on memory, private chat or one person’s availability, responsibility has already dissolved into the organisation.

Distributed competence is one of the strengths of a modern technical team. Distributed responsibility becomes a weakness only when the organisation uses complexity as an excuse to avoid ownership.

Source episode: Why Can a System Be Smarter Than Its Leader? | Daniel Dennett