People ask us: "Is it just an LLM with some prompts?" That's a fair question. The honest answer is no — but to explain why, we need to walk through the actual architecture. This post is that walkthrough. It's technical. It's specific. If you're evaluating whether Cyborg is the right fit for your team, this is the right thing to read.
The 3-layer architecture
A Cyborg is composed of three distinct layers that interact in a defined sequence. Understanding each layer separately, then how they connect, is the clearest way to understand the system.
Layer 1: Identity
Every Cyborg is a named employee. Not a generic assistant — a specific entity with a name (e.g., "Alex, your Cyborg Software Engineer"), a job description, a set of permissions, and a persistent identity that survives across sessions, reboots, and model updates.
Identity is stored as a structured document on the Cyborg's machine. It includes:
- Name and role description
- Onboarding context (what the customer told us during setup)
- Tool permissions — explicitly granted, nothing assumed
- Escalation rules — when to ask before acting
- Working hours and communication preferences
- Review rubric for each output type
The Identity layer is what makes management possible. A human manager can look at a Cyborg's identity document and understand what it's allowed to do, what it knows about the company, and what it will escalate. This is not a black box.
Layer 2: Base Runtime
The Base Runtime is the engine under the hood. It handles four things: memory, the workflow engine, guardrails, and the audit log.
Memory is long-term, customer-scoped, and stored on disk on the Cyborg's own machine. There are three memory tiers: working memory (current task context), session memory (within a working day), and persistent memory (facts about the company, the team, the codebase, ongoing projects). Memory is never shared across customers. It never leaves the Cyborg's machine unless the customer explicitly exports it.
The workflow engine is a custom state machine — not LangChain, not a cloud orchestrator. Each task is represented as a graph of steps with explicit inputs, outputs, and failure modes. The state is serialized to disk after every step, so if the machine reboots mid-task, the Cyborg picks up exactly where it left off. This was a core requirement: no lost work, ever.
Guardrails are a set of runtime checks that run before any action that touches an external system. They verify: is this action within the Cyborg's granted permissions? Is it above the consequence threshold requiring human approval? Has this exact action been blocked by a previous audit review? Guardrails are not LLM-evaluated — they're deterministic code. The model decides what to do; the guardrail decides whether it's allowed.
The audit log is an append-only file that records every action, decision, and escalation with a timestamp, a unique action ID, and a structured JSON payload. It's stored on the Cyborg's machine. It's exportable. It cannot be disabled.
Layer 3: Role Skills
Role Skills are the job-specific capabilities layered on top of the Base Runtime. A Software Engineer Cyborg has a different skill set than a Marketing Cyborg. Skills are composed of three things: playbooks, tool integrations, and review rubrics.
Playbooks are structured procedures for common role tasks. The Software Engineer playbook includes procedures for: picking up a Linear ticket, cloning the relevant repo, writing code to spec, running tests, opening a PR, and posting a standup update. The playbook doesn't script the LLM — it provides a structured task graph the workflow engine executes. The LLM fills in the judgment steps inside each node.
Tool integrations are pre-built connectors for the 55+ tools in our catalog. Each connector handles auth (via scoped OAuth tokens stored in the Cyborg's credential store), API interaction, error handling, and retry logic. The Cyborg calls a connector — it doesn't write API calls from scratch. This matters for reliability and for auditing.
Review rubrics are the quality standards the Cyborg applies to its own output before surfacing it to the human. A PR rubric includes: does the code compile? Does it pass existing tests? Is the diff size within expected bounds? Does the commit message describe the intent? The Cyborg checks these before flagging a PR for human review.
The machine: why a dedicated Windows VM
This is the part that surprises people most. Each Cyborg runs on its own dedicated Windows virtual machine. Not a container. Not a serverless function. Not a thread in a shared process. A real OS instance.
We made this choice for three reasons:
- Isolation. There is no kernel-level sharing between Cyborgs. A bug in one customer's Cyborg cannot affect another customer's Cyborg. This is physically enforced by the hypervisor, not by application-level sandboxing.
- Persistence. Files, credentials, memory snapshots, and the audit log live on the VM's disk. They persist across reboots. They're encrypted at rest with a customer-scoped key.
- Real tooling. A Software Engineer Cyborg needs to run
npm install, execute test runners, interact with the filesystem, and run a browser. You can't do that meaningfully in a stateless serverless function. The VM gives the Cyborg a real environment.
Disk encryption is AES-256 with keys managed per customer. We don't hold the decryption keys — the customer does. This means even if someone gained access to our infrastructure, they'd have encrypted disks they can't read.
Memory architecture in detail
Memory is probably the most important differentiator in the architecture, and the most misunderstood.
When a Cyborg finishes its first week of work, it has accumulated context: the team's coding style, the CEO's communication preferences, the fact that the finance team uses a custom Notion template for budget requests, the ongoing status of three projects it's contributed to. This context lives in the Cyborg's persistent memory store — a structured document database on its own disk.
Memory is scoped strictly to the customer. There is no shared memory pool. When Cyborg A for Company X writes a memory entry, it's written to Company X's disk on Company X's VM. Cyborg A for Company Y has its own disk, its own memory, and cannot access Company X's data under any circumstances.
Memory retrieval is semantic — when the Cyborg is starting a new task, it queries its memory with an embedding search to surface relevant context. But the retrieval is bounded to the customer's own memory store. The model never sees data from other customers.
Model routing
Cyborg is model-agnostic. We don't pin to a single frontier model because no single model is best at everything. We route each task to the model best suited for it based on three factors: task type, required output format, and cost-latency tradeoff.
Code generation tasks route differently than document summarization tasks. Tasks that need structured JSON output route to models known to be reliable at that. Tasks with tight latency budgets route to faster, smaller models. Tasks that require deep reasoning get more capable models with longer context windows.
We maintain a fallback chain. If the primary model for a task is unavailable, the router tries the next best model automatically, logging the fallback in the audit log. Customers can also pin specific tasks to specific providers if they have compliance or preference requirements — this is a config option, not a custom integration.
The daily loop: 5 steps, every working day
This is the operating rhythm of a Cyborg. It runs every working day, in this order:
- Wake. Cyborg comes online at the start of the customer's working hours (configured at onboarding). It checks its task queue, reviews any messages or tickets that arrived overnight, and loads its working memory for the day.
- Plan. Based on open tasks, priority signals from Linear/Jira/Notion, and its persistent memory about ongoing projects, the Cyborg generates a prioritized task plan for the day. This plan is logged and optionally posted to Slack for human review.
- Execute. The Cyborg works through its task list. Each task runs through the workflow engine: playbook selection, step-by-step execution, guardrail checks, tool calls. Blocked tasks escalate to the designated human approver. Completed tasks update the relevant tracker.
- Report. At the end of the working day, the Cyborg posts a structured summary: tasks completed, tasks blocked (with reason), tasks deferred to tomorrow, any escalations raised. This is not an auto-generated summary — it's compiled from the day's audit log entries.
- Learn. After the report, the Cyborg runs a lightweight reflection pass: were any tasks completed differently than the playbook expected? Were any escalations unnecessary in retrospect? Were any tools consistently failing? These observations are written to persistent memory and flagged for the next onboarding review with the customer.
Why we didn't wrap LangChain
When we started building Aliens, LangChain was the obvious starting point. We prototyped with it. Then we rebuilt from scratch. Here's why.
LangChain is excellent at chaining LLM calls quickly. It's optimized for demos and for workflows where the state lives in memory (RAM) for the duration of the run. For a Cyborg that runs all day, every day, on a persistent machine, with customer-scoped memory that survives reboots, with per-action audit logging, with deterministic guardrail checks — the LangChain model is fundamentally mismatched.
The specific things we needed that required building our own runtime:
- Deterministic state persistence across arbitrary interruptions (reboot, crash, pause)
- Customer-scoped memory that never leaks across tenants
- Per-action audit log entries with structured payloads and unique IDs
- Kill switch that halts the workflow at the state machine level, not at the LLM call level
- Guardrail evaluation that runs as deterministic code, not as an LLM judgment
Building our own runtime was a significant investment. It's also, in our view, the only way to build something you can genuinely manage like an employee — which is the whole point.