Chats & Diamonds

A chat is a conversation with the daimon. A Diamond is a durable container for a pursuit, holding what you have worked out about a piece of work so that later work starts from it. Here: starting and reading chats, the turn controls, folding a chat into a Diamond, the workspace a Diamond works in, attaching files to either, and organising what you accumulate.

Starting and returning to a chat

Choose New chat, the ＋ beside Chats in the rail. Type in the box at the bottom of the centre panel and send with ➤. Every chat you start is listed under Chats, newest first; click one to bring it back to the centre. A new chat starts on your default model, and the selector in its header changes the model for that chat alone.

A chat tile carries a ×, and the ⋯ on the Chats head carries Delete all chats. Neither asks: both move chats to the Trash, where they can be brought back. The questions have moved to the two acts that cannot be undone, which are both in that panel.

While an answer is arriving you can keep typing. A message sent then is queued rather than lost: it appears under the thread as a dashed bubble and goes as its own turn the moment the answer finishes. Click a queued bubble to take it back into the box and change it, or its × to drop it. Pressing ■ to stop the answer hands anything queued behind it back to you, unsent. Stopping means stopping.

Reading a long conversation

A conversation grows quickly, so the chat header carries controls to keep it readable, at the top-right of the centre panel. Two more sit in the composer bar beside ➤.

Folding a chat into a Diamond

When a conversation has worked something out, you fold it: keep what you learnt, drop the back-and-forth that produced it. What you fold into is a Diamond, and two units make it up:

• A fold is one improvement, a single step forward.
• A crystal is what the folds have accumulated: the shape of the work, the steps in their order, and the checks you found the hard way. A Diamond is a crystal together with the chain of folds that produced it.

Selecting turns and folding them

Collapse the thread with −, then pick the turns worth keeping. A row of controls appears in the header: Select all, Deselect all and Fold selected, which folds the chosen turns into the Diamond. Fold a step you have adopted and not a passing remark: folding keeps what you learnt, not the transcript.

Working a Diamond

Diamonds are listed above your chats in the rail; add one with the ＋ beside Diamonds. Selecting one replaces the chat in the centre with its command surface, a compact view where you steer the work and fold further improvements into it. You can tell which face the panel is showing without reading it: on a Diamond it takes the Daimond mark beside the name and squares its corners, against the rounded corners of everything else on screen.

A Diamond has two faces, and a switch in the header moves between them. Crystal is what the Diamond knows. Chat is its own conversation, which persists like any other and carries a Fold button, because folding is done mid-flow rather than while configuring something. Pick a chat in the rail and the ordinary conversation returns, as it does whenever the stage would otherwise be empty.

What a Diamond does, and what it does not

A Diamond retains; on its own it does not run. Nothing executes a crystal: there is no workflow engine and no chain from one Diamond to another. Returning to a Diamond does not set it going, and neither does leaving it alone. A Diamond you have not automated answers when you prompt it and at no other time — which is what its panel says when you look: Nothing set. This Diamond answers when you prompt it and at no other time.

So picking it up again means steering it again with everything it has learnt already in hand. The crystal is prose, which is what a model reads best, and it is handed to the daimon when you work the Diamond and to every worker dispatched from it. What you worked out once reaches the work again without you retyping it, or remembering that you should.

The one way a Diamond acts without you is the one you set up yourself, described next.

Triggered actions

A triggered action is a standing arrangement for a Diamond to do something without being asked. You write it, you switch it on, and from then on the Diamond acts when the thing you named happens. It is the only part of Daimond that spends money with nobody at the keyboard, so it is worth reading this section before you set one.

They live under When this Diamond acts on a Diamond's crystal. Add an action makes one; a pulldown selects it for editing when there is more than one. Two things can set an action off:

• Minutes of my activity. A timer that only counts while you are actually working. A tab left open overnight counts none of them, so a Diamond set to thirty minutes fires after half an hour of your work, not half an hour of wall clock.
• Mail arriving. Mail landing in a folder you name, in a mailbox you have already set up. Nothing fires until there is mail.

Each action carries two pieces of writing. The instruction is what the Diamond is asked to do when it fires, and it is sent every time. The context is background it needs the first time only: it goes in front of the first instruction and then stops going, until you change it, at which point it is sent once more. That is what changing it means.

Actions are ordinary files. They sit in the Diamond's own directory as triggers.json, in the open, where you can read them in the Workspace panel and where the Diamond itself can read and edit them with the file tools it already has. Nothing about them is hidden from you or from it.

The play, the pause and the light

Every triggered action wears the same three-part control the rest of the app uses: a play, a pause and a round light. The Diamond carries one that speaks for all of its actions, and the Everything row at the top of the rail carries one that speaks for the whole app.

The light says whether anything is going to happen on its own. Not whether you have pressed pause — whether something is actually armed and free to fire:

• Red. Nothing here will act by itself — because you have set nothing up, or because what is here is switched off, held, or missing something it cannot fire without.
• Amber. Some of what is set up will act, and some is held.
• Green. Everything that is set up will act.

A Diamond you have not automated therefore shows red, and so does the Everything row on a fresh account. That is not a warning. It is the honest answer to "is anything running by itself?", and on a new account the answer is no.

The two buttons follow the light, so you never have to work out which one would do something:

• Red: play is live and pause is greyed. There is nothing running to stop.
• Amber: both are live. You can release what is held or hold the rest.
• Green: pause is live and play is greyed. There is nothing held to release.

Pressing pause on a Diamond holds every action under it; pressing it on the Everything row holds the lot. Nothing is spent by a held action — it is refused before the turn starts, so a pause costs nothing but the wait. Amber can only be arrived at, never set: there is no button that makes a light amber, which is what stops the colour from meaning whatever somebody last clicked.

The same light rides on your mailboxes, and it reads the same way. A mailbox whose folders you refresh by hand is red: pressing refresh yourself is not automation, it is you. Give a folder an interval and it goes green.

The crystal and its history

The crystal is two real files in the Diamond's own directory: crystal.json, what the Diamond knows, and crystal.html, the page that draws it. That directory is always in the Diamond's workspace, so both can be opened in the Workspace panel, read, and edited by hand. It is not inside the folder you have open as your workspace, though: a Diamond is kept in the browser's own storage, apart from your work.

Every write snapshots a version, so a crystal has a history and nothing is written over. The history lists every version, newest first, each with what produced it:

• View: read that version.
• Restore: make that version current again.
• Delta: see the raw input a fold consumed, the material the agent was given to reduce.

Artefacts

A Diamond also keeps track of what its work touched: the files written and the pages opened while you were working on it. None of it is yours to record. Daimond already notes every tool an agent uses, so the list is read off what happened, and gathered at the moment you accept a fold.

Files that were only read are left out on purpose. An agent may open forty files looking for one thing, and all forty listed would bury the one that mattered. What is kept is what the work produced, and the pages you asked to see.

When a Diamond has any, a line above the steer box says how many. Clicking it opens the list, where each entry does three things:

• The name opens it: a file in the Doc panel, a page in the Web panel.
• The small arrow puts a reference to it in the steer box, so you can say "redo the figures in this one" without typing out the path.
• The cross removes it, if it does not belong to this Diamond after all.

The workspace of a Diamond

A Diamond has a workspace: the files and folders you keep with it. You put them there. A daimon cannot add to its own workspace, so it works with what it has been given and asks you when it needs more.

It is a view of your files, not a box holding them. Nothing is copied when you attach something: the file stays where it is and the Diamond points at it. Attach the same folder to two Diamonds and there is still one folder, and an edit made through either is the file the other reads. Taking something out of a Diamond's workspace only detaches it; the file itself is untouched, and only a deliberate delete removes it. The word workspace invites you to expect a copy, and there is none.

A Diamond also has a directory of its own, always in its workspace and always writable, so its daimon has somewhere to work before you have attached anything; the crystal lives there. A folder can be attached to be consulted rather than edited, which lets a daimon read it and refuses every write. And the Workspace panel shows either all your files or only the ones this Diamond holds, whichever suits the work in front of you.

Attaching, with the paperclip

The 📎 on every row of the Workspace panel (on files as much as folders) and in the Doc panel's header reads Attach to current focus. One control, whose effect follows what is in focus and not which row it sits on. With nothing in focus it is not offered at all.

• A Diamond is in focus. The file or folder joins that Diamond's workspace and stays until you take it off. Its daimon may then open it.
• An ordinary chat is in focus. The attachment is for the next turn only, shown in a footer above the box that clears when the turn is sent.

Each attachment carries one of two states, toggled on its tile. Note says the path is worth knowing about, and costs a few tokens. Read says the contents are wanted now, and a file can run to thousands. Note is where an attachment starts, being much the cheaper: a default that spends your money unasked would be the wrong one.

Either way the text it generates (Note …, or Read … in full.) is written into the box in front of your message, to edit or delete before sending. A prompt the app writes and hides is a prompt nobody can argue with.

The footer carries a + for attaching several things without leaving what you are reading, and a toggle between the tile Stack and rows of larger Icons. Past six tiles (four when the window is short) it scrolls instead of growing, so the composer stays put. An attachment made in a workspace that is not the open one says where it lives rather than reading as an empty folder, and is left out of the generated text: a path a model cannot open buys a turn spent apologising.

What a daimon can open

A daimon can only open the files in its Diamond's workspace. Nothing outside it is readable or writable, by the daimon or by any worker it dispatches. This is no instruction in a prompt that a model may or may not honour: the check sits in the compiled code, at the one door every file tool passes through, and that code is in the published bundle, which is built reproducibly. So it is a claim you can check and not one to take on trust.

What it does not cover belongs in the same breath. It settles what a daimon can reach, not where what it reads ends up: whatever it opens goes to your model provider with the rest of the turn. It does guard against an agent that has been talked into something: a turn that has just read a stranger's instructions in a page or an email, and gone looking on their behalf, still reaches nothing outside this workspace. It is no guard against a provider misusing what you send it, or a build that is not the one we published; those are answered by what leaves the browser and the sealed record of every build.

Dispatching workers

Some tasks want work done and not merely recorded. For those the Diamond's daimon dispatches a worker agent. Each worker runs in its own context with the workspace file tools, and is given the standing instructions and this Diamond's crystal. That crystal is the whole of what it knows about your pursuit: a worker cannot see your conversation, so the task it is handed must say everything else it needs.

Up to eight workers run at once; the rest queue. The daimon dispatches them and its turn ends there, without receiving their output. Each reports a summary, and you fold the ones worth keeping in by hand, which is what keeps the choice of what enters a crystal yours. Live runs appear in the Agents panel in the dock.

Holding and stopping agents

The Agents panel header carries three controls that act on every agent at once, and the same three ride on each tile so you can act on one:

• Pause ⏸: hang up what is running and hold the queue. A running agent keeps what it had produced; a waiting one does not start. Nothing new launches until you resume. This is the brake for a fan-out spending faster than you meant.
• Resume ▶: continue every paused agent from where it left off, picking up its own work instead of starting over, so a pause costs nothing but the wait.
• Stop ✕: end agents outright. Each keeps what it managed to do, as a stopped tile; Clear finished agents removes them. The instant kill switch.

Each tile shows its cost as it runs, the tokens and dollars accruing live rather than only at the end, so you can see the spend while deciding whether to hold it. Under the header a line reads how many agents are running, paused and queued, which makes the size and the cost of a fan-out legible at a glance. The measures Daimond takes on its own are on the Spending page.

A wider brake sits on the Everything row at the top of the rail. It pauses and resumes all of it at once: every Diamond, every chat, the workers, the mailboxes and any page being fetched for you. A paused thing refuses a turn before it starts, so nothing is spent.

Two limits hold. A worker cannot dispatch another worker, so delegation goes one level and stops. And one Diamond is steered at a time, so no second Diamond works away while your back is turned.

Tags

Diamonds accumulate, so they can be tagged. A tag is a short label you choose, edited from Tags on a Diamond's crystal. Four are suggested to start from (person, project, topic and org), but Daimond imposes no taxonomy, and you can type whatever suits your work.

What you type is tidied: a tag is lowercased, trimmed and deduplicated, with up to 8 tags on a Diamond and 24 characters in each. Tags are stored in the Diamond's own meta, on this device, like everything else.

The editor shows two boxes: the tags on this Diamond, and all your tags underneath. The × on a chip in the upper box takes that tag off this Diamond and returns it to the pool below, where one click puts it back. The × in the lower box is a different act: it deletes the tag itself, from every Diamond filed under it. That one asks first, and says how many Diamonds it will change. The four starter suggestions carry no ×, being always offered.

In the rail, Filter by tag opens the tags you can narrow by, with the count of them on the button. Click a tag to show only Diamonds carrying it; click it again to hide them instead. With more than one chosen, All and Any decide how they combine, and Clear empties the filter. There is no separate search box: a Diamond is found by what it is filed under, and two ways of narrowing one short list is one more than it needs. The list is ordered by most recently touched, so what you last worked on sits at the top.

The Trash

Deleting a chat or a Diamond does not destroy it. It is trashed: still stored, still synced, out of the rail, out of the graph and the tag filter, and out of every daimon's reach, listed in the Trash panel in the dock with a Restore button beside it. It is kept thirty days and then destroyed, and each row says the date.

Because the act can be taken back, nothing asks before it. The two questions live where they are true instead: Delete permanently on one item, and Empty trash, which names the count. Both are irreversible and both go from every device. A dialog in front of a reversible act teaches people to click through dialogs, and then the irreversible one is clicked through too.