ebarahona/hermes-one

Hermes ONE (Orchestration Node Engine): a multi-tenant agent orchestration engine.
Hermes is assembled by IoC (inversion of control). Every process is a DI (dependency injection)
container (LoopBack 4 on the edge plane,
agentback on the agent plane), and dependencies are ports
resolved from bindings, with adapters wired at the composition root. Provider adapters (edge plane)
and authentication strategies plug in as extensions discovered at runtime; adding one is a new
binding, not a change to the platform.
What runs is decided by data, not by deploys. Workflows, rules, policies, capabilities, and agent
engines are versioned, content-hashed definitions; publishing a deployment changes a tenant's
behavior on the next message, while runs in flight stay pinned to the version they started on. Each
agent turn gets its tools injected at runtime from the pinned capability contracts, filtered to what
the engine allows and the caller's scopes cover, and bound to the tenant's ranked providers and
credentials.
The full map of bindings, components, extension points, ports, adapters, composition roots, and
what is and isn't dynamic is in docs/COMPOSITION-AND-RUNTIME.md.
A deterministic Temporal workflow rail with bounded agent nodes inside it. The workflow owns
orchestration; the agent owns bounded reasoning; the model proposes, the runtime disposes —
every tool the model calls passes a policy gate, every side effect carries an idempotency key, every table with a
tenantid column is scoped by row-level security, and every turn's tool executions, evidence, and policy decisions are
durably recorded for audit. The reasoning behind these choices is in docs/WHY-THIS-ARCHITECTURE.md; governing
decisions live in docs/adr/; the build sequence in docs/BUILD-PLAN.md.
> Status: pre-1.0. The core platform runs end to end and is covered by unit, integration,
> replay, and end-to-end tests. Interfaces may still change between minor versions. What is planned
> but not built yet is listed under Roadmap; open work is tracked in
> docs/DEFERRED-AND-FLAGGED.md; deployment boundaries are listed in SECURITY.md.
## Capabilities
Verticals are data, not code (ADR-013) — proven live. The electrician vertical is a single
pack.json (workflow, triage rule, policy, capability, agent engine). It installs through the
platform's own admin API (apps/admin-api/src/pack-e.itest.ts), and a live LLM turn on real
Temporal (apps/agent-worker/src/pack-e.e2e.ts, which installs the same definitions in-process)
yields a tool-backed agent conversation — the model calls appointment.slot.read, the
platform resolves a ranked provider, and the result is durably recorded. A new vertical is a new pack file, not a deploy.
Two verticals ship in verticals/: a residential electrician (electrician/) and support-ticket
triage (support/), where rules answer or escalate most messages and the model is called only
for a message that needs judgment.
Bring-your-own-vendor multi-tenancy. A tenant can rank its own provider first
(capability.providermappings, admin-managed) and supply its own credentials
(envelope-encrypted per tenant, rotated with a single rotate() call) — zero deploys, proven live: