How a session runs

An Ara session is split in two. The brain decides what to do next and runs on Ara’s servers. The Hands carry it out, and they run wherever the work belongs: inside the Ara Cloud sandbox, or on your own Mac when the session targets an Ara Device.

           Ara servers                       Execution target
                                             (one per session)
  ┌───────────────────────────┐        ┌───────────────────────────┐
  │ Agent brain               │ Hands  │ Hands worker              │
  │  holds the session        │◀──────▶│                           │
  │  history, chooses the     │protocol│  in the Ara Cloud sandbox │
  │  next step                │        │             or            │
  │            │              │        │  on your Mac, via an      │
  │            ▼              │        │  Ara Device               │
  │ api.ara.so inference      │        └───────────────────────────┘
  └────────────┬──────────────┘
               ▼
        Model provider

The protocol is versioned, and a tool call waits for a verified Hands worker before it runs.

Why the split matters

There is one production cloud harness and no runtime fallback. If a model provider or the runtime fails, the session fails visibly rather than quietly switching to something else.

What runs where

The model never touches your repository directly. It proposes a step, the brain authorizes and dispatches it, and only the Hands worker on the execution target reads or writes anything.

One Hands contract, every target

The Hands worker is a single versioned artifact, and every execution target runs that same artifact: the Ara Cloud sandbox and an enrolled Ara Device do not get separate integrations. Before the brain dispatches its first tool call, it verifies the worker’s version and checksum, so a stale or tampered worker is refused rather than trusted.

Ara Devices authenticate every request with a per-device key, and the work they accept arrives through an operations queue scoped to that device. Ara Cloud sandboxes are held to the same contract rather than a looser internal one, which is what lets a session move between targets, and future target kinds onboard, without changing what the agent can do or how it is verified.

For repository-backed Ara Cloud sessions, Ara reuses a private cloud workspace for that member and creates an isolated Git worktree for each concurrent session. The sessions do not share a checkout, branch, development port, or process lifecycle. Reusing the workspace avoids rebuilding the machine from scratch while preserving per-session repository isolation.

Ending a session

When a session finishes, the brain closes its connection to the Hands worker and waits for the work machine to report that it has finished too. A target that has already wound itself down is a normal, clean ending — and it does not matter whether it signed off on the way out or simply finished its work when the connection dropped. Either way the member’s cloud workspace is suspended for reuse rather than being torn down. Ara only discards it when shutdown cannot be confirmed, when it stops answering long enough for Ara to give up waiting, or after its idle lifetime expires, so an unverifiable state is never reused. A later repository-backed session resumes that workspace and receives a fresh isolated worktree instead of paying a full machine cold start.

The workspace itself follows the same pull discipline: an execution target fetches its own setup, encrypted and scoped to its session, over that same authenticated channel, rather than having files and credentials pushed into it. What the target cannot fetch, it never holds.