By NHI Mgmt Group Editorial TeamBased on Arize: “How Hermes implements an open source agent harness architecture” (June 1, 2026)

TL;DR: Hermes shows how an open agent harness can move beyond a simple model loop by treating sessions as infrastructure, separating tool registration from tool exposure, and preserving lineage during compression, according to Arize. The architectural lesson is that durable agent systems need explicit runtime boundaries, not just better prompts or larger context windows.


At a glance

What this is: Arize's analysis of Hermes argues that an open agent harness can support long-running agents by treating sessions, tools, and compression as explicit runtime infrastructure.

Why it matters: This matters because agentic AI governance depends on controlling runtime boundaries, delegated capability scope, and state lineage, not only on model prompts or isolated tool calls.


Context

Hermes is best understood as an agent harness architecture, not just a coding assistant wrapper. In practical terms, that means the system has to manage session state, tool exposure, delegation, and recovery as part of the runtime itself. For teams building agentic AI, the governance question is whether the control plane can still explain what the agent saw, used, and carried forward after many turns.

The deeper issue is that long-running agents behave more like persistent software services than one-shot prompts. Once sessions compress, delegate work, and route through multiple interfaces, teams need lineage, scoping, and policy enforcement that survive across the whole lifecycle. That is a genuine identity and authorization problem for AI systems, because the agent’s effective privileges and context boundaries become operational assets rather than implementation details.


Key questions

Q: How should teams govern agent sessions that retain context across requests?

A: Treat retained context as part of the control surface, not just application state. If an agent can use prior session history to influence future tool calls or decisions, then access, logging, retention, and revocation need to follow the session, not just the request.

Q: Why do agent harnesses need tool exposure controls instead of just tool registration?

A: Because registered capability is not the same as active authority. A safe harness limits what the model can actually see and invoke in a specific run, which reduces accidental overreach, narrows blast radius, and keeps delegated workflows from inheriting unnecessary power.

Q: What breaks when delegated agent runs do not have durable lifecycle ownership?

A: Delegated work becomes hard to contain, clean up, and audit once the parent call ends. That creates weak ownership semantics for child runs, which makes it difficult to prove what the subagent did, when it stopped, and what context it carried forward.

Q: What is the difference between session state and prompt context in agent systems?

A: Prompt context is the text the model sees on a turn, while session state is the persisted runtime record that carries lineage, metadata, and recovery information across turns. Strong harnesses manage both, because the model’s immediate context is only one part of the system’s operational memory.


Technical breakdown

Agent harness loops and provider abstraction

Hermes keeps the familiar model call, tool dispatch, result append, repeat pattern, but normalises multiple provider APIs behind transport adapters. That matters because the harness, not the model, becomes the place where execution behaviour is made consistent across chat-completions style APIs, Messages-style APIs, and hosted runtime paths. The technical value is less about model choice and more about the control boundary that mediates model requests, tool invocation, and response handling. In a long-lived system, that boundary is where observability, policy, and replayability begin.

Practical implication: Treat the harness as the enforcement point for runtime policy, not as a thin wrapper around model calls.

Context compression with lineage preservation

Hermes does not simply trim old context. It summarises older turns, prunes aged tool outputs, and then closes the current session row before creating a child session seeded by the summary. That creates lineage rather than rewriting a single transcript in place. From a governance perspective, that is important because the system preserves a chain of state transitions that can be inspected after the fact. Compression therefore becomes a lifecycle event, not just a token optimisation, and it changes how teams should think about auditability, recovery, and trust in retained context.

Practical implication: Preserve parent-child session lineage whenever context is compressed so the agent’s state history remains explainable.

Tool exposure and delegated runtime scope

Hermes separates tool registration from tool exposure. Tools can exist in a central registry, but the model only sees a scenario-specific exposed subset, and delegated runs can be narrowed again. That distinction is central to agentic security because registered capability is not the same as usable capability. A long-lived agent with broad installed tools still needs a constrained model-visible surface in each run, especially when delegation or unattended execution is involved. This is the difference between having a capability library and granting an active operating envelope.

Practical implication: Scope the model-visible tool set per run and per profile so registered tools do not become accidental runtime authority.


NHI Mgmt Group analysis

Runtime boundary design is now the core security problem for agentic systems. Hermes shows that durable agents are governed less by the model itself and more by how sessions, tools, and context are bounded. The important shift is from prompt engineering to runtime architecture, because persistent agents create state that must be controlled across many turns. Practitioners should therefore treat boundary design as the primary governance object for agentic AI.

Lineage-preserving compression is a stronger governance pattern than transcript rewriting. When a system closes one session and seeds a child session from a summary, it preserves a recoverable chain of custody for context. That matters for auditability, incident review, and policy enforcement because compressed state is still part of the decision path. The named concept here is context lineage control: the ability to retain traceable state transitions as an agent compresses, delegates, and resumes. Teams should use this as the design target for long-running agent systems.

Tool registration without tool exposure is an identity control, not a convenience feature. Hermes demonstrates that capability inventory and active authority are different things, and that distinction mirrors good authorization practice. For agentic AI, the relevant governance question is who or what can actually exercise a tool at runtime, not what is merely installed. Practitioners should therefore review exposed tool surfaces the same way they review high-risk entitlements in human IAM or NHI programs.

Delegation remains the weakest point in many agent harnesses. Hermes already has useful child-run mechanics, but durable and externally steerable child control is still emerging. That gap matters because delegated work is where responsibility, cleanup, and containment become hardest to enforce. The lesson for the field is that orchestration maturity will hinge on whether child runs become first-class control-plane objects rather than ephemeral byproducts.

Open harnesses are converging on operational governance, not just model orchestration. The most useful systems now embed hooks, session routing, prompt assembly, and policy surfaces directly into the runtime. That makes them closer to managed execution environments than to simple application wrappers. The practitioner implication is clear: the security model must follow the harness architecture, not sit beside it as an afterthought.

From our research library:

What this signals

Context lineage control: long-running agent systems need state that can be traced across compression, delegation, and resume events. When the runtime rewrites history instead of preserving lineage, auditability and incident reconstruction both degrade. Teams should design for recoverable session ancestry before they scale agent workloads.

Open agent harnesses are moving the governance burden from prompt tuning into runtime design. That changes the operating model for AI security teams because control surfaces now include session storage, tool scoping, gateway hooks, and delegated execution paths. The practical signal is to review agent platforms the way you review privileged systems, with explicit authority boundaries and observable state transitions.


For practitioners

  • Define session lineage requirements Require every compressed agent session to retain parent-child lineage, summary provenance, and recovery metadata so audit teams can reconstruct the decision path.
  • Limit tool exposure per run Expose only the tools needed for the current task, even if many more are registered in the harness, and narrow delegated runs further.
  • Separate registration from authority Maintain a central inventory of available tools, but govern the runtime-visible set as the actual control boundary for each profile and scenario.
  • Treat compression as a control event Trigger review, policy checks, and session metadata updates when context is summarised so compressed state does not silently change the effective agent record.
  • Plan for durable child-run governance Design explicit lifecycle, cleanup, and ownership semantics for delegated child runs before they become operationally persistent.

Key takeaways

  • Hermes illustrates that long-lived agent systems fail or succeed on runtime boundaries, not on prompt quality alone.
  • The architecture keeps lineage visible through compression and narrows tool authority by separating registration from exposure.
  • Teams building agentic AI should govern session state, delegated scope, and recovery semantics as first-class security controls.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseHermes separates exposed authority from registered tools, which directly maps to agent privilege abuse risk.
ASI08 — Cascading FailuresCompression, delegation, and session persistence can amplify failures across long-lived agent workflows.
Recommendation — Constrain the model-visible tool set and review any path that expands runtime authority beyond task scope. Design containment boundaries so one agent failure cannot cascade across child runs or compressed sessions.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is fundamentally about governance of persistent AI runtime behaviour and accountability for state.
Recommendation — Define ownership, policy, and audit expectations for persistent agent sessions and delegated execution.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementOver-broad tool exposure in long-lived agents can enable credential misuse and movement across tasks.
Recommendation — Map agent tool exposure to ATT&CK-style abuse paths and narrow authority before deployment.

Key terms

  • Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
  • Case Lineage: The preserved record of how an incident or alert evolved over time, including comments, attachments, approvals, and changes in status. Case lineage matters because it lets teams investigate, tune detection, and prove accountability long after the original event has closed.
  • Tool Exposure: Tool exposure is the subset of available capabilities that a model can actually see and invoke during a specific run. It is a security boundary, not just an engineering convenience, because limiting exposure reduces misuse and shrinks the effective attack surface.
  • Delegated Run: A delegated run is a subtask executed by an agent on behalf of a parent workflow, usually with its own task context and output summary. The security issue is not delegation itself, but whether its lifecycle, scope, and cleanup are controlled.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security leaders and architects translate identity governance into controls that work in real runtime systems.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org