Production Feature Agents

Eden includes seven Adam-managed Hermes specialist blueprints for operating the production security and infrastructure feature set, plus a portfolio-wide Hermes orchestrator. Each blueprint is a versioned Agent definition with a long-form prompt, built-in skills, a schedule, Eden-only tool scope, approval gates, and an evidence contract.

The blueprints do not bypass Eve. Every run uses a dedicated agent service identity, and every API or endpoint action remains subject to organization scope, RBAC, endpoint policy, approvals, and audit.

The first names are display identities for conversation, alerts, and the UI. Always show the role beside the name. Profile slugs remain stable for commands, configuration, APIs, and automation.

Feature coverage

Related features share an agent only when their schedule, approval model, and safety boundary are the same. This keeps permissions narrow without creating duplicate agents that behave differently only by name.

API access

eden is one audited tool transport, not one API. It exposes eden_api_read, eden_api_write, and eden_api_admin. Each blueprint carries its exact route list in the persisted prompt and scope.api_access:

The specialists' 119 assignments include shared inventory and evidence routes needed by more than one role. Hermes receives their deduplicated 92-route union, for 211 assignments across eight persisted Agent payloads. Route declarations make the APIs discoverable; they do not grant access. Service-identity RBAC, endpoint policy, and approval gates remain authoritative.

Hermes orchestration

eden-assistant deploys Hermes — Production Orchestrator. Hermes has all specialist production skills and derives its API inventory directly from the seven specialist contracts. It delegates focused work to the owning specialist and correlates cross-feature evidence. Hermes remains read-only by default; write and admin operations still require the owning specialist's approval boundary and the service identity's permission.

Safety model

All production feature agents:

• default to read-only investigation;
• run through Adam orchestration under a dedicated service-agent identity;
• use eden as their only tool endpoint;
• cannot connect directly to customer databases or infrastructure;
• label missing production evidence as unknown rather than passing it;
• require explicit approval for governed mutations;
• keep passwords, private keys, tokens, raw PII, query arguments, and customer

payloads out of prompts, Slack notifications, memory, and evidence;

• report exact resource identifiers, safe status, and tool evidence for claims.

The service identity must receive only the organization, endpoint, and permission bits required by that specific agent. Installing a blueprint does not grant it access.

Inspect a blueprint

From an Eden checkout, list the available profiles:

adam_runtime/adam_agents/adam_agents list

Generate the complete scheduled-Agent payload without changing Eden:

ADAM_AGENT_ENDPOINT_UUID="<llm-endpoint-uuid>" \
ADAM_AGENT_SERVICE_IDENTITY_UUID="<agent-service-identity-uuid>" \
adam_runtime/adam_agents/adam_agents payload audit-observability

Use eden-assistant to inspect the complete Hermes orchestrator payload:

ADAM_AGENT_ENDPOINT_UUID="<llm-endpoint-uuid>" \
ADAM_AGENT_SERVICE_IDENTITY_UUID="<agent-service-identity-uuid>" \
adam_runtime/adam_agents/adam_agents payload eden-assistant

Dry-run is the default. Review the prompt, skill_ids, tool_endpoint_uuids, schedule, Slack metadata, approval policy, and service identity before deployment.

Deploy a blueprint

After granting the service identity its least-privilege access:

export ADAM_AGENT_ENDPOINT_UUID="<llm-endpoint-uuid>"
export ADAM_AGENT_SERVICE_IDENTITY_UUID="<agent-service-identity-uuid>"
export ADAM_AGENT_TOKEN="<operator-token>"

adam_runtime/adam_agents/adam_agents deploy audit-observability --apply

The deployment creates an ordinary versioned scheduled Agent through POST /api/v1/llm/agents. Operators can inspect its status, runs, logs, metrics, and A2A card through the standard Agent APIs.

What each agent proves

The agents produce bounded operational evidence, not compliance or availability claims on their own:

• Nora, the Platform Readiness agent, separates observed Eden state from

customer-owned backup, secret, collector, and failure-drill evidence.

• Marcus, the Identity Governance agent, records the exact organization,

subject, group, resource, and effective permission bits without exposing credentials.

• Priya, the Data Protection agent, distinguishes request denial from backend

response controls and uses synthetic canaries by default.

• Theo, the Audit and Observability agent, distinguishes configured sinks from

observed admission, replay, acknowledgement, and exporter delivery.

• Elena, the VPN Configuration agent, verifies subject identity, RBAC, interlay

binding, route ceilings, and—when active-active VPN is selected—the shared server public key, stable source-restricted UDP load balancer, cache sync, disruption budget, and next-handshake failover boundary.

• Ben, the Credential Rotation agent, preserves one stable rotation ID and

verifies that the customer provisioned the target replacement first.

• Maya, the Compliance Evidence agent, verifies explicit scope, authorization,

hashes, coverage, truncation, and sensitive-field absence without invoking a model.

Related docs

• Adam
• Model Routing And Orchestration
• LLM And Agent APIs
• Production Deployment
• Eden VPN
• Database Credentials
• Promptless Evidence