These definitions are the canonical source. If you see a term used differently anywhere in the product or marketing, that’s an error — let us know.
A timestamped, exportable record of every action a Cyborg takes — every read, write, decision, and escalation. Append-only, retained per your DPA settings. Can be exported to S3, GCS, or downloaded as JSON Lines. The audit log is the primary mechanism for human oversight of Cyborg activity.
A named digital employee with persistent identity, long-term memory, dedicated infrastructure, and a defined role. Not a session. Not a chatbot. Not a macro. A Cyborg has a name, a job description, credentials, a daily report cadence, and a kill switch. It works inside your real tools, on a real machine, every day.
The 5-step daily workflow every Cyborg runs: (1) Wake — start the working day, load context; (2) Plan — review the task queue, prioritize; (3) Execute — work on assigned tasks; (4) Report — send EOD report; (5) Learn — integrate feedback received since last cycle. The loop resets each working day.
A real Windows OS instance allocated exclusively to one Cyborg. Not a container slice. Not a shared thread. Not a serverless invocation. Each Cyborg runs on its own isolated, encrypted, customer-scoped virtual machine. No other Cyborg or customer shares that compute. This is what makes identity, file access, and credential isolation possible.
End-of-day report. Every Cyborg sends one at the end of each working day. Contents: what was completed (with links to artifacts), what was blocked and why, what decisions were made autonomously, any proactive flags or observations. Sent to the designated human manager via Slack, email, or the Aliens app. Not optional — it is the primary feedback surface between Cyborg and manager.
A single button in the customer admin console that immediately pauses the Cyborg, revokes all OAuth tokens across all connected tools, and freezes its machine in a non-destructive state. Mean time to halt: under 30 seconds. The Cyborg cannot override or resist the kill switch. It is always available to the account owner, regardless of the Cyborg’s current task state.
A pause point built into risky actions. Before a Cyborg takes a T3 action — such as running a database migration, sending an external-facing email, or modifying billing settings — it posts a structured plan and waits for explicit human approval before proceeding. Review gates cannot be disabled globally; they are configured per action type and trust level.
The role-specific skill module loaded on top of the base Cyborg runtime. A Role Pack contains: playbooks for common tasks in that function, tool integrations specific to the role, review rubrics, a daily report template, escalation thresholds, and voice/tone guidelines. A Software Engineer Role Pack is different from a Customer Support Role Pack. Customers can request custom Role Pack extensions.
OAuth access granted with the minimum permissions needed for the Cyborg’s role. Not full admin access. Not broad read-all. Specific scopes, explicit at grant time, visible to the customer at all times. Revocable from the customer’s own tool admin panel (GitHub, Slack, Notion, etc.) independently of the Aliens platform. Scoped OAuth is the primary access control mechanism for all Cyborg tool integrations.
TRUST LEVELS
The four levels of autonomy granted to a Cyborg, configurable per tool and per action type:
T1 — Cyborg ships autonomously. Human reviews output after the fact (async). Used for low-blast-radius, well-understood tasks.
T2 — Cyborg drafts, human reviews before delivery. Used for external-facing outputs (emails, posts) or changes to shared systems.
T3 — Human approves before action runs. Used for high-impact actions: database operations, billing changes, major deploys.
T4 — Cyborg never acts alone. All actions require explicit human initiation. Reserved for the highest-risk action types (irreversible system changes).
Trust levels are set by humans, per tool. Default on Day 1: T2 for most actions. Calibrated upward over time as review-pass-rate improves.
One customer’s Cyborg environment. Every customer is an isolated tenant. Data, memory, credentials, audit logs, and VM are all scoped per tenant. There is no cross-tenant data flow — ever. A Cyborg in Tenant A cannot read, write, or communicate with anything in Tenant B. Tenant isolation is enforced at the infrastructure level, not just at the application layer.
↳ Term missing? hello@anilcyborg.com — we update this glossary with every platform release.