Skip to content
OWP

1. Introduction

1.1 Motivation

Knowledge work has been governed for centuries by a small set of organisational primitives. A human worker carries a stable identity, occupies a defined role, and operates within a bounded scope of authority. They act on signals — some received from the environment, some self-generated from standing responsibilities. They produce auditable work, escalate when their authority falls short, and are accountable for their outcomes. These primitives are familiar enough that we rarely name them; they are what makes a worker a worker.

Non-human knowledge workers — agents, autonomous systems, automated decision-makers — are routinely deployed without most of them. Identity is often per-invocation rather than stable. Role is often implicit, inferred from the surrounding system. Authority is rarely explicit; when it is, it is rarely machine-checked. Outputs frequently lack provenance, escalation paths are an afterthought, and accountability is hard to assign even in retrospect.

The obstacle to deploying such workers at organisational scale is not the underlying capabilities. It is this structural mismatch: organisations require workers, and what has typically been deployed is something less.

This protocol specifies the missing primitives. It defines, vendor-neutrally and at the wire level, the constructs by which a non-human knowledge worker is given identity, role, authority, signal subscription, intent grammar, escalation paths, and audit-grade accountability.

1.2 Scope

This document specifies:

  • The six primitives required to model a non-human knowledge worker as a first-class organisational entity.
  • Two deployment artefacts that bundle and instantiate those primitives.
  • Three cross-cutting requirements that all conforming implementations MUST satisfy.
  • The runtime semantics of signal delivery, intent generation, intent resolution, dispatch, escalation, and authority enforcement.
  • The contract by which capability providers — including model providers, tool providers, deterministic-code providers, and human-channel providers — are integrated.
  • The structure of the audit envelope and the cost record.
  • The conformance criteria for runtimes that claim to implement this protocol.
  • A profile mechanism by which compliance regimes — regulatory, contractual, or organisational — can be attached to a Function without modifying the core specification.

1.3 Non-Goals

This document does not specify:

  • Which model, framework, or vendor is used to realise a Worker.
  • Which prompts, reasoning strategies, tool-use policies, or generation parameters a Worker employs.
  • How a Capability provider is implemented internally.
  • How a Workforce is hosted, scaled, monitored, or operated.
  • The user interface by which a Worker is authored, observed, or interacted with.
  • The legal, regulatory, or contractual frameworks under which Workers operate. Such frameworks attach as Compliance Profiles per §11.
  • The wire encoding by which the protocol’s abstract primitives are exchanged. Wire encodings are deferred to companion binding documents; see §17.

The protocol is intentionally silent on these matters. They belong to frameworks, products, regulators, and the operating practices built on top of the protocol; vendor neutrality at the protocol layer requires the protocol itself to take no position.

1.4 The Charter Model

This protocol assumes a charter model of organisational work.

In this model, a Worker holds a stable identity and exactly one Role. A Role is a charter: it specifies the Worker’s standing intent, the Signals it consumes, the Intents it can generate or accept, the Capabilities it may invoke, the bounds of its authority, and the escalation paths available to it. The charter binds the Worker; the runtime enforces the binding. Multiple Workers MAY share the same Role concurrently — typically with distinct deployment contexts (per-customer assignment, per-region, per-tenant) — but each Worker is bound to a single Role.

Human principals (§7) are not Workers and follow different rules: a single human MAY hold multiple Human Roles concurrently, since multi-role human participation is the standard pattern in real organisations.

Workflow is not authored. Workflow emerges from Workers acting on Signals within their charters. The trace of a workflow — what happened, by whom, under what authority, at what cost, with what outcome — is captured in the Audit Envelope, an append-only signed record bound to the Intent that originated the work.

This model differs from procedural models, in which a workflow is authored as an explicit graph and Workers (or their analogues) execute steps within it. In the charter model, the procedural graph is a derived artefact, observable through the audit envelope after the fact, not a primary authoring artefact.

The charter model is congruent with how human knowledge organisations work: roles, delegations, signals, judgment, escalation, audit, ongoing performance management. The congruence is load-bearing rather than incidental. The primitives developed for human workers are the primitives non-human workers need too, and the protocol’s correctness should be judged against that fit.

The charter model designates four structurally-distinguished Human Roles that participate in the Workforce: Architects (who author Functions, Roles, and Charters), Reviewers (who review Outcomes and may refuse them), Resolvers (who handle escalated work that exceeds the Workforce’s capability), and Operators (who observe ongoing performance, commission Evaluations, and propose Recalibrations). Section 7 specifies each Role; sections 11 and 12 specify the surfaces (Compliance Profiles, Evaluation, Recalibration) through which these Roles act.

1.5 Document Organisation

Section 2 establishes terminology and notational conventions. Section 3 specifies the six primitives. Section 4 specifies the two deployment artefacts. Section 5 specifies the three cross-cutting requirements. Section 6 specifies runtime behaviour. Section 7 specifies the four structurally-distinguished Human Roles. Section 8 specifies the Capability Provider contract. Sections 9 and 10 specify the Audit Envelope and Cost Record in detail. Section 11 specifies the Compliance Profile mechanism. Section 12 specifies the Evaluation and Recalibration mechanism by which Workers and Roles are managed over time. Section 13 specifies conformance. Sections 14 through 16 cover security, privacy, and versioning. Section 17 contains non-normative notes on wire bindings.

Appendix A contains a worked example illustrating the model end-to-end. Appendix B addresses where the substantive depth of a Role lives, since it is distributed across multiple surfaces rather than carried inline in the Role declaration. Appendix C is a glossary. Appendix D records open design questions to be resolved in subsequent drafts.