The Console
https://incarna.io/consoleSign 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. No body selected, and the turn is ours.
When to use this instead of an integration
Use the Console 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 the moment the work is repeated, scheduled, or part of something you are building. The Console is one human at one keyboard; the MCP surface is the same capabilities, in the same organization, without that limit — and without a human needed to approve each post.
Whose bodies these are
Yours. The assistant runs as one shared runtime with one credential, but every turn carries a short-lived grant naming your organization, so the bodies it makes are the same bodies your API key lists over REST and MCP. There is one workspace, not a sandbox beside it.
Posts wait for you
The assistant cannot post. Ask it to, and it composes the text and stops, and the
post appears as a card in the conversation marked NEEDS APPROVAL, with Approve &
post, Edit and Discard. Nothing leaves until you press one.
This is enforced on our side, not asked of the model: the tool that publishes directly is refused for the assistant, and only an approved draft executes. An approval an agent can walk around is not an approval, and a card that only appears when the agent chooses to draw it would be exactly that.
Editing and approving are one step — what goes out is what is in the box when you press the button. Your own key is not gated this way: an agent you run is you acting, and it posts directly.
incarna.io/chat and incarna.io/demo are earlier addresses for this surface and
both land here.