An Architecture for Non-Human Entities (NHE): A Reference Model for Persistent, Identity-Bearing Autonomous Agents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 12 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Software agents built on large language models increasingly run not as single stateless calls but as long-lived processes: they accumulate memory, carry an identity across restarts and across hosts, cooperate with other agents, take actions under delegated authority, and are expected to be auditable after the fact. Systems of this kind are being built repeatedly and independently, each reinventing the same handful of interfaces --- how an agent proves who it is, how it moves its accumulated context to another host, how two agents exchange work, how its reasoning is made verifiable, and how its authority is bounded and revoked.¶

This document gives those recurring interfaces a common reference model. It names the components of a persistent autonomous agent --- here called a Non-Human Entity (NHE) --- and the interfaces between them, and it identifies which of those interfaces are interoperability surfaces suitable for independent standardization. The term NHE originates in the Synthetic Human Intellect (SHI) framework; this document uses it strictly in the functional sense defined in Section 2.¶

This is an informational architecture document. It defines no wire format itself. Its purpose is to make the companion protocol documents coherent with one another and to let readers understand where each fits.¶

2. What an NHE Is, and Is Not

An NHE is a software system. This document specifies it as a functional artifact: a bounded process with defined inputs, outputs, and persistent state, running on hosts under the control of an operator.¶

Nothing in this document asserts, requires, or implies that an NHE is alive, sentient, conscious, or a moral or legal person. Such claims are not engineering-specifiable, are out of scope, and MUST NOT be inferred from any mechanism described here. The properties an NHE exhibits --- a persistent identity, continuity of memory, autonomous initiation of action --- are functional properties of the specification, not attributes of a living being. They are defined operationally: an identity is a verifiable key commitment (Section 4.1); continuity is the transfer of a hash-committed state (Section 4.2); autonomy is action taken within an explicitly bounded grant of authority (Section 4.6).¶

Three invariants follow from treating the NHE as a functional artifact, and every companion specification in this suite is expected to preserve them:¶

• Operator control. An NHE MUST be suspendable and terminable by its operator at any time. Continuity of identity or memory MUST NOT be specified in a way that prevents suspension, revocation, or termination.¶
• Inspectability. An NHE's state, reasoning record, and actions MUST be exposable in a verifiable form to an authorized party (Section 4.5). No component may rely on being unobservable for its correctness or security.¶
• Bounded authority. An NHE acts only within an explicit, revocable grant of authority. Authority is conferred, scoped, and withdrawn by parties external to the NHE (Section 4.6).¶

These invariants are what keep the architecture an engineering specification rather than a claim about the moral status of the systems it describes.¶

3. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Non-Human Entity (NHE):

A persistent, identity-bearing autonomous software agent as specified by this reference model; a functional artifact per Section 2.¶

Operator:

The party that deploys, hosts, bounds the authority of, and may suspend or terminate an NHE.¶

Host:

A computing environment in which an NHE instance executes. An NHE may migrate between hosts while preserving identity and continuity.¶

Continuity:

The property that an NHE's persistent state can be transferred to another instance or host such that the receiving instance can verify it is the same accumulated state.¶

Peer NHE:

Another NHE with which a given NHE exchanges messages or work over the mesh interface (Section 4.4).¶

Authority grant:

An explicit, scoped, revocable conferral of permission to take a class of actions.¶

4. Reference Architecture

An NHE is decomposed into seven components. The division is by interface, not by implementation: a single process may realize several components, and a component may be distributed, but the interfaces between components are where interoperability is defined.¶

        +-----------------------------------------------------------+
        |                        N H E                              |
        |                                                           |
        |  +-------------+   +--------------+   +----------------+   |
        |  | Identity    |   | Continuity   |   | Memory         |   |
        |  | (who it is) |   | (state xfer) |   | (what it knows)|   |
        |  +------+------+   +------+-------+   +-------+--------+   |
        |         |                 |                  |            |
        |  +------+-----------------+------------------+--------+   |
        |  |            Reasoning & Audit (verifiable record)   |   |
        |  +------+---------------------------------------+-----+   |
        |         |                                       |         |
        |  +------+-------+                       +-------+------+  |
        |  | Governance & |                       | Observability|  |
        |  | Authority    |                       | & Control    |  |
        |  +------+-------+                       +-------+------+  |
        +---------|---------------------------------------|--------+
                  | (mesh)                                 | (operator)
             +----v------+                            +----v-----+
             | Peer NHE  |                            | Operator |
             +-----------+                            +----------+

5. Trust Model

The reference model assumes the following trust relationships:¶

• An NHE trusts its operator to bound its authority and to suspend or terminate it. The operator is the root of control, not the NHE.¶
• A relying party does not trust an NHE's self-assertions; it verifies them --- identity via the Identity interface, state coherence via the Continuity interface, reasoning via the Audit interface.¶
• Peer NHEs are mutually distrusting by default and authenticate each other through the Identity interface before exchanging work over the Mesh interface.¶
• No component depends on being unobservable. Confidentiality, where required, is provided by the transport or an explicit encryption layer, not by obscurity of the mechanism.¶

Each companion protocol document specifies its own security considerations in full; this section states only the model they share.¶

6. The NHE Protocol Suite

The interfaces identified above map to a suite of companion documents. This architecture document is the reference model; each interoperability surface is (or is a candidate to become) a separate specification, so that each can be implemented, reviewed, and adopted on its own merits. The dependency order is roughly: Identity and Continuity first (everything is scoped to identity, and continuity is already specified), then Mesh, Audit, Memory, and Governance.¶

Publishing the reference model separately from the protocols is deliberate: it lets the architecture stabilize the vocabulary and the trust relationships while each protocol proceeds at its own pace, and it avoids binding adopters of one interface to the whole suite.¶

7. Relationship to Existing Work

The NHE model reuses, and does not replace, existing building blocks. The Identity interface is complementary to remote attestation [RFC9334] and to verifiable-credential and decentralized- identifier work; the Audit interface is analogous in structure to transparency logs [RFC9162]; the Continuity and Mesh interfaces are expected to run over standard secure transports such as TLS [RFC8446] or QUIC [RFC9000]. This document's contribution is the reference model that relates these to one another in the specific setting of a persistent autonomous agent, together with the functional-artifact framing of Section 2. Given its research-adjacent character, the architecture may be an appropriate topic for an IRTF Research Group, while the individual protocol documents target the IETF Standards Track.¶

8. IANA Considerations

This document has no IANA actions. The companion protocol documents define their own registries. A future revision may request an umbrella registry group under which those registries are organized.¶

9. Security Considerations

This document defines an architecture, not a protocol, and introduces no wire mechanism of its own; the detailed security analysis lives in each companion document. At the architectural level the following hold. Identity is the root of all scoping; a compromise of the Identity interface compromises the guarantees of every other interface, so identity key management is the highest-value target and MUST receive the strongest protection. Continuity, Mesh, and Audit convey potentially sensitive state, reasoning, and inter-entity traffic; each relies on an underlying transport for confidentiality and peer authentication and provides integrity and tamper-evidence rather than a secure channel of its own. The functional- artifact invariants of Section 2 --- operator control, inspectability, and bounded authority --- are themselves security properties: an implementation that cannot suspend, inspect, or bound an NHE is non-conformant, and the loss of any of these is a security failure, not merely an operational one.¶

Acknowledgments

The NHE reference model consolidates interfaces from an existing body of implementation and design work in the Synthetic Human Intellect (SHI) framework.¶

Author's Address