AI Lab Blog

Hermes and the Message Bus Problem in Agentic AI

June 27, 2026

Tags: Agentic AI, Hermes, Architecture

Agentic AI is usually discussed as if the agent is the main character. But in real systems, the messages matter just as much as the agent.

A useful agent does not operate in a vacuum. It receives goals, reads evidence, calls tools, asks other agents for help, passes intermediate findings, waits for approvals, and emits final artifacts. Every one of those steps is a message. If the messages are ambiguous, unauthenticated, lossy, or invisible, the agent system becomes difficult to trust.

That is why Hermes is a useful pattern for agentic AI. Whether Hermes is implemented as a specific component, a service, or simply an architectural discipline, the idea is the same: treat communication between agents, tools, policies, and humans as first-class infrastructure.

The messenger layer is not plumbing. It is where trust is carried.

The problem with conversational glue

Many early agent systems are stitched together with conversational context. Agent A writes a summary. Agent B reads it. A tool returns a blob. Another agent interprets the blob. The final answer appears in a chat window.

That can work for prototypes. It does not scale well to security operations.

Conversational glue has several weaknesses. It often lacks strong schemas. It may blur source evidence with model interpretation. It may not preserve timestamps or tool versions. It can make it hard to tell which agent said what, based on which evidence, under which policy. It can also allow irrelevant or hostile text to influence later steps.

Security workflows need messages that are structured enough to be inspected by machines and humans.

A good message should answer:

• who or what produced it;
• when it was produced;
• what evidence it references;
• what confidence it claims;
• what policy context applied;
• whether it is a fact, assessment, request, command, or draft;
• what downstream actions it authorizes, if any.

Without that metadata, agent chains become polished rumors.

Message types should be explicit

Hermes-style architecture begins by naming the message types. A SOC agent system might use types like:

evidence.observed
entity.extracted
assessment.proposed
tool.call.requested
tool.call.completed
approval.requested
approval.granted
containment.recommended
brief.drafted
case.updated

The names are not cosmetic. They prevent category mistakes. An assessment.proposed message should not be treated as confirmed evidence. A brief.drafted message should not authorize a firewall rule. An approval.requested message is not the same as approval.granted.

Once message types are explicit, policy becomes easier. The system can require that high-risk tool calls only occur after an approval message. It can require that executive briefs include evidence references. It can prevent one agent’s low-confidence assessment from becoming another agent’s high-confidence fact.

Provenance travels with the message

In threat intelligence and incident response, provenance is not optional. If an agent says a host is suspicious, the team needs to know why. Was the claim based on an EDR alert, DNS log, authentication event, vulnerability scan, analyst note, or another model’s summary?

Hermes-style messages should carry evidence references. Not full raw data every time, but stable pointers to source records. A message might reference alert IDs, log query IDs, ticket IDs, advisory URLs, file hashes, timestamps, or immutable evidence bundle IDs.

This matters during review. If a recommendation was wrong, the team can inspect whether the evidence was wrong, the interpretation was wrong, or the downstream agent lost context. If a brief goes to leadership, the team can trace each claim back to its source.

The more autonomous the system becomes, the more provenance matters.

Policy checks belong in the route

A message bus is also a policy enforcement point. When an agent asks to call a tool, that request should pass through a route that can check whether the action is allowed.

For example:

Agent requests: revoke sessions for user m.rivera
Route checks:
- Is the requesting agent allowed to request session revocation?
- Is there an active incident ID?
- Is the target a single user, not a wildcard?
- Is there an approval.granted message from an authorized human?
- Is the approval fresh enough?
- Is the action logged with rationale?

If the answer is no, the bus should deny the route. The model can be told why, but the model should not be the final enforcement layer.

This design is boring in the best way. It turns policy into infrastructure.

Agents should not share one giant memory

A common shortcut is to let every agent read the same large context. That feels convenient, but it creates risk. Sensitive information spreads too widely. Irrelevant text pollutes reasoning. Attacker-controlled content may persist longer than needed. The system becomes hard to debug.

Hermes-style design encourages scoped messages. Each agent receives the information needed for its role, plus references it can request if policy allows. A summarizer may need sanitized evidence and source links. A containment recommender may need asset criticality and response playbooks. A stakeholder brief writer may need the approved assessment, not raw logs containing sensitive details.

Less context can mean better control.

Failure handling is a message design problem

Agent systems fail in strange ways. A tool times out. A model refuses incorrectly. A retrieval step returns stale data. A downstream agent receives contradictory findings. A human approval is delayed. A policy check denies a route.

These should not disappear into logs only engineers read. They should become structured messages.

A failed enrichment should produce tool.call.failed with reason and retry state. Conflicting evidence should produce assessment.conflict_detected. A missing approval should produce approval.required. A denied action should produce policy.denied.

When failures are typed, the workflow can respond safely. It can retry low-risk enrichment, pause high-risk action, ask for analyst review, or degrade to a simpler output.

The audit trail is the product

For security teams, the audit trail is not a compliance afterthought. It is part of the value of the system.

A mature Hermes implementation should let an analyst reconstruct the story:

1. The alert arrived.
2. An evidence agent extracted entities.
3. An enrichment tool added reputation and asset context.
4. A triage agent proposed an assessment with medium confidence.
5. A policy check required human approval before containment.
6. The SOC lead approved session revocation.
7. The tool executed and returned success.
8. A brief agent drafted the stakeholder update using the approved assessment.

That story should be visible without reading every token of every prompt. It should be built from structured messages.

The bottom line

Agentic AI needs good models, but it also needs good messengers.

Hermes is compelling as a pattern because it shifts attention from the agent’s personality to the system’s communication discipline. Serious agent systems need typed messages, provenance, scoped context, policy routes, failure signals, and audit trails.

If the SOC cannot trace how an agent reached a decision, it cannot trust the decision. If approvals are just text in a chat, they are not approvals. If evidence becomes detached from its source, the output becomes opinion.

The future agent stack will not be one brilliant model acting alone. It will be a network of agents, tools, policies, and humans passing structured messages through governed routes. The messenger layer is where that network becomes trustworthy.