Why we built it
Hermes Hub began with a practical question inside JetCalls: what would it take to host AI agents for small business in a way that felt useful, repeatable, and operationally responsible?
The easy version of that question is a chatbot. Give every customer a prompt, connect a model, add a chat box, and call the result an AI business assistant. That was not enough for the product we wanted to prove.
Small businesses do not only need answers. They need continuity. They need an assistant that can remember the business, return to recurring work, receive messages through normal channels, and keep client data separated from everyone else. Agencies and operators need something else too: a way to create, inspect, stop, update, and recover those agents without treating every customer as a hand-built one-off.
That is the shape Hermes Hub grew into. It is a hosted AI agents control layer for tenant-scoped Hermes Agent runtimes. The product journey was not about inventing a bigger prompt. It was about building the operating layer around agents: tenant records, isolated memory, scheduled work, runtime lifecycle controls, access boundaries, chat routing, A2A interoperability, business defaults, and enough administrative surface to run the system deliberately.
This article is a building-in-public account of that process. It is not a claim that Hermes Hub is a finished large-scale enterprise platform. It is a proof that hosted business automation agents need infrastructure before they can become dependable products.
The first constraint was isolation
The first hard decision was to treat each customer as a tenant, not as a row in a shared prompt table. That sounds obvious until the product starts doing real work.
An agent that helps a business may accumulate memory, sessions, schedules, uploaded media, browser state, access metadata, and operational logs. Those are not cosmetic details. They define whether a hosted AI business assistant can be trusted to work across days and weeks. They also define whether one customer can accidentally inherit another customer’s context.
Hermes Hub was built around tenant agent isolation from the beginning. The hub owns the control plane. The runtime does the agent work. Each tenant gets its own workspace and runtime state, while shared release assets are reused centrally so the system does not copy heavy dependencies into every customer environment.
That distinction mattered because we wanted cold-idle agents. A hosted agent should be reachable from the outside, but it should not have to keep every tenant runtime warm all the time. The hub can maintain the public edge, wake the tenant runtime when work arrives, and let the runtime rest when there is nothing to do. For a small-business product, that is both an efficiency choice and an operational discipline.
The lesson was simple: before we could make a better AI agent marketplace or package agent templates, we needed a reliable boundary between tenants. A template is not a tenant. A prompt is not isolation. A marketplace direction only becomes credible when each installed agent has its own memory, tools, schedule, and operating limits.
From chatbot to hosted agent
The next phase was turning the hub from a tenant registry into a working hosted-agent system.
A hosted AI agent has to handle more than one kind of work. It may receive a direct chat message. It may receive a task from another agent. It may wake up on a weekly schedule. It may need to run a longer task, stream progress internally, stop cleanly, or report usage back to the operator. Those requirements pushed Hermes Hub toward an AI agent control plane rather than a narrow chat service.
We added lifecycle controls so tenant runtimes could be prepared, started, inspected, and hibernated. We added runtime integration so work could be sent to the underlying agent in a natural way instead of through a lossy public protocol. We added scheduled wakeups because a business assistant should not wait forever for the owner to ask the next question. We added usage and business metrics so the operator has a better view of what the agents are doing.
The chat work also moved from theory to product pressure. WhatsApp and Telegram-style message flows forced the hub to behave like a real edge adapter. Incoming messages had to be mapped to the right tenant, converted into normal agent conversations, and returned through the same channel without exposing the private runtime surface.
That changed how we thought about the product. Hermes Hub was not only “agents in the cloud.” It became hosted AI agents with a managed boundary: public channels outside, private runtime control inside, and tenant state kept separate throughout the path.
The same thinking now informs other JetCalls product builds. In building AI Site Biz, the question is how agent-assisted website work becomes a repeatable small-business workflow. In building AI Dashboard, the question is how natural-language analysis becomes an operational view. Hermes Hub is the lower layer: where those agent experiences can be hosted, isolated, and controlled.
A2A at the boundary
Agent interoperability became another important proof point. The market is moving toward agents that can discover and call each other, and the phrase agent to agent protocol is no longer only a research topic. It is becoming a product expectation.
Hermes Hub adopted that direction carefully. The hub exposes A2A-style access at the edge, so external systems can discover and call tenant agents. But we did not make the public agent to agent protocol the private control protocol between the hub and the runtime.
That separation is important. Public interoperability and private runtime control have different jobs. A2A is useful at the boundary because it gives other agents a way to find and address a hosted agent. Inside the platform, the hub needs richer controls for lifecycle, scheduling, stop behavior, session handling, and runtime inspection. Collapsing those layers too early would make the product simpler on a diagram and weaker in operation.
The product direction is therefore protocol-aware, not protocol-only. Hermes Hub treats A2A as an edge capability for hosted agents. The internal control plane remains focused on the practical needs of running tenant agents reliably.
That decision also affects how we talk about an AI agent marketplace. We see a marketplace or template catalog as a direction: reusable roles, business skills, scheduled jobs, and agent packages that can be installed into isolated tenant workspaces. But Hermes Hub is not marketplace-first. The first proof is the tenant-scoped operating model. The marketplace layer should sit on top of that, not replace it.
Business context became the product test
The business-agent flavor was where the infrastructure had to prove that it could serve an actual product experience.
We wanted Hermes Hub to support AI agents for small business without pretending that every owner wants to become a prompt engineer. The hosted agent needed a default business-companion behavior: learn the company over time, ask concise questions when context is missing, remember useful facts safely, and help with recurring improvement work.
That led to business defaults rather than a generic blank agent. The business flavor includes guidance for the agent, a small business knowledge scaffold, a weekly review rhythm, and a curated set of business skills around marketing, content, analytics, conversion, email, pricing, sales enablement, launch work, lead magnets, and revenue operations. The goal is not to claim a fully autonomous business. The goal is to give an owner or agency a persistent helper that can return to useful work with context.
This is where the phrase business automation agents becomes concrete. Automation is not only a trigger and an action. For small businesses, it often looks like recurring attention: checking what changed, noticing missing context, drafting follow-up, reviewing pages, preparing campaign ideas, or asking the next useful question. A scheduled review job is modest compared with the hype around autonomous agents, but it is a better product primitive because it creates a repeatable habit.
The business flavor also exposed a healthy tension. Every extra capability increases the need for clearer boundaries. Search, browser work, document handling, media processing, and external account access all have different operational risks. Hermes Hub therefore moved toward cautious defaults: make the business agent useful, but do not bundle every possible tool before the runtime dependencies and safety rails are ready.
That same discipline shows up in adjacent JetCalls builds. Building ReSmart.ai focuses on domain-specific real estate intelligence rather than a vague “agent for everything.” Building Freeform Code explores how coding agents need grounded execution loops, not just chat. Hermes Hub sits in the same philosophy: make the agent useful by giving it a real operating environment.
What the journey changed
Building Hermes Hub changed our internal definition of an AI business assistant.
At the start, it was tempting to describe the product in user-facing terms only: a persistent business companion, a hosted assistant, a tool for agencies serving many clients. Those descriptions are still useful, but they are incomplete. The product only becomes credible when the invisible layer exists underneath.
The invisible layer includes tenant agent isolation, lifecycle control, scheduled wakeups, access management, central runtime reuse, metrics, and a clear split between public channels and private execution. That is what makes Hermes Hub an AI agent control plane rather than a prompt library.
It also clarified the limits of what we should claim. Hermes Hub is not yet a broad enterprise-scale system. It is not a promise that agents can run a company on their own. It is not a generic no-code automation marketplace. It is a concrete hosted-agent foundation built to test how tenant-scoped business agents should work in the real world.
That framing is more useful for customers too. A small-business owner does not need inflated autonomy claims. An agency does not need another abstract agent platform. They need hosted AI agents that keep each client separate, remember useful context, work through familiar channels, and can run scheduled business reviews without creating operational chaos.
For JetCalls, Hermes Hub is proof of a broader product pattern. We are building products where agents do real work inside bounded systems: websites, dashboards, real estate analysis, code workflows, and business operations. Hermes Hub is the layer that asks how those agents should be hosted when they need memory, schedules, interoperability, and operator control.
The next work is straightforward and demanding: continue proving the hosted runtime under production-shaped load, tighten global admission controls, make the admin surface more complete, validate scheduled business-agent behavior, and keep the business-facing experience simple enough for real operators to use.
That is the journey so far. Hermes Hub started as infrastructure, but the infrastructure was the product lesson. Useful AI agents for small business are not just smarter conversations. They are hosted, isolated, scheduled, observable systems that can become part of how a business gets work done.