Hermes gateway
01- ▸Routes Slack, webhooks, and channels to the right worker
- ▸Channel auth stays out of the execution pod
- ▸One gateway can front many workers
// agents
Agent platform on Kubernetes.
A reproducible template we run in production—spin up new agents for your org without long-lived secrets in the execution environment.
// architecture
// how it runs
Gateway, worker, trust services.
Channels hit the gateway. The worker runs your config and tools. For GitHub or cloud APIs it calls in-cluster Go services that mint short-lived credentials—nothing long-lived in the pod.
Agent worker
02- ▸StatefulSet pod: context, KB, skills, and workspace you configure
- ▸Model routing and MCP at runtime
- ▸Calls broker and identity with Kubernetes service-account identity
Trust services
03- ▸GitHub credential broker: short-lived git and gh tokens
- ▸Agent identity: OIDC for cloud provider APIs
- ▸Signing keys and OAuth stay in trust services, not the worker
// trust boundary
What stays in the pod vs what does not.
// pillars
What every production agent needs.
What you provide
Context
Identity, rules, scope
Knowledge base
Static reference docs
Skills
Callable procedures
Workspace
Repos, files, volume
How it runs
Tools
MCP, external APIs
Memory
Preferences, entities, corrections
Model
Provider, routing
Platform
Execution environment
Kubernetes pod, gateway
Trust & permissions
Broker, identity, policy
Channels
Slack, webhooks, gateway
Observability
Logs, metrics, traces
You supply the agent; durable work stays in your GitHub org.
You configure context, knowledge, skills, and workspace. The agent opens branches, commits, and PRs in repositories you own—state lives in your GitHub account, not in a disposable chat session.