Skip to content
kube-agents

Manual install

If you’re not using GKE or the shipping ./install.sh flow, you can install the Platform Agent workspace into an existing Hermes-compatible harness by hand. This page covers the harness-side setup only; you still need to arrange cluster access, chat ingress, an inference gateway, and (for GitOps flows) a token minter separately.

Prerequisites

Section titled “Prerequisites”
  • A harness or platform that runs the Hermes agent runtime (nousresearch/hermes-agent) with workspace file access and tool execution.
  • kubectl configured with access to the target Kubernetes cluster(s).
  • cert-manager v1.13.0+ on any cluster where you plan to install the operator’s webhook.

Step 1: Copy the workspace

Section titled “Step 1: Copy the workspace”

The Platform Agent needs a dedicated workspace directory containing its persona, config, skills, governance SOPs, and cron definitions.

Terminal window
cp -r agents/platform /path/to/harness/workspace/agents/platform

The directory layout your harness will see:

platform/
├── SOUL.md                  # persona / system prompt
├── AGENTS.md                # workspace runtime instructions
├── CAPABILITIES.md          # one-line routing description for the front door
├── config.yaml              # MCP servers, toolsets, plugins
├── skills/                  # SKILL.md bundles
├── governance/              # SOPs the scheduled governance jobs point at
├── cron/jobs.json           # empty — the schedules live on the Planning Agent
├── plugins/                 # in-tree Hermes plugins (incident_context, memory)
├── docs/                    # workspace docs (glossary, console-link templates)
└── scripts/                 # in-pod Python MCP servers + kanban helpers

In the operator-deployed pod this workspace is one of several Hermes profiles: chat ingress is owned by the separate Planning Agent workspace (agents/chat/, whose defaults/ holds the chat-ingress hooks and plugins), which delegates to the Platform Agent over the kanban board, and per-cluster Cluster Agent profiles are scaffolded at runtime from the agents/cluster/ template. A manual install that only registers agents/platform/ gives you a working direct-query agent; to reproduce the shipped chat front-door behaviour you also need to register agents/chat/ as the chat-facing profile.

Step 2: Register the agent

Section titled “Step 2: Register the agent”

Configure your harness to register a new agent named platform:

  • Workspace directory: the platform/ directory copied in step 1.
  • System prompt: load from SOUL.md.
  • Config: load MCP servers, toolsets, and plugins from config.yaml.
  • Skills: point the harness at skills/ (the runtime discovers SKILL.md files automatically).
  • Registration: perform the platform-specific agent registration and reload/restart the harness if required.

Step 3: Enable the scheduled watchdogs

Section titled “Step 3: Enable the scheduled watchdogs”

The Platform Agent runs its routine maintenance and drift detection as autonomous governance jobs on cron schedules. They live in the workspace you just copied, at agents/platform/cron/jobs.json, and each carries a pre-authored prompt that points at a governance SOP under the Platform Agent’s governance/.

  • If your harness has native cron support (Hermes does), the jobs register automatically once the workspace is loaded — no extra configuration is needed. Ticking is a property of the profile that owns the running gateway, so a second job, profile-cron-tick on the Planning Agent’s roster (agents/chat/defaults/cron/jobs.json), is what advances this profile’s schedule; it ships with that workspace.
  • Otherwise, wire each job into your scheduler by hand: for every entry in agents/platform/cron/jobs.json, create a recurring task on the job’s schedule.expr (a standard 5-field cron expression) that sends the job’s prompt verbatim to the platform agent.

See Autonomous watchdogs and Reference → Cron jobs for the full, annotated job list.

Step 4: Wire the surrounding infrastructure

Section titled “Step 4: Wire the surrounding infrastructure”

The manual install covers only the agent workspace. To reach parity with a ./install.sh install, you still need:

  • Cluster access: a Kubernetes context the agent can call. The shipping config expects the GKE MCP server proxied via mcp-remote; for other clusters, substitute your own Kubernetes MCP server or add kubectl to the toolset.
  • Chat ingress: Google Chat Pub/Sub or Slack Socket Mode. See ChatOps.
  • Inference gateway: any Completions-API-compatible endpoint (LiteLLM is the default recommendation). See Inference gateway.
  • GitHub token minter: for the submit-suggestion and github-issue-resolver skills. See Deploy → Token minter.

Verify

Section titled “Verify”

Interact with the agent through your harness’s chat surface. It should respond with a status update, and it will begin running the governance SOPs autonomously as their cron schedules fire.

Post-install

Section titled “Post-install”