How Razorpay runs one isolated, always-on Hermes agent per employee on Kubernetes

Who built it

Engineers at Razorpay, an Indian fintech company, writing on the Razorpay Engineering blog (author ashwath kumar, with a contributor and an editor credited). They built the platform so employees get a sanctioned agent instead of improvising their own setups.

How it works

Each employee gets a dedicated Kubernetes namespace containing their own Hermes pod. The pod runs the Hermes gateway (which handles inference, tools and state), the web dashboard, a small loopback relay sidecar and an init container that seeds configuration. Because it runs on a cluster rather than a laptop, the agent keeps working when the owner is offline. A single onboarding script creates the namespace, identity, encrypted volume, config and deployment; the authors report it finishes in under two minutes, and offboarding is a volume snapshot followed by deleting the namespace.

Access goes through one central Go gateway that signs people in with Google Workspace and checks on every request that the signed-in user owns the agent they are trying to reach. The authors' design principle is that tenant separation should come from the infrastructure (namespaces, volumes, identities, network policy) rather than from trusting application code to keep users apart.

Network egress is restricted at the kernel level with Cilium policies: a pod can reach DNS and an audit proxy and nothing else, and cross-tenant traffic is denied by default. All outbound calls pass through CrabTrap, an open-source TLS-intercepting proxy, which attributes each call to a user, logs it and screens it against an LLM-based policy that can block requests. The post reports roughly 15 million screened calls and about 219,000 blocks over a 30-day window.

On the data side, each agent ingests the owner's work context hourly (Slack channels and DMs, GitHub repos, Google Workspace) and runs daily sweeps of external sources such as X accounts, RSS feeds and newsletters. A pipeline turns this into a personal wiki, an entity graph and a vector index the agent can answer questions from. The agent also runs scheduled jobs; the example instance had 21 of them, including morning and evening digests posted to Slack.

The self-improving part relies on Hermes skills: the agent writes reusable procedures for work it repeats, scoped to its owner. The authors describe one instance holding 98 skills across 25 categories, and note that administrators can require human approval for every skill write. They also list practical fixes needed to run the upstream image in a locked-down cluster, and warn that a mutable image tag once left pods running different code, which is why they now pin images by digest.

Lessons you can use

• If you want people to stop running unsanctioned agents on laptops, make the approved, secure option the easiest one to get; Razorpay's under-two-minute onboarding script is the centre of that approach.
• For several users, isolate at the infrastructure layer (separate profile or namespace, storage, credentials and network policy per person) instead of relying on the agent to keep data apart.
• Route all outbound traffic through one auditable proxy so every call can be attributed to a user and blocked if needed.
• Default routine work to cheaper models and save stronger models for hard tasks; a gateway with one scoped key per agent makes this manageable.
• Pin container images by digest, not a moving tag, so every instance runs the same code.
• If agents write their own skills, decide early whether those writes need review, and turn on an approval gate where the stakes justify it.

Try a smaller version

1. 1

   Start with one agent for yourself, but keep its state separate: create a dedicated Hermes profile (hermes profile create) so its memory, skills and config don't mix with other work. See the Profiles docs.

2. 2

   Run it in a container rather than directly on your machine (see the Docker docs), and read the egress docs (Egress docs) to send its outbound traffic through a proxy you can log.

3. 3

   Turn on the skill write-approval gate (skills.write_approval: true, or /skills approval on) so you can review every skill the agent tries to create or change. See the Skills docs.

4. 4

   Add one scheduled digest with cron that reads a single source you trust and delivers to a private Slack channel, then check a week of output before adding more sources. See the Cron docs.

5. 5

   Only after one person's setup is stable, script the provisioning steps (profile, config, credentials) so a second person's agent can be created the same way.

Caveats

• All usage figures (220+ agents, about 84 active daily, 15,039 sessions on one instance, blocked-call counts) are reported by the authors and were not independently verified.
• The post gives no figures on cost, latency or answer quality across the different models, and doesn't say how often the LLM-based egress policy blocks legitimate calls.
• This is a heavy setup that depends on Kubernetes, Cilium and a dedicated platform team; it is a reference design, not a starting point for an individual. The post also doesn't say how the quality of self-written skills is checked.

Spotted something wrong or out of date? Tell us on X at @HermesWatcher↗ (opens in a new tab) and we will fix it.