# The Playground

```
https://incarna.io/playground
```

Sign in and tell an agent what to do. No key, no config, no client to install. It
operates real bodies through the same MCP surface your own agent would use, and the
right-hand column shows you what actually happened rather than what it says
happened.

This is the fastest way to find out whether Incarna does the thing you need. It is
also the only way to use it without writing any integration at all.

## Three columns

**Left — bodies and history.** Every body in the workspace, with its region, how many
accounts it holds, and a dot for whether it is `ready`. Below them, past
conversations. A conversation is created when you first say something, not when the
page loads, so a visit that goes nowhere leaves nothing behind.

**Middle — the turn.** What you asked, what the agent said, and every tool call it
made, in order, as it makes them. Calls that *change* something are marked; reads are
not. That distinction is the only thing coloured on the page, because it is the only
one worth glancing at.

Below the box, **acting as** picks which body the instruction is aimed at. Pick one
rather than naming it in the sentence. An id has no failure mode; a name the model
has to go and look up does, and it got it wrong — it read the wrong row and reported
an inbox that was not there.

**Right — the body itself, read back from the API.**

| | |
|---|---|
| IDENTITY | Where it comes from, its fingerprint, its device. Marked `LOCKED`, because it is. |
| ECONOMY | Its wallet address, USDC balance, and what it has authorised today against its cap. `Deposit` shows the address; nothing on this page moves money. |
| ACCOUNTS | What it holds, linked out to the platform, with the inbox if it has one. |
| LOGS | What was done to this body, newest first. |

The log is the point of the column. A transcript is what the agent *said* it did; the
log is what the system recorded happening. They can differ, and a product whose whole
claim is that these accounts belong to somebody has to show you the version that is
not the agent's own account of itself.

## Openers

Five chips sit under the box. None of them sends anything — an action that leaves
your systems is a decision, not a button, and the agent is instructed to show you the
whole draft and wait for a yes.

| Chip | What it starts |
|---|---|
| new body | Asks what it should be called and where it should live, proposes a handle and an inbox, waits for you |
| bind account | Lists what can be bound here, starts a connection, hands you the authorize link |
| read inbox | Reads the selected body's mail, or offers to attach an inbox if it has none |
| send email | Drafts, shows you the draft, sends only on your yes |
| publish page | Publishes `incarna.io/@handle` — and tells you what becomes crawlable first |

The chips that need a body open the picker instead of making the agent ask you back.

## Which model is thinking

The header picks the provider and, inside it, the model — ninety of them, grouped by
vendor, with per-million-token prices next to each. The choice is stored per turn,
not per conversation, because switching mid-conversation is the normal way to use
this and "which model answered me" is a fact about the turn.

Two providers today: the deployment's own default, billed to Incarna; and
**BlockRun**, quoted per call in USDC on Base. Pick BlockRun with a body selected and
the body pays for its own thinking, out of its own wallet, against a per-call ceiling
— see [Wallets](wallet.md). No body selected, and the turn is ours.

## When to use this instead of an integration

**Use the Playground** to see the product work before committing to it; to make and
inspect a body by hand; to walk somebody through what a body *is* without asking them
to install anything; and to check what a body has actually done, which the log shows
better than any API response.

**Use [your own agent](clients.md)** the moment the work is repeated, scheduled, or
part of something you are building. The Playground is one human at one keyboard. The
MCP surface is the same capabilities without that limit — and it runs in *your*
organization, which the Playground does not.

## What it does not do yet

The Playground's assistant runs with its own credential, so it acts in the
organization that credential belongs to — not yours. Bodies you make here are real,
and everything the panel shows about them is real, but they are **not** the bodies
your API key lists over REST or MCP. Driving the Playground with your own key is not
built.

Plan accordingly: the Playground is for seeing and for trying. Anything you intend to
keep, make through your own key.

`incarna.io/chat` and `incarna.io/demo` are earlier addresses for this surface and
both land here.