The Agintent protocol: one durable object for agent work

Current AI agent stacks are fragmented. Prompts are not portable. Workflow tools are isolated. Agents do not share one execution object. Artifacts and memory are trapped inside individual apps, and human review is bolted on rather than native. The Agintent protocol exists to define one shared object that survives the entire chain, so the ecosystem does not harden around weaker defaults.

The reference orchestrator is the first working implementation that proves the model on real execution constraints. It is not a claim that a full ecosystem already exists — it is the honest, useful stage at which to get the object model right.

The envelope is the durable transport wrapper. It carries the protocol version, object identity, the source actor and origin metadata, routing and execution hints, lifecycle status, the intent payload, and references to artifacts and memory. Everything else — which executor ran the work, which model was used, where a file landed — is an implementation detail attached to the envelope, never a replacement for it.

Inside the envelope, the intent object is the canonical requested-work unit. It answers a small, strict set of questions: what is being asked, for whom, under what constraints, with what priority, and with what expected outputs. A prompt captures a moment of instruction; an intent object is portable across tools and time.

The run contract is the execution agreement that binds an accepted envelope to a concrete run. It records who accepted the work, which capability is handling it, which state transitions are valid, and how logs and artifacts attach. Lifecycle states are deliberately small and explicit: queued, running, waiting for input, completed, failed, and cancelled. A run paused for human review is in a defined waiting state with a reason — not a fuzzy limbo.

Work routes to a declared capability, not a single named worker. Capabilities include research, workflow webhook dispatch, manual approval, browser automation, CRM mutation, data extraction, content creation, and task decomposition. Any executor that declares a capability can accept matching work, and unsupported intents fail clearly instead of silently stalling.

Outputs — structured data, files, links, summaries, prompts, screenshots, reports — remain attached to the originating envelope as typed artifacts. The artifact contract is defined at the protocol level, so storage backends can change (local filesystem today, object storage later) without changing the contract or losing the link between an output and the work that produced it.

The reference runtime still uses task-shaped internals and a compatibility /api/tasks API. That is a deliberate tradeoff: the storage shape can lag the protocol vocabulary, but the external language must not. A runtime task maps to an intent object inside an envelope; a task run maps to a run under the run contract. Protocol-native routes such as /api/protocol/envelopes expose the protocol surface on top of the same runtime.