Does TrueFoundry support MCP and AI agents?
.png)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU â no tuning needed
- Production-ready with full enterprise support
These two projects get compared constantly, and it is a fair fight rather than a marketing one. Both are MIT-licensed, enormously popular, self-hosted, and usable from a chat app on your phone. Hermes even ships a hermes claw migrate command to import an OpenClaw setup, which tells you how directly the maintainers see the overlap (Hermes Agent README, retrieved 21 September 2026).
But they disagree about something real, and the disagreement is in each projectâs own first sentence. OpenClaw is an assistant that âmeets you in the channels you already use.â Hermes is âthe agent that grows with you.â Those are different products that happen to share a category.
This guide compares what each actually ships, then makes the point an enterprise reader needs: the interesting question is not which harness wins, it is what breaks when your whole team is running one.

OpenClaw: Overview
OpenClaw is an open-source AI assistant that runs on your own machine and reaches you through the chat apps you already have. It is written in TypeScript, published on npm as openclaw, and stewarded by the OpenClaw Foundation, an independent 501(c)(3) that employs the core team and signs releases. The project states plainly that it has no paid tier, no hosted service and no token, and that OpenAI is a donor rather than an owner (OpenClaw README, retrieved 21 September 2026).
The repository is licensed MIT and, as of 21 September 2026, shows 390,174 stars and 82,059 forks (GitHub API, observed 21 September 2026). It was created on 24 November 2025, which makes the growth curve unusually steep even by open-source standards.
[SCREENSHOT: OpenClaw â the Control UI with a live conversation, approvals panel and channel list visible]
Architecturally, OpenClaw is a single long-lived Gateway daemon that owns every messaging surface. Control-plane clients â the macOS app, the CLI, the web Control UI, automations â connect to it over WebSocket, by default on 127.0.0.1:18789. Device ânodesâ such as an iPhone or an Android handset connect to the same WebSocket server with role: node, declaring the capabilities they expose (camera, screen recording, location). There is exactly one Gateway per host, and all connections require device pairing and signed challenges (OpenClaw Gateway architecture docs, retrieved 21 September 2026).
The published channel catalogue lists more than thirty surfaces, including Telegram, Slack, Discord, WhatsApp, Signal, iMessage, Microsoft Teams, Google Chat, Matrix, Mattermost, IRC, SMS via Twilio, LINE, Feishu and WeChat (OpenClaw channels docs, retrieved 21 September 2026). Native apps cover macOS, iOS, Android, Windows and Linux.
OpenClaw 2.0 shipped as v2026.8.1, published 31 August 2026 at 03:30 UTC. The release notes put its scale at 16,977 pull requests, 698 direct commits and 987 contributors, touching installation, the rebuilt web Control UI, memory, skills, models, automations, browser and computer use, plugins and security. Notable additions include a Skill Workshop that holds proposals, checks and applied history; memory recall across an agentâs other private conversations; and credentials that can reach supported destinations without entering model-visible text (OpenClaw v2026.8.1 release notes). The project has shipped steadily since â v2026.9.5 landed on 19 September 2026.
Honest trade-offs. The security guide is direct about the default posture: âTools run on the host for the main session unless you configure sandboxing.â Reach is the design goal, and every additional channel is another inbound path that has to be treated as untrusted input. OpenClawâs own team setup guide states the boundary clearly: âA gateway is one trust domain,â and recommends one gateway per tenant if you need to serve mutually untrusted people or organisations (OpenClaw team setup docs, retrieved 21 September 2026).
Hermes Agent: Overview
Hermes Agent is Nous Researchâs open-source, MIT-licensed autonomous agent. It is written in Python, created on 22 July 2025, and as of 21 September 2026 shows 247,589 stars and 52,090 forks (GitHub API, observed 21 September 2026). The most recent release at the time of writing is v2026.9.14, labelled Hermes Agent v0.21.3, published 14 September 2026.
Hermes describes itself as âthe only agent with a built-in learning loop,â and the specifics back that up rather than just asserting it. It creates skills from experience, improves those skills during use, nudges itself to persist knowledge, searches its own past conversations, and builds a model of the user across sessions using Honcho dialectic user modelling. Its skills are compatible with the agentskills.io open standard (Hermes Agent README, retrieved 21 September 2026).
[SCREENSHOT: Hermes Agent â the terminal TUI mid-task, showing streaming tool output and a skill being invoked]
The memory design is deliberately bounded rather than unlimited. Two files carry it: MEMORY.md for the agentâs own notes, capped at 2,200 characters (roughly 800 tokens), and USER.md for the user profile, capped at 1,375 characters (roughly 500 tokens). Both live in ~/.hermes/memories/ and are injected into the system prompt as a frozen snapshot at session start. When a write would exceed the cap, the tool returns an error rather than silently dropping entries, and the agent consolidates before retrying (Hermes persistent memory docs, retrieved 21 September 2026). A background Curator handles usage tracking, staleness and archival for agent-created skills.
On deployment, Hermes offers seven terminal backends â local, Docker, SSH, Singularity, Modal, Daytona and Vercel Sandbox â with Daytona and Modal providing serverless persistence so the environment hibernates when idle. It runs on a $5 VPS or a GPU cluster, and it reaches you through Telegram, Discord, Slack, WhatsApp, Signal, Email and the CLI from one gateway process. Model choice is open: Nous Portal, OpenRouter, OpenAI, Anthropic, Google, or any OpenAI-compatible endpoint, switched with hermes model.
Honest trade-offs. The same docs that describe memory also describe its limit: âMemory is scoped per profile by design,â with an explicit warning not to point two agent processes at the same Hermes home. That is the correct engineering decision for a personal agent and exactly the constraint that bites when a team wants shared institutional knowledge. Hermes does ship serious operational pieces â a Managed Scope for administrator-pinned, user-immutable config and secrets, an egress credential-injection proxy, and Docker network egress isolation â but these are per-install controls, not a multi-user control plane.
Architecture and deployment compared
Read that as two coherent philosophies rather than a scorecard. OpenClaw spent its engineering budget on surfaces and on making one host serve them all safely. Hermes spent its on the loop that turns yesterdayâs work into todayâs capability, and on running it anywhere from a phone to a GPU cluster. OpenClaw 2.0 narrowed the gap on memory and skills; Hermes has narrowed it on channels. The centre of gravity is still different, so pick on which one you actually need.
Where teams hit trouble
The failure modes below are not defects in either project. They are what happens when a tool built for one person is adopted by an organisation.
1. Credentials multiply. Each install holds its own provider keys, its own MCP server tokens, its own OAuth grants. Fifty developers means fifty copies of a Snowflake token on fifty laptops. OpenClaw 2.0âs credential masking keeps secrets out of the modelâs context, and Hermes has Managed Scope and an injection proxy â both genuinely good â but neither gives you one place to rotate a key and have it take effect everywhere.
2. Nobody can answer âwho did what.â Both projects log locally. Neither aggregates. When an agent drops a table or emails the wrong customer, the audit trail is on the machine that did it, in a format nobody else queries. OpenClawâs multi-user mode gives per-session attribution inside one gateway, which is real progress, but it stops at the gateway boundary.
3. Spend is invisible until the invoice. Fifty agents, each choosing its own model, each free to pick the frontier tier for a task that a cheap model would handle. There is no shared budget, no per-team cap, and no way to see which workload is burning the money.
4. Learned knowledge stays trapped. This one is specific to the Hermes design and worth naming plainly. Its skills and memory are scoped per profile by design. When your best engineerâs agent has spent six months learning your deployment runbook, that value is on their machine, not in your organisation. OpenClawâs personal skills on a shared gateway improve on this, but only within one host.
TrueForge: the same ownership, plus the control plane
TrueForge is TrueFoundryâs open-source, vendor-neutral agent harness. It is MIT licensed, documented at trueforge.dev, and runs locally with npx @truefoundry/trueforge or as a team deployment via Docker Compose or Helm.
The point is not âTrueForge instead of OpenClaw or Hermes.â It is that TrueForge assumes more than one person will run it. Instead of tying the runtime to a model provider, it handles the agent loop, tool execution, context management, approvals and sandboxing while you bring your own models, MCP servers and infrastructure. Centralised MCP access and credentials, human-in-the-loop approvals, observability and governance come with it rather than being left as an exercise.

Because the runtime is separated from the model layer, teams can switch models or route workloads to different providers without rebuilding the agent. Sessions are visible across the team rather than sitting in one personâs local store.


In TrueFoundryâs benchmark against Claude Managed Agents, TrueForge reached roughly the same task accuracy â about 11 out of 14 â while using far fewer tokens on the same model. On Opus 4.8 that made it roughly 30% cheaper per run. Running the same benchmark with GLM-5.2 held the same score at about $2.90 per run against $11.80, roughly 75% lower cost.
The second cost lever sits in the AI Gateway. Auto Routing classifies requests by complexity and sends them to the right model tier instead of defaulting to the frontier model. Across 550 prompts, routing between Haiku, Sonnet and Opus cut cost by 69% while retaining 98% of baseline quality, and mean latency fell from 7.6 seconds to 4.0 seconds. On production-shaped traffic the reduction reached 80%.
The gateway itself adds roughly 3-4 ms of latency, handles 350+ RPS on 1 vCPU, and fronts 1,000+ LLMs behind one OpenAI-compatible API â which is what makes it practical to put in front of every agent rather than only the important ones.


Head-to-head comparison
Related reading
- What Is an Agent Harness? â the layer underneath both projects
- Agent Harness vs Agent Framework: Whatâs Actually Different
- Best Open Source Agent Harness
- What Is an AI Control Plane?
- AI Agent Observability Tools
Conclusion
OpenClaw and Hermes Agent are both very good at different things. OpenClaw decided an agent you cannot reach is useless, and built the most comprehensive set of surfaces in open source. Hermes decided an agent that forgets everything is a toy, and built a learning loop that makes it more useful in month six than in week one. If you are one developer choosing a harness, pick the philosophy that matches your actual problem, and know you can migrate later â Hermes ships the import command for exactly that.
What neither set out to answer is what happens at scale. Both are explicit in their own docs: one gateway is one trust domain; memory is scoped per profile. Those are honest design statements, not gaps to be embarrassed about. But an organisation with fifty agents needs one place to rotate a credential, one audit trail, one budget, and one view of which model is being asked to do what. That is a control-plane problem, and it does not go away by picking the better harness.
If you want to keep the open-source ownership and add that layer, TrueForge and the AI Gateway are built for it.
TrueFoundry AI Gateway delivers ~3â4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


Recent Blogs
Frequently asked questions
OpenClaw vs Hermes: which should I pick?
Pick OpenClaw if the value is reach â you want one assistant answering on Telegram, Slack, WhatsApp and your phone, with native apps and thirty-plus channels. Pick Hermes if the value is accumulation â you want an agent that writes its own skills, keeps curated memory, and can run serverless on Modal or Daytona so it costs almost nothing idle. Both are MIT licensed and self-hosted, so the decision is about fit, not lock-in.
Which has more momentum, OpenClaw or Hermes Agent?
By raw GitHub signal, OpenClaw is larger: 390,174 stars against 247,589 as of 21 September 2026. Both are in the top tier of open-source AI projects and both ship weekly. Star counts measure attention, not suitability, so treat them as context rather than a verdict.
Are there good OpenClaw alternatives if I need team governance?
Yes, but understand what you are swapping. OpenClawâs team setup is deliberately one trust domain per gateway, and it says so. If you need mutually untrusted users, per-team budgets, centralised credential rotation or a single audit trail, you want an agent control plane alongside or instead of the harness â that is what TrueForge and the AI Gateway provide.
Is Hermes Agent free?
The software is free and MIT licensed. You pay for model inference and for whatever infrastructure you run it on. Nous Portal offers optional paid tiers ($20, $100 and $200 per month as of September 2026) that bundle model credits and hosted tools, but you can use your own provider instead.
Is TrueForge open source?
Yes, MIT licensed at github.com/truefoundry/trueforge, with docs at trueforge.dev. Run it locally with npx @truefoundry/trueforge or deploy it for a team with Docker Compose or Helm.
Does TrueFoundry support MCP and agents from other frameworks?
Yes. TrueFoundry includes an MCP Gateway, an Agent Gateway, and an agent and MCP registry with tool-level access control, so agents built on any framework can be governed through one control plane.














.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)




.png)

.png)





