The agent runtime

An agent combines a tenant-scoped Agent, an AgentTemplate describing its behavior, and a Harness selecting its runtime. Sessions execute through Substrate workers. An agent definition is not a dedicated, always-running Deployment.

The pinned contract

The platform targets kagent 1.0.0-alpha5, with Go source pinned to d4ed7dea2079c43d734c7d77840ed328c7c4c728. Its resources use api.kagent.dev/v1alpha3; Substrate resources use ate.dev/v1alpha1. The cluster runs the kagent chart’s own controller at that version, one replica; the platform does not fork it.

Resource Responsibility
AgentTemplate Prompt, model, skill selection and tool bindings
Agent References a template and the tenant’s Harness
Harness Selects the runtime image, WorkerPool and snapshot location
WorkerPool Supplies the tenant’s Substrate execution capacity
Session and task Runtime state reached through kagent’s APIs, not Kubernetes custom resources

The tenant baseline creates the spooky-kagent Harness and tenant WorkerPool. CreateAgent validates the requested configuration and establishes the required model, credentials and tool bindings before writing the agent resources. Kubernetes acceptance does not mean a session has started, and the multiple resource writes are not a database transaction. A durable creation reservation assigns the immutable agent UID before brokerage and credential publication. A matching retry reuses that UID; a background reconciler repairs accepted agents whose configuration publication or activation was interrupted. New work remains blocked while creation is incomplete.

See the pinned API source and current upstream concepts.

Skills and native tools

The skills catalog comes from the Spooky-Labs/skills Git plugin package. The custom runtime image bakes its selected package revision into /plugins/plugin-0; the image digest and skills_package_commit travel together in the deployment pin file. The legacy RPC name ListContainerSkills now lists this package. It does not enumerate OCI images.

An explicit skill selection must resolve in the catalog. An empty selection uses the defaults; disable_workspace_tools selects no skills. A skill provides instructions and resources for existing tools. Its presence alone does not create an arbitrary new native tool or MCP server.

The patched runtime keeps skill discovery/loading and workspace file tools when the skills capability is enabled. It removes the native bash tool and kagent’s ask_user tool from the model’s registry, including subagents. Agents are long running and autonomous, so no tool may stop a run to wait for a person. The platform MCP server exposes scheduling tools, not a replacement shell or code runner. See Runtime isolation.

Each existing package cache must carry a source marker matching the requested repository, commit and path, or the applicable OCI/S3 source fields. Missing, malformed or mismatching markers stop materialization before agent construction and server startup. The image build validates packaged skills with the pinned ADK parser and records that source marker. Missing or renamed selected skills also fail instead of silently selecting alternatives.

This check runs when each runtime starts. It is not an API check that the deployed image supports all saved skill revisions, or a cluster-wide promotion gate. A new catalog pin does not rewrite existing agents: preserve compatibility with their saved sources when promoting runtime images.

Capabilities and edits

Skills, workspace-tool choices, delegation targets, tool bindings and paper-trading markets are fixed at creation. Changing those choices requires a new agent. Ordinary edits preserve saved skill source pins and capability selections, even if the current catalog has changed or is unavailable. Unsupported arbitrary tools, mcp_servers, memory, workspace and per-edge subagent descriptions are refused.

Explicit changes to immutable selections return FailedPrecondition. UpdateAgent.update_mask records presence for these selections, including an explicitly empty list or false; it does not make the other mutable fields a general partial-update API. Importing over an existing agent must retain its exact saved capability configuration. A new import resolves skill names through the creation catalog.

Agent read-back includes selected skills with source URL, commit, path or OCI reference, workspace_tools_enabled, native_tools, and capability_selection_immutable. Without skills the native inventory is empty. With skills enabled it is list_skills, load_skill, load_skill_resource, read_file, write_file and edit_file. It does not advertise native Bash, ask_user or optional file tools that this runtime does not enable.

The supported capabilities are:

Capability How it is supplied
Model inference A catalog model through the platform’s model gateway
Prompt composition System prompt and supported prompt fragments
Skills and files Pinned plugin skills plus the runtime’s file tools
Tool approval Only for an imported MCP tool binding with requireApproval; agents created in the console never pause; see Streaming
Delegation Named agents in the same tenant; self, duplicate and cross-namespace targets are refused
Scheduling Platform MCP tools schedule_wake, list_wakes, cancel_wake
Paper trading Brokerage tools filtered to the agent’s configured markets

Tool availability also depends on configured services. The API’s read-back and runtime bindings, not a count inferred from selected skills, determine what an agent can call.

Configuration reconciliation

The Agent retains the desired template; the separate AgentTemplate is its runtime projection. Failed projection writes are retried from that desired configuration. Reconciliation also converges per-agent credentials, MCP server references and model gateway settings while preserving the selected model, skill pins and tool selections. It does not provision a replacement brokerage account. A successful definition update does not establish that an already prepared actor has loaded it.

Suspend, resume and history

Suspension records a platform annotation that blocks new work and requests suspension of the agent’s sessions. Substrate session suspension snapshots state and releases its worker allocation. Resume clears the platform gate; a later message can resume the session. This is not a replica-count change on a per-agent Deployment.

Deletion records durable intent and blocks new work before cleanup. Cleanup waits for admitted operations, stops active tasks and retries remaining steps. It retains session history and records the deleted agent’s immutable identity. Reusing the name creates a new incarnation; retained sessions cannot submit work to that replacement.

A suspension request, an admitted message and a completed task are different states. Partial failures must remain visible. Task history is a persisted projection with the reconciliation limits described on Streaming, not a promise to replay every live frame.

Retired runtime

The separate agents repository is archived historical material. The current Harness uses the custom runtime built from platform-api/runtime/kagent; the archived BYO image is not a supported alternative deployment path.