Summary

  • An individual IETF draft says an agent's recommendation becomes an organizational decision only through an explicit adoption rule and an authorized subject. A valid credential can carry the suggestion onward; it cannot cast the missing vote.
  • The draft also separates a real action from a tool call and an observed outcome from the action. It asks each handoff to preserve bounded authority, material context, a decision reference, evidence kind and an accountable owner.

The Suggestion Arrived Wearing a Decision's Coat

Picture an agent recommending a supplier change. A second agent copies the recommendation into a work queue; a tool accepts the request; a dashboard reports success. By lunchtime the organization has a neat story: the recommendation was approved, the switch was made, the savings appeared. The neatness is the warning. Which authorized person or rule adopted the suggestion as the company's decision? What system changed the supplier? What record shows that the business result occurred? A new individual Internet-Draft on agent handoffs insists these are four different questions.

The supplier story is a hypothetical way to read the draft's requirements. It is not a documented deployment. The IETF Datatracker lists revision 00, dated 19 October 2026, as an active individual draft with no IETF endorsement or RFC stream. Its author proposes organizational semantics for delegation, rather than a wire format or a new credential. The title sounds abstract; the failure mode is painfully familiar. A machine's confident recommendation acquires the clothes of a corporate decision while it travels through systems that can authenticate each other but cannot say who committed the organization.

The draft's first distinction is between infrastructure permission and organizational authority. A token can establish that a caller may invoke an API. Authority is a bounded right to decide or act for a particular purpose, with exclusions and a responsible principal. A delegation must carry only a subset of the delegator's authority, and it must identify the delegator, purpose and limits. Handing an agent a usable tool should never silently expand its mandate. A receptionist can have the key to the boardroom without a board vote; software credentials deserve the same common sense.

The second distinction is the moment of adoption. A recommendation proposes a course of action. A decision is an organizational commitment made under a rule by an authorized subject. For an action taken on the organization's behalf, the draft asks for a reference to that decision or an explicit rule saying no separate decision was required. A recommendation alone cannot fill the reference. That requirement puts a name and a rule at the place where many agent pipelines put a green check mark.

The Tool Said “Done.” What Actually Happened?

The document continues the chain past the decision. A tool invocation is a request to machinery; an action is an intervention that actually occurred. Even an unauthorized intervention must be recorded as an action. Its occurrence and its legitimacy are separate facts. An outcome is a later change in the world, which needs its own observation. A successful API response cannot prove the business outcome, and the agent's polished account of its work cannot by itself prove that it acted. The draft asks records of action to support later linkage to outcomes while leaving the two records distinct.

Its evidence rule has three bins at minimum: the agent's self-report, the platform or runtime record, and externally verifiable material. The bins matter because an eloquent self-report and a tool log do different work. One may tell investigators what the agent thought it did; another may prove what the service accepted; an independent record may show what changed outside the agent's own narrative. In a high-risk setting, the draft says self-report is insufficient proof of action.

Handoffs create a third vulnerability: context falls off the parcel. The first agent may know that a recommendation concerns only one supplier, one region or one approved period. The next receives a bare instruction and a valid token. The draft calls context material when its loss changes interpretation, authorization or risk; that context must survive the handoff. Trust and confidence cannot simply be inherited from the sending agent. The receiving side must justify reliance in its own setting. Passing a token along is easy. Passing the reason for the limit is governance.

Finally, new evidence must not edit the past. If a later system proves the supplier change failed, the record of what the organization knew when it decided must remain intact. Learning should change the next decision, not rewrite the previous one into an omniscient account. The draft distinguishes design conformance from operational conformance: a diagram of these distinctions is weaker evidence than real system records showing they survived actual handoffs. It reports requirements, not an audited deployment.

Original records