Skip to content
Aghata

Computer mode

You can read the plan before it runs.

Hand Computer mode an outcome and its first act is a plan you can inspect — then it works the checklist with your connected tools and sandboxed code, pausing for your judgment on anything that matters, and delivers finished work to your Library.

Computer · running

The plan

The plan is a contract, not a vibe.

Before a single tool runs, the session writes a checklist you can read. Every item carries a live state — pending, in progress, done, blocked, skipped, cancelled — so 'how's it going?' has an exact answer at any moment.

It reports blocked, not busy

A step that needs you is marked blocked with the reason attached. The session doesn't spin, retry forever, or improvise around a missing decision — it holds the item and moves on where it can.

Steering without restarting

Type into a running session and your guidance lands on the next step. Answer a paused one and it resumes exactly where it stopped. Finished work takes follow-ups that keep the full history.

Every run keeps its origin

Sessions started from chat, email, a schedule, or a routine all carry a durable link back to what started them — and show their elapsed time and cost when they land.

Pauses

Three ways it stops. All of them on purpose.

Aghata never collapses 'needs attention' into one mystery state. A pause is typed — approval, input, or authentication — so you know exactly what's being asked of you before you open the session.

paused for approval

Consequences wait for a yes

Sends, purchases, deletions — anything irreversible stops at an approval card showing exactly what will happen. Reject it and the session re-plans; it doesn't sulk or sneak.

paused for input

Questions instead of guesses

Ambiguity parks the run with a concrete question. Your answer resumes it — hours or days later — from the same step, with the same files, at zero cost while it waits.

paused for authentication

Humans do the logging in

When a step needs credentials or a second factor only you have, the session hands over cleanly and waits — then picks the plan back up the moment you're done.

Mechanics

The numbers are published. The failure mode is a pause.

Most agents ask for trust. Computer mode publishes its mechanics instead — what it may spend, what needs your sign-off, and what happens at every limit.

Hard budgets. 24 model turns and 60 tool calls per session. Exhaustion parks the run with progress intact — never a silent failure, never a fabricated finish.

Four risk classes. Every tool call is classed read, write, external send, or destructive. Reads run free; the rest stop at one consistent approval primitive.

Sandboxed code. Computation runs in an isolated sandbox with durable files. Pause stops it, resume restarts it, and a served app gets a live preview link.

Everything lands in Library. Reports, datasets, images, downloads — every artifact a run produces is kept, attributed to its session, and citable by later work.

Zero idle compute. No resident agent loops in the background. Sessions sleep between steps and wake on your reply, a webhook, or a schedule — a run can wait a week for free.

Bounded delegation. A session can spawn sub-agents for parallel legs — at most three, one level deep. Fan-out is a design decision here, not an accident.

Questions

Questions before you hand it work.

How is this different from asking a chatbot?+

A chatbot answers in one breath. Computer mode opens an execution session: it writes a plan you can read, works through it with your connected tools and sandboxed code, pauses when your judgment matters, and delivers files — not just messages. Everything it produces lands in your Library.

What happens when the budget runs out?+

Every session runs under published limits — 24 model turns, 60 tool calls. If a run exhausts them, it parks with its progress intact and asks you how to continue. Exhaustion is a pause, never a silent failure or a made-up answer.

Can it send an email or delete something without me?+

No. Every tool call carries a risk class — read, write, external send, or destructive. Reads execute freely; everything else stops at an approval you can inspect before anything moves.

What does 'sandboxed code' mean in practice?+

When a task needs computation — parsing exports, crunching a spreadsheet, generating a chart — it writes and runs code in an isolated sandbox. Pausing a session stops the sandbox with its files intact; resuming restarts it. If the code serves something, you get a live preview link.

What if it gets stuck halfway?+

It tells you. A session that hits a wall pauses with a typed state — needs approval, needs input, or needs authentication — and your reply resumes it from exactly where it stopped. Long waits cost nothing: there is no idle agent burning compute between steps.

Chapters of one system

Give it the outcome. Keep the control.

Start free in the product, or talk to us about how your team would use it.