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.

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 session’s scratch machine is kept warm for a follow-up message rather than being torn down. Ara only discards the machine when the shutdown cannot be confirmed at all, or when it stopped answering long enough for Ara to give up waiting, so an unverifiable state is never reused. In practice a follow-up message sent right after a session resumes on that warm machine instead of paying a 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.