Overview
What you need in place, the two ways to bring the platform up, and how to choose between them. Read this page first.
SkyMythos offers two ways to get started, and which one you pick depends on what you are trying to verify.
The local runtime brings up the control plane and a task runtime on your development machine with a single command. It suits a first contact with the platform, confirming that a model gateway is reachable, and walking the domain model through one complete task. It needs a machine that can run containers, and a reachable model gateway.
A local Kubernetes deployment installs the control plane, the Agent Runner, the Sandbox Provider and the runtime into a cluster through one unified Helm install. It suits verifying the isolated execution boundary and the behaviour of the Agent Sandbox and network policy.
Both paths assume the infrastructure underneath is already in place. The Kubernetes path additionally requires the Agent Sandbox Controller, a RuntimeClass and a network policy enforcer to be installed beforehand; none of those are part of the Helm install.
What you need in place
The platform is designed private-first: every critical path runs inside your own network without depending on an external managed service. Before starting, have the following ready.
| Component | What it is for | Required |
|---|---|---|
| Container runtime | Hosts the control plane and the task execution environment | Yes |
| Model gateway | Serves chat and reasoning model calls | Yes |
| PostgreSQL | The authoritative store for the control plane's structured business state | Required in production |
| S3-compatible object storage | Large objects — runtime snapshots, frozen requirements, capability packages | Required in production |
| Kubernetes cluster | Isolated execution boundary and sandbox lifecycle | Kubernetes path only |
| Git service credentials | Clone repositories, read issues, open change requests | Required once you create tasks |
You can start without configuring Git or the knowledge data plane. As soon as you create a real task, though, the runner needs to be able to reach a repository.
Choosing a path
If your first goal is to understand how the product works, pair the Core concepts section of this manual with a local run, reading and watching side by side.
If you have already decided to evaluate isolated execution and the cluster deployment shape, go straight to the Kubernetes deployment and come back to the concepts afterwards.
If what you need to confirm is that the platform interoperates with your existing model gateway and code hosting system, configure the model gateway and the enterprise connectors first, then create a task.
Reading order for this section
The three pages in this section are meant to be read in order: confirm the requirements and versions, complete the deployment, then create your first task. The third page walks all the way through preflight, execution, artefacts and delivery, and it is the fastest way to understand the whole product.
One caveat, stated up front
This manual distinguishes between what is implemented and what is a target shape. The repository today contains a working vertical slice covering the domain model, the control plane, real agent sessions, isolated sandboxes, dependency-graph scheduling, artefact handoff, knowledge recall, runtime snapshot and resume, observability and the console. That is not the same as a complete production release: the highly available control plane, enterprise single sign-on and audit, production installation and upgrade, and full end-to-end acceptance against real enterprise gateways and code hosting systems are all still under construction.
Wherever a description is marked as a target, do not treat it as a verified capability.