Blog · Guide · 29 October 2026

Choose an AEGIS agent runtime from the standard registry

Also in: Español, Português, 日本語, Deutsch, Français, 한국어, 简体中文, Italiano, हिन्दी

Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation, chiefly the Standard Runtime Registry, the aegis.runtime.list entry of Management Tools and the CLI Reference, and reviewed by the company. Every YAML line, call and command below is copied from those pages; none was run for this guide. Where the docs leave a question open, the last section says so.

AEGIS by 100monkeys.ai, in beta, runs each agent in a container. An agent manifest can name a language and a version instead of an image, and the orchestrator picks the image. The registry page puts it plainly: "Using StandardRuntime means you never specify a Docker image directly." This guide picks a runtime, checks it before deploy, and shows what happens at run time.

Step 1. Know what the registry decides

When a manifest gives spec.runtime.language and spec.runtime.version, the orchestrator "resolves them to a deterministic, pinned Docker image at execution time." The mapping lives in runtime-registry.yaml, committed to the orchestrator repository and loaded when the daemon starts. The point for review is that two agents naming the same pair run on the same image, and nobody types an image tag into a manifest.

Step 2. Ask the registry what it accepts

An agent that writes other agents' manifests, or a person at a client, can call the built-in tool aegis.runtime.list. With no arguments it lists every runtime; with a language it filters:

{}

{ "language": "python" }

The answer names each runtime's language, version, image, description and a deprecated flag, plus custom_runtime_supported. The registry page gives the reason for the tool: it "prevents hallucinated language-version combinations from being written into manifests." It is available in the aegis-system-agent-runtime security context "with no additional configuration".

Step 3. Pick a supported pair

The registry page's matrix, as it stands:

Manifests that name a deprecated version "still execute but emit a warning in the execution log". The page names python: "3.9" as deprecated and says to move to 3.10 or 3.11. Removals are announced "two phases in advance", and a removed version fails validation.

Step 4. Write it into the manifest

spec:
  runtime:
    language: "python"   # Required (StandardRuntime)
    version: "3.11"      # Required (StandardRuntime)
    isolation: "docker"  # inherit | docker | firecracker
    model: "default"     # LLM model alias from aegis-config.yaml

"Specifying an unsupported language+version combination is rejected at execution validation time with a descriptive error. There is no fallback to a default version." That last sentence is the useful one: a typo does not quietly run on some other interpreter.

Step 5. Validate, then deploy

aegis agent deploy ./agent.yaml --validate-only
aegis agent deploy ./agent.yaml

--validate-only parses and validates without deploying. Deploying the same name and version twice fails unless you add --force.

Step 6. Install what the agent needs, or move to a custom image

Each standard image carries its language's package tool: pip and apt on the Python images, npm and apk on the Node images, go and apk on Go, cargo and rustc on Rust. For TypeScript the orchestrator sets TYPESCRIPT_VERSION=5.1 and the docs say your bootstrap should install the toolchain with npm install -g typescript ts-node. When an agent needs OS packages such as ffmpeg, a version the registry lacks, prebuilt binaries or private dependencies, the page's answer is a Custom Runtime, your own image, rather than installing the same things on every run.

Step 7. Know what happens when the agent starts

For a standard runtime the orchestrator resolves the pair to an image, creates the container with a main process that only keeps it alive, uploads its bootstrap.py to /usr/local/bin/aegis-bootstrap if it is not already there, and runs it with the prompt. The bootstrap connects back to the orchestrator's dispatch gateway and runs the iteration loop: "generate → execute → validate → refine".

Step 8. On your own node, keep the registry file where the daemon looks

# aegis-config.yaml
spec:
  runtime:
    runtime_registry_path: "runtime-registry.yaml"

The default path is relative to the daemon's working directory. If the file is missing or does not parse, the daemon "hard-fails at boot", because "a missing registry makes every StandardRuntime agent execution impossible." Set an absolute path when the daemon runs from another directory or inside a container image.

What the docs leave open

• Two example answers disagree. The registry page's sample answer from aegis.runtime.list lists Python 3.11, 3.10 and 3.9 on python:3.x-slim; the Management Tools page's sample lists Python 3.12 on ghcr.io/100monkeys/runtime-python:3.12, which the matrix does not hold. Ask your own node rather than trust either sample.
• When a bad pair is caught. The registry page says an unsupported pair is rejected "at execution validation time". It does not say whether aegis agent deploy --validate-only already catches it.
• Isolation values. The registry page's manifest comment lists inherit | docker | firecracker; the workflow and agent references also list process.
• Dates. No removal date is given for Python 3.9 beyond "Phase 2".

Next

The runtime is one field of the agent manifest. For the rest of it, read The AEGIS agent manifest: every field and what it enforces. AEGIS installs with the command printed on 100monkeys.ai:

curl -fsSL https://get.100monkeys.ai | bash

Install AEGIS from 100monkeys.ai