Tasks Flow, Responsibility Doesn't: Why Task Contracts Are Essential in the AI Era

The article opens with a familiar organizational failure: a customer order triggers a cross-departmental scramble where everyone participates but no one owns the delay. The same fracture appears in shift handovers and, critically, when a digital employee (an AI agent) automatically processes a refund that should not have been approved — leaving no trace of which rule version authorized it, who granted permission, or who is accountable.

The Core Problem: Responsibility Evaporation at Handoffs

Tasks flow across people, departments, systems, and now digital employees, but the agreement on "what this task is based on, who owns the result, what authority is granted, what counts as done, and who takes over when stuck" does not travel with the task. That agreement is the Task Contract (TC) — a dynamic, minimal rights-and-responsibilities carrier that moves with the task.

What Is a Task Contract? The Five-Element Skeleton

A TC answers five questions at every handoff:

Outcome — what result is required and what proves completion.

Boundary — authorized actions, resources, time, and budget.

Key Judgments — which few decisions (based on which fact version) are reserved for a named authority.

Evidence — what artifacts prove the result and where they come from.

Escalation — conditions and owners for exception handling and takeover.

These five elements are universal; their explicit thickness varies with risk.

Historical Precedents: Military Orders, Kanban, and Construction Tickets

The article shows that TCs are not new. The Prussian Auftragstaktik (mission command) uses a five-paragraph field order (SMEAC) that includes Commander's Intent so subordinates can act autonomously when communications fail. Toyota's kanban cards are micro-contracts moving with parts. Construction sites use task orders and technical briefings signed by foremen. Commercial contracts and Statements of Work (SOW) are inter-organizational TCs. In all cases the contract was implicit, carried by human common sense and hierarchy.

The IT Era: Fragmented Contracts Across Systems

ERP, BPM, ITSM, SLA, OLA, RACI, Acceptance Criteria, Definition of Done, and Design by Contract each capture a fragment (state, timeline, roles, completion rules, module interfaces). But no single object carries the whole TC across system boundaries. Humans remain the "glue" — reconciling via meetings, chats, and emails.

The AI Era: Agents Already Use Contracts

Distributed AI research has long used the Contract Net Protocol (Reid G. Smith, 1980), where tasks are announced, agents bid, and contracts are awarded. The modern A2A (Agent2Agent) protocol (Google, 2025) standardizes a Task object with states (submitted, working, input-required, completed, failed, cancelled), artifacts, and Agent Cards describing capabilities. Engineers now write agent contracts specifying goal, success criteria, prohibited actions, step/cost budgets, and escalation policies. Microsoft's 2025 Shared Responsibility Model and ServiceNow's risk-proportional governance both insist on clear ownership for every agent action.

Why Now? Three Simultaneous Shifts

Executor change : Humans fill gaps instinctively; digital employees do not. They execute at machine speed, scaling errors in seconds.

Flow change : Tasks now move cross-system, cross-org, human-to-agent at machine speed. Continuity of accountability can no longer rely on human memory or paper trails.

Cost change : Making contracts explicit used to be expensive (paper, approvals). Today templates auto-instantiate, status projects automatically, permissions auto-validate, versions auto-log — marginal cost approaches zero.

The intersection of rising demand (non-explicit contracts break) and falling supply cost (auto-generation) makes TCs a standard object for every cross-node handoff.

Task Contract vs. Orders, Work Orders, and Meeting Notes

The article distinguishes three layers using a single customer order:

Outer layer : Commercial contract / purchase order — inter-organizational result contract (authoritative in ERP/contract system).

Middle layer : Fulfillment Task Contracts — intra-organizational execution contracts (scheduling, procurement, logistics, installation) that reference the order but do not copy it.

Inner layer : Work orders / job tickets in source systems — operational records (authoritative in MES, WMS, etc.).

Meeting minutes, chat logs, and read receipts are communication traces, not responsibility transfers. Acceptance requires explicit acknowledgement. The TC also encodes residual control rights (Grossman & Hart, 1986): who decides when the contract is silent.

Universal but Variable Thickness: Four Tiers

Seven variables determine thickness: cross-entity handoff, independent verifiability, risk/irreversibility, digital-employee involvement, resource pre-commitment, multi-source volatile facts, and hard time/SLA commitments. More variables hit → thicker contract. Four tiers:

Implicit — carried by role norms and tacit knowledge (no explicit object).

Lightweight — auto-generated from template: only this-time assignee, scope, deadline.

Standard explicit — full five elements, human-confirmed key responsibilities.

Thick — item-by-item approval, heavy evidence and escalation chains.

Principle: Contract thickness follows risk, not format. Business differences are handled by configuring templates, thresholds, and acceptance rules on a shared model, not by building separate contract types.

Implementation in MOOS: A Coordination Layer, Not a Business System

Mido's MOOS (Mycelium Organization Operating System) is positioned as the "traffic rules" layer. It does not own business data (orders stay in ERP, tickets in source systems), does not duplicate ledgers, and does not replace ERP/BPM/legal contracts. It sits in the seams, auto-deriving TCs at handoff moments: referencing source documents as fact bases, selecting template thickness by configured risk rules, binding responsibility anchors, evidence, and escalation paths, and versioning every change.

No-explicit tier: single-role, reversible, no handoff → no TC object created.

Auto-lightweight : standard, high-frequency, low-risk → template applied, near-zero user friction.

Human-expanded : urgent, conflict, non-standard, agent-involved → explicit TC with human confirmation of key rights.

Configuration is a one-time setup of three system tiers (no-explicit / auto-lightweight / human-expanded) mapped to the four management tiers. The MOOS workbench shows a unified inbox: task identity, live contract version, result owner, current blocker, required evidence, next actor. Execution completion and acceptance are separate steps.

Responsibility Must Ultimately Land on Humans

Digital employees can execute, judge, and independently verify, but they lack legal personhood. Every executed TC binds four named human responsibility anchors: Result Owner (outcome), Professional Nodes (quality gates), Operations/Maintainers (digital capability upkeep), Authorization Approvers (automation scope and risk acceptance). "The AI did it" is never a valid defense.

Getting Started: From Pain Points to Configured Rules

Managers should not wait for a big-bang rollout. Identify the most fracture-prone, irreversible handoffs. Convene business, quality/risk, legal, and actual doers. For 1-2 high-frequency incident types, walk through the five questions, agree templates and thresholds. IT makes them callable and auditable. Success signals: the same handoff stops recurring; when issues arise, the live contract version and named owner are instantly retrievable; an agent that oversteps is halted in real time, not discovered post-mortem.

Conclusion: Tasks Flow, Responsibility Must Not Evaporate

The Task Contract is as old as human collaboration — military orders, kanban, construction tickets all embody it. The AI era does not invent it; it strips away the human "gap-fillers" that kept implicit contracts working. Now the contract must stand on its own: machine-readable, verifiable, auditable, and always anchored to a specific human at the end of the responsibility chain. That is the unchanging foundation from a field order to an AI agent.