DIGITAL EMPLOYEES · BUILT FOR REAL WORK
Digital employees.Built for lasting work.
A lasting identity, validated Memory and reusable Skills. Each completed task lays the groundwork for the next.
The SkyMythos Agent executes a task and produces work. Validated feedback forms Memory records and a reusable Skill; the next task calls both, representing the direction of RSI.Digital employees
Work together. Build experience.
A lasting identity, a defined role, and experience carried into the next task.
Newly distilled experience needs validation through later use. Access follows workspace and project permissions.
Lasting identity
Each digital employee has a distinct identity. That identity and its experience remain after a task ends.
Defined roles
Hire by role and work within granted access. Role upgrades preserve existing experience.
Grounded experience
Experience is drawn from real work, with its sources retained. Review, correct, or exclude what no longer applies.
A clear path from requirement to delivery.
Control plane · Prepare
- 01
Create
Task record
- 02
Preflight
Frozen spec
- 03
Provision
Environment
Task sandbox · Supervisor
- 04
Execute
Agent sessions
- 05
Hand off
Frozen artefacts
- 06
Deliver
Merge request
Control plane
- 07
Consolidate
Knowledge delta
Explore the full process and state authority
01Create
Persist the task record and return an identifier. No sandbox resource exists yet, so a failure here never leaves an orphaned pod.
control plane
02Preflight
Re-authorise against the current principal and scope, check repository, dependency graph, schema and budget deterministically, then freeze an immutable specification. Failure keeps structured findings.
control plane
03Provision
Create the sandbox, clone the repository at a specific commit, materialise requirements and capability bundles, configure the runtime and start the agent.
control plane → provider
04Execute
The supervisor selects nodes with satisfied dependencies, runs independent agent sessions in parallel under quota, and handles waiting, failure, rework and cancellation.
sandbox supervisor
05Hand off
A successful attempt freezes its declared artefacts, manifest and result summary under contract, into a read-only snapshot outside the agent's writable directory.
sandbox supervisor
06Deliver
A controlled completion step pushes the checkpoint branch and idempotently creates a merge request. The credentials it uses are invisible to the agent session.
sandbox → git
07Consolidate
Produce a knowledge delta from inputs, artefacts, code changes and verification results, and synthesise it into reviewable formal cognition for later tasks to recall by frozen version.
control plane
Built for collaboration
Clear boundaries. Grounded execution.
The control plane governs access and resources. Agents collaborate in isolation and hand off work under clear contracts.
Explore the architecture →Task sandbox · one per task
GatewayWeb / WebSocket → sandbox access
Contracts & LibrariesShared protocols and semantics
Explore further
Task workbench
Create, observe and manage R&D tasks. Inspect node topology, agent sessions, artefacts, verification results and delivery state in one surface.
Flow and work node library
Describe the R&D DAG with publishable flows, and reuse agent capability and quality gates through immutable work node releases. Ordinary users describe the task; the platform reuses an existing flow when one fits.
Isolated execution
One sandbox per task. Runs locally or on Kubernetes agent sandboxes with a gVisor boundary. Every attempt uses its own Git worktree.
Deterministic delivery
Completion is constrained by an artefact manifest, a result summary, content digests and unit gates. Downstream nodes cannot modify an upstream artefact.
Resume and rework
Execution-level retry is counted separately from semantic rework. Execution generations, attempts and snapshots are retained so work can resume at a defined point.
Project knowledge loop
Manage long-lived project knowledge, decisions and personal working preferences. Knowledge enters the sandbox read-only and is recalled by frozen version in later tasks.
Capability supply chain
Manage versioned skills, MCP endpoints and enterprise resource connections. A task consumes only resolved, frozen capabilities — never floating content at runtime.
Observability
Understand agent behaviour and system health through live events, task and node state, and OpenTelemetry traces.
What it deliberately does not do
Does not replace code hosting or review
Works alongside GitHub, GitLab and similar systems rather than rebuilding repositories, review and permissions.
Does not build general CI/CD or production release
Collaborates with Jenkins, Argo CD and similar tools instead of taking over build clusters and release pipelines.
Does not centre the product on a DAG canvas
Running tasks and agent sessions are the primary working surface. The execution graph explains the process on demand.
Does not treat agent self-restraint as security
Credentials, tools, network and high-risk side effects are constrained by platform policy — never by a prompt or a model's judgement.
Does not treat full conversations as long-term knowledge
Content entering a knowledge space must be traceable, reviewable and backed by an explicit authoritative source.
Current stage
What exists today, and what is still missing
The core workflow runs. Production readiness remains in progress.
Current progress and limitations
The repository already contains a working vertical slice, runnable locally and on OrbStack, proving that the domain model, control plane, real ACP agent sessions, isolated sandbox, DAG scheduling, artefact handoff, knowledge recall, runtime snapshot and resume, observability and console experience connect end to end.
That is not the same as a complete production release. Full persistence coverage, enterprise single sign-on and audit, a highly available control plane, additional coding drivers, production installation and upgrade, and full end-to-end verification against real enterprise gateways and code hosting are still under construction.
This section describes the actual state, not the target state.
Start with your first task
Deploy the local slice, configure a model gateway, then submit a real task. The documentation follows the order you would actually work in — you do not need the whole domain model first.