Run your first company.

Four ideas explain almost everything Aria does. Hold these and the rest of the docs read easily.

• The company

  Your top-level workspace. One goal in, an org of agents coordinating toward it, one live product out. You are its only human.

• Specialists

  Role-shaped agents — planning, frontend, backend, data, QA, ops — that pick up tracks and work in parallel, handing results to each other.

• Shared memory

  A common context every specialist reads and writes: the goal, decisions, conventions, and what each other has done. No re-explaining.

• Sandboxes

  Each run executes in an isolated cloud workspace with your repo and tools — never on your machine, never sharing state with anyone else.

When you set a goal, the company creates a plan and assigns tracks to specialists. They coordinate through shared memory so the frontend agent knows the API the backend agent just defined, and the QA agent knows what to verify. Every bit of execution happens inside a sandbox — a clean, isolated environment that holds only what this run needs.

The company is only as good as the goal you give it. You don’t need a spec — you need a clear outcome, the constraints that matter, and a way to know it worked.

A strong goal names what should exist, not how to build it. Leave the “how” to the specialists. Add constraints only where they’re real — a deadline, a stack you must stay on, a compliance rule — and say how you’ll judge success.

A quick checklist before you hit run:

• State the outcome as something a user could see or use.
• Name only the constraints that are non-negotiable (stack, deadline, brand, compliance).
• Give a success test — a URL that loads, a flow that passes, a metric that moves.
• Point it at the right repo, or ask for a fresh one.

Aria works the way your team already does: on a branch, through a pull request, with a clean diff you can read. Nothing lands on main without your say.

Connect a GitHub repository once. For each goal, the company checks out the code into a sandbox, works on a fresh branch, and opens a pull request with the changes plus a written summary of what it did and why. You review it like any other PR.

Prefer to start clean? Ask for a new repository and the company will scaffold it, commit the first working version, and hand you the URL. Either way you keep full ownership and history.

# grant access to one repo (least privilege)aria repo connect github.com/acme/launch ✓ connected · branch protection respected✓ company will open PRs, never push to main

• Readable diffs

  Small, scoped commits with conventional messages — not one giant unreviewable blob.

• PR summaries

  Every PR explains the change, the trade-offs, and how it was verified, in plain language.

Your company doesn’t live in a vacuum. Connect the services it needs — databases, deploy targets, queues, payments — and the specialists use them as first-class tools.

Adapters are how Aria talks to the outside world. Most common services have a managed adapter you enable with a click and a scoped credential. For anything custom, point the company at an API and it wires up a no-code adapter from the docs.

• Managed adapters

  Databases, hosting, object storage, email, payments — enable, authorize once, and the company uses them safely.

• No-code adapters

  Have an internal or niche API? Give Aria the endpoint and auth; it builds the adapter and tests it before relying on it.

• Scoped credentials

  Every connection is least-privilege and revocable. Credentials live in the vault, never in code or logs.

• Tool discovery

  Specialists pick the right adapter for the job automatically — you don't assign tools by hand.

# connect a Postgres database (scoped, revocable)aria adapter add postgres \  --url "$DATABASE_URL" \  --scope read-write ✓ stored in vault · never written to logs✓ available to data + backend specialists

Shipping is the start, not the finish. Once a product is live, the company keeps watching it — and when something breaks, it tries to fix itself before you ever see an alert.

Aria watches uptime, errors, and the health checks it wrote for your product. When a check goes red, a specialist picks up the incident, diagnoses it in a sandbox, and either applies a fix through a PR or rolls back to the last green state — then tells you what happened.

03:11  health: error rate 4.2% on /api/referral03:11  ops: opening incident · isolating cause03:12  fix: null-guard added · reproduced + verified03:13  deploy: patch live · error rate 0.0%03:13  notify: resolved before page · summary sent

• Always-on checks

  Uptime, latency, and the product-specific health checks the company wrote during the build.

• Diagnose in a sandbox

  Incidents are reproduced safely in isolation — never by poking production blindly.

• Fix or roll back

  A scoped patch through a PR, or an instant rollback to the last green deploy — whichever is safer.

• You stay informed

  Plain-language summaries of what broke, what fixed it, and what to watch — no log spelunking.

Every run is isolated by construction. Your code, your credentials, and your data never share a workspace with anyone else’s — and never touch your local machine.

Each goal executes in a dedicated sandbox with its own filesystem, network boundary, and short-lived credentials. When the run ends, the sandbox is torn down. Secrets live in a vault, are injected only into the run that needs them, and are never written to code, logs, or shared memory.

• Per-run isolation

  A fresh, single-tenant sandbox per goal — no shared state between runs, projects, or customers.

• Vaulted secrets

  Credentials are encrypted at rest, injected just-in-time, scoped to the run, and redacted from every log.

• Least privilege

  Adapters and repo access are granted narrowly and are revocable in one click at any time.

• Auditable actions

  Everything the company does lands as a reviewable PR, deploy log, or summary — nothing happens off the record.

The questions we hear most, and the fastest way to unblock a run.