The first wave of agent tooling answered a fascinating question:
How do I build an agent?
The next operational question is different:
What happens when my company has 10, 100, or 1,000 agents doing real work?
At that point the problem starts to resemble workforce operations: identity, ownership, permissions, budgets, credentials, performance, supervision, and offboarding.
That is the idea behind Heimda11, a self-hosted Digital Workforce OS.
The digital-worker model
I don't think companies will be satisfied with a list of anonymous automations.
An AI worker should have an accountable identity:
- a role and department
- a human owner
- an autonomy level
- a monthly compute / model budget
- an allow-list of tools
- a lifecycle state
- performance and audit history
Heimda11 turns those concepts into an operational control plane.
Gate: what is this worker allowed to do?
Gate is default-deny.
An agent can request an action such as using a tool, changing data, or triggering a financial workflow. Policies can allow it, deny it, or require explicit human approval.
A governed workflow cannot simply skip the decision. Flow checks Gate before every step.
Meter + Watch: what does this worker cost and produce?
Meter records model/provider usage and attributes AI spend to the worker.
Watch records traces, outcomes, failures, value, and operational events.
That lets the company move from “we spent a lot of tokens†to questions such as: what did this AI worker cost, what did it complete, and what value did it produce?
Vault: agents should not own raw credentials
Vault encrypts secrets at rest using a customer-controlled master key.
Agents can receive short-lived, one-time leases scoped to their own identity. A different worker cannot redeem the same scoped secret.
Relay can also consume provider credentials internally without exposing the plaintext credential to the requesting agent.
Relay: continuity between model providers
Heimda11 includes ordered provider fallback for OpenAI-compatible APIs.
The point is not to invent another model API. The point is to make model choice and provider failure an operational concern that can be governed and observed.
Memory + Training
Memory provides private self-hosted operational context with namespaces, tags, and optional per-agent ACLs.
Training records certifications attached to the worker identity: skill, score, issuer, and expiration.
Why self-hosted first?
If this layer eventually controls a company's AI workforce, it becomes sensitive infrastructure.
It may contain operational history, policies, credentials, company memory, budgets, and audit records.
Heimda11 therefore ships as a single Go binary with an embedded administration console and Docker support.
What is in v0.1.0?
The first integrated release includes Registry / Control, Gate, Meter, Watch, Vault, Relay, Flow, Memory, Training, an embedded admin UI, authenticated HTTP API, Docker / Compose deployment, Windows/Linux binaries, tests, and self-hosted CI.
It is intentionally vendor-neutral. The long-term goal is to sit around existing agent stacks, not replace every framework.
Try it
GitHub:
https://github.com/ricardoaldape/Heimda11
Community is free and self-hosted.
I'm especially interested in feedback from teams already running agents in production: which problem hurts first — identity, permissions, credentials, cost, observability, reliability, or coordination?
I'm also opening a small Founding Company program for teams that want guided self-hosted onboarding and direct product feedback access.
AI disclosure: AI tools were used extensively during the design, implementation, review, testing, and preparation of this article. The repository contains executable code, tests, CI, and published release binaries so the work can be inspected directly.
Top comments (0)