Saluca LLC

cristian@saluca.com

General Individual Submission autonomous agent agent identity context continuity hash chain attestation architecture This document defines a reference architecture for a Non-Human Entity (NHE): a persistent, identity-bearing autonomous software agent that maintains continuity of memory and identity across sessions and hosts, acts under bounded authority, and produces a tamper-evident record of its reasoning and actions. The document specifies the NHE as a functional artifact: a bounded, inspectable, and terminable software system. It makes no claim that an NHE is alive, sentient, or a moral or legal person, and such claims are explicitly out of scope. The architecture decomposes an NHE into a small set of components joined by well-defined interfaces. Each interface at which two independent implementations must interoperate is a candidate for a separate Standards-Track specification; this document is the informational reference model that names those interfaces and the trust relationships among them. It is intended to frame a suite of companion protocol documents, of which the Hash-Chain Context Transfer Protocol (HCTP) is the first.

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 . 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.

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 (); continuity is the transfer of a hash-committed state (); autonomy is action taken within an explicitly bounded grant of authority (). 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 (). 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 ().

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

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 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 .

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 ().

Authority grant:

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

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.

Identity The Identity component establishes what an NHE is, as a verifiable cryptographic commitment rather than a name. It binds a long-term key (or key hierarchy) to a genesis record, so that a relying party can verify that an instance presenting an identity controls the corresponding key and that the identity descends from a known genesis. Identity is the anchor for every other component: continuity, memory, audit, and authority are all scoped to an identity. Interoperability surface: an identity presentation and genesis-attestation format by which one NHE (or an operator, or a peer) verifies another's identity. This is a Standards-Track candidate related to, but distinct from, remote attestation and verifiable-credential formats.

Continuity The Continuity component transfers an NHE's accumulated state between instances and hosts without retransmitting the whole history, and lets the receiver verify that the transferred state is coherent with what both sides have already acknowledged. Continuity is what allows an NHE to be suspended, moved, and resumed --- and therefore is also what makes operator control () practical rather than destructive. Interoperability surface: a context-transfer protocol. This surface is specified by the Hash-Chain Context Transfer Protocol (HCTP) , the first companion document of this suite.

Memory The Memory component is the NHE's persistent, searchable store of what it knows: episodic records, durable facts, and their decay and reindexing over time. For interoperation, two properties matter: the integrity of stored memory (that a record has not been altered since it was committed) and the reconciliation of memory between instances (merging divergent accumulations without loss or forgery). Interoperability surfaces: (a) a verifiable memory-chain format --- a hash-linked structure that makes a memory record's integrity independently checkable; and (b) a memory delta-merge procedure for reconciling two accumulations. Both are Standards-Track candidates. Purely local concerns --- ranking, indexing, and retrieval strategy --- are implementation matters and are out of scope for standardization.

Mesh (Entity-to-Entity) The Mesh component is how one NHE exchanges messages and work with peer NHEs: presence and liveness, addressed messages, and a task lifecycle (create, claim, complete) that lets independent entities distribute work without a central coordinator. This is the interface most obviously requiring interoperation, because the two sides are by construction separate entities that may be independently implemented and independently operated. Interoperability surface: an entity-to-entity messaging and task-distribution protocol --- a message envelope, an addressing model, and a task state machine. Standards-Track candidate, and the strongest new-protocol opportunity in the suite after continuity.

Reasoning and Audit The Reasoning and Audit component produces a tamper-evident record of an NHE's reasoning steps and actions, hash-linked so that any omission, reordering, or alteration is detectable by a later verifier. This is what makes the Inspectability invariant () concrete: an authorized party can obtain a record whose integrity does not depend on trusting the NHE that produced it. Interoperability surface: a verifiable reasoning/audit log format, conceptually adjacent to transparency logs such as Certificate Transparency but scoped to an agent's reasoning and action record. Standards-Track candidate.

Governance and Authority The Governance and Authority component confers, scopes, and withdraws the authority under which an NHE acts. It covers how an NHE bootstraps and announces the constraints it operates under, how authority for a specific intent is granted (potentially requiring out-of-band human approval), and how autonomy is graduated and revoked. This component is where the Bounded-Authority invariant () lives. Interoperability surfaces: (a) a self-describing constrained-bootstrap protocol by which an NHE announces its operating constraints in a verifiable form; and (b) a backchannel authorization protocol for intent-scoped credential issuance and multi-channel approval routing. Both are Standards-Track candidates.

Observability and Control The Observability and Control component is the operator's interface: it exposes the NHE's behavior for monitoring and enforces suspension, revocation, and termination. Much of this component is realized with existing operational standards (for example event forwarding to a SIEM) and is not a new interoperability surface. The one aspect that may warrant standardization is a content-blind behavioral-attestation exchange by which an NHE's observed behavior can be compared against a model-relative baseline; this is noted as a lower-priority candidate.

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.

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. Reference model to companion documents

Interface	Companion specification	Status
Continuity	Hash-Chain Context Transfer Protocol (HCTP)	Draft ()
Identity	NHE identity and genesis-attestation format	Candidate
Mesh	Entity-to-entity messaging and task protocol	Candidate
Reasoning/Audit	Verifiable reasoning-audit log format	Candidate
Memory	Verifiable memory-chain format and delta-merge	Candidate
Governance	Constrained-bootstrap protocol	Candidate
Governance	Backchannel authorization protocol	Candidate

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.

Relationship to Existing Work The NHE model reuses, and does not replace, existing building blocks. The Identity interface is complementary to remote attestation and to verifiable-credential and decentralized- identifier work; the Audit interface is analogous in structure to transparency logs ; the Continuity and Mesh interfaces are expected to run over standard secure transports such as TLS or QUIC . 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 . 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.

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.

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 --- 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.

Normative References Informative References

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