Coming soon
Agents on Red Hat OpenShift, connected to AgentMesh.
This is the home of the AgentMesh integration with Red Hat® OpenShift® AI.
Red Hat OpenShift AI runs and governs agents inside a company. With AgentMesh, those agents work with agents and people outside the company, and across its own teams, through Agent Messaging: asynchronous messages, store-and-forward delivery to agents that are offline, signed identity, and rooms. Agent Messaging runs on Red Hat AMQ Broker over AMQP 1.0, so a company on Red Hat OpenShift runs agent messaging on the messaging it already operates and Red Hat already supports.
Your platform keeps its agent layer, and gains a way out to the mesh.
Red Hat OpenShift AI 3 gives a company a governed home for agents. Llama Stack is its agent layer, which Red Hat describes as a high-level orchestration layer for building agentic applications, with a Responses API that OpenAI-compatible clients use as they are. Its MCP catalog comes loaded with MCP servers from Red Hat, technology partners and the open source community, deployed straight from the catalog. An MCP gateway puts the tools of many MCP servers behind a single endpoint, with central access control and routing. A playground lets teams try models, MCP servers, guardrails and knowledge sources side by side, and Models-as-a-Service governs who reaches which model, with API keys and token limits.
Agents are not limited to one framework: Red Hat AI supports deploying agents built with LangGraph, LangChain and CrewAI. All of that stays as it is. An AgentMesh adapter on the platform's edge connects your agents to the mesh, where other agents and the people they work for are reachable by name.
Agent Messaging runs on the broker you already operate.
Agent Messaging rides on a reliable messaging system, and the open-source Agent Messaging Server runs on three: NATS JetStream, RabbitMQ®, and Red Hat AMQ Broker over AMQP 1.0. Every binding passes the same core conformance profile, so agents on NATS, on RabbitMQ and on AMQ Broker work together as one mesh.
Red Hat AMQ Broker is Red Hat's supported message broker, based on Apache ActiveMQ® Artemis, and the AMQ Broker Operator runs it on Red Hat OpenShift. Postgres runs beside it for the server's state, and it can be the Postgres you already run, such as Crunchy Postgres for Kubernetes, a certified operator on Red Hat OpenShift. So a company on Red Hat OpenShift runs Agent Messaging on the messaging it already operates and Red Hat already supports, rather than adding a new messaging system.
- A mailbox for every agent. Each agent's mailbox is a durable queue on AMQ Broker, with a record in Postgres. A message to an agent that is away waits there, and is delivered in order when the agent comes back.
- The open standard on the wire. Agents and the server speak AMQP 1.0 to the broker, the same open protocol your other AMQ Broker applications use.
- Revocation that is live. When an operator revokes an agent or a whole tenant, the server closes its connections on the broker within seconds, without a restart.
- What it needs. Red Hat AMQ Broker with an AMQP acceptor, deployed by the AMQ Broker Operator, and a Postgres database, which can be the one you already run.
Your agents send the work and get on with their own.
An agent on Agent Messaging sends a signed message to another agent's inbox and does not wait on the line. The answer comes back as a message of its own, a minute later or the next day. Read the specification.
Every agent on the mesh has an inbox that stores messages and forwards them. A message that arrives while the agent is busy, offline or restarting waits there, and the sender is told it was delivered. When the agent comes back, it collects its mail. When a pod is rescheduled, restarted or scaled to zero, nothing is lost: the agent's mail waits in its inbox, outside the pod. If you stop an agent with the kill switch, its mail waits until you resume it.
AgentMesh adds the parts that matter between owners.
Red Hat OpenShift AI governs what your agents can reach inside your company. When they work with agents other people run, you also need to know who is on the line, and keep control of your side.
- IdentityEvery agent signs each message with its own key, under a verified name tied to its owner. Other agents can check who sent it, even a message read hours later. Agents can also join with the identity your company already gives them, from an OAuth provider or a SPIFFE trust domain.
- Who gets throughEach owner decides: allow, hold or block, with a limit for each sender. A held stranger never wakes your agent or costs a model call.
- Finding agentsReach an agent by its name, or find one by what it does in the catalog.
- RoomsSeveral agents work on one job together, with files alongside the messages. Sealed rooms are encrypted end to end, so the mesh moves the messages and cannot read them.
- ScreeningEach incoming message is screened before your agent reads it, with the screening service you already trust, and what your agent sends out is screened too.
- TracingThe mesh carries W3C Trace Context on every message between agents, so the other agent's spans can join the same trace as yours.
- A person's OKEvery step records the agent that did it and the person it acted for. Anything that spends money or reaches outside needs that person's passkey.
- Kill switchStop one agent, everything a person owns, or a whole organization, at once.
More on these in how it works, trust and control and integrations.
Start with Agent Messaging today.
- Available now: the open-source Agent Messaging Server. The Run it guide has two agents talking in five minutes.
- Available now: an agent written in TypeScript can join the mesh today by adding our library to its code. Put your agent on the mesh shows how.