DOCS · CHAT
The chat that executes.
Chat is the primary surface in SynthOS. You say what you want in plain language; it chooses the tools, dispatches the agents, and does the work — showing every step as a card you can read. The point of this surface is that it does the job rather than handing the job back to you as instructions. This page covers how to phrase an ask, how to read a run as it happens, when it checks in with you, how voice fits in, how the work files into your vault, and how to stop or redirect a run already in flight.
Honest framing up front: chat does the work, but it is not magic and it is not silent. Every tool call and every agent step appears as a card while it happens. Nothing runs hidden, and anything risky waits for you before it proceeds.
HOW CHAT WORKS
Ask in words. It does the work.
You type — or speak — a job the way you’d describe it to a capable assistant. There is no command syntax to learn and no prompt ritual to perform.
YOU ASK
State the outcome
Describe what you want to be true when the work is done, in plain language. “Pull this week’s open invoices and draft a follow-up for each” is a complete ask. You do not need to name the tools or spell out the steps — that’s the part SynthOS handles.
IT PLANS
It picks the tools
SynthOS reads the ask, decides which tools the job needs — the command-line, the browser, your files, reading from the vault — and works out the order. When a job is large enough, it splits the work across more than one agent so independent pieces run in parallel rather than one after another.
IT RUNS
It does it, on the record
Each tool call becomes a live step card the moment it starts. You watch the command, the page, or the file edit happen — and the result lands in the same card. When the run finishes, you have the outcome and a readable trail of how it got there, not a wall of instructions to carry out yourself.
The dispatch is not a black box you have to trust. The plan is visible as it executes, the tool choices are shown by the cards themselves, and any step that could change something outside a safe read checks in with you first (see Check-ins, below).
WRITING A GOOD ASK
Clarity beats prompt tricks.
You don’t need a clever prompt. You need to say clearly what “done” looks like, and to hand over the context only you have.
Lead with the result you want, not the steps. “Get the three competitor prices into a table I can paste into the deck” tells SynthOS what success is. It will choose the steps; you keep the goal honest.
Give it the things it cannot guess — which account, which folder, which tone, what to avoid. Context you already keep in your vault is available to it, so a note that says “our pricing lives in Pricing.md” saves you repeating yourself in every ask.
Say the boundaries out loud: “don’t send anything,” “stop and show me before you publish,” “only read, never edit.” Stated constraints are honored as the run proceeds and shape where it pauses to check with you.
Bound the size when it matters — “just this week,” “the top five,” “the README only.” A scoped ask runs faster and is easier to read as a sequence of cards. You can always widen it in a follow-up message.
If an ask is ambiguous, SynthOS will tell you what it’s about to do — or ask — rather than guess at something irreversible. A short, clear ask plus a quick correction beats a long, over-engineered prompt.
READING THE LIVE RUN
Step cards, not a black box.
A run is a stream of cards. Each card is one concrete thing the work did or is doing right now. Reading the run is reading the cards top to bottom.
One action: a command run in the terminal, a page opened in the browser, a file read or written, an agent dispatched. The card names the tool and shows what it acted on.
The output of that step — the command’s output, the text pulled from a page, the diff of a file edit. The result is attached to the same card, so cause and effect sit together instead of scrolling apart.
A step that is running now reads as active until it completes. When several agents work in parallel, you’ll see more than one card live at once — that’s the parallelism made visible, not a glitch.
A step that needs your call before it goes further. The run holds here and checks in with you (see below) rather than pushing past a decision that’s yours to make.
The cards are the record. There is no separate “trust me” summary standing in for the work — the summary, when there is one, is built from steps you can scroll back to and re-read. If a step did something on disk or on the web, the card that did it is still there afterward.
CHECK-INS IN CHAT
It checks in before the risky part.
Reading is free; consequences aren’t. When a step would do something it can’t quietly undo, the agent is instructed to stop and ask you first — in the same chat, on the same card. Being straight about it: that is behaviour the agent performs, not a gate the app enforces on every tool, and you can make it a hard rule for specific tools in your own guardrails file.
When it checks in. Anything that reaches outside a safe read — sending a message, publishing, deleting, spending, changing a setting, running a command that mutates state — is what a check-in is for. Pure reading, searching, and drafting generally flow without interruption.
What you see. The check-in card states what it’s about to do, in plain terms, before it does it — which action, on what, with what effect. You’re approving a specific step, not signing a blanket permission.
How you respond. Approve and the step runs. Decline and it’s skipped — the run continues with the rest, or stops if that step was load-bearing. You can also just reply in the chat to redirect: “not that account, the other one” re-steers the work without starting over.
Why it’s not an upsell. Check-ins are part of how SynthOS works on every plan. The pause before a risky action is the product behaving correctly — never a gate you pay to remove.
TALKING TO IT OUT LOUD
Voice is just another way to ask.
You can speak your ask instead of typing it. Voice input feeds the same chat — it doesn’t change what runs or how the run is shown.
How it works. Start voice input, say the ask the way you’d say it to a person, and it becomes the message in the chat. From there the run is identical to a typed ask: the same tool choices, the same step cards, the same check-ins.
When it helps. Voice is good for longer, describe-the-whole-thing asks where talking is faster than typing, and for working hands-busy. It does not skip check-ins or run anything silently — a spoken ask is still read back to you as the message it became, and risky steps still wait.
You stay in text afterward. Whatever you said lands as editable chat text, so you can fix a misheard word or tighten the ask before the work goes further.
PROJECTS AND CONTINUITY
Each conversation files into your vault.
Chat isn’t a throwaway window. The work a conversation produces files into your knowledge vault and links into the graph, so the next ask starts from what the last one learned.
IT FILES
Work becomes notes you own
What a conversation produces — the drafts, the findings, the records of what ran — files into your Obsidian-compatible vault as plain markdown on your own disk. It’s yours to open, edit, and keep whether or not SynthOS is running.
IT LINKS
Notes wire into the graph
New notes auto-link to the ones they relate to, so the vault grows into a connected graph rather than a pile of files. A conversation about a client connects to everything else you already know about that client.
IT CARRIES OVER
The next ask starts ahead
Because the work is in the vault, the next conversation can draw on it instead of starting cold. Context compounds across conversations rather than resetting every session — the more you do, the more the chat already knows.
For the full picture of how the vault and graph work, see the docs hub. This section covers only what chat contributes to them.
How the vault and graph work →STOP OR RE-STEER
You can stop a run mid-flight.
A run in progress is never out of your hands. You can halt it, or nudge it onto a better path, without waiting for it to finish or starting the whole thing over.
Stopping a run. Stop the run you are watching and the work halts — the in-progress steps wind down and nothing new is dispatched. Because each step was shown as a card, you can see exactly where it stopped and what it had already done up to that point. Stopping is scoped to that run; there is no one control that halts every agent at once.
Re-steering. You don’t have to stop to correct course. Send a message while the run is going — “skip the third one,” “use the staging account, not production” — and the work adjusts from there rather than redoing what already landed.
You can see what it did. Every step is a card as it happens, so a stop or a redirect is something you make on what you can actually read rather than on a guess. What completed before you stepped in is already filed in your vault, on the record.
NEXT
See the chat run.
The fastest way to understand the chat is to watch it work. Run it on your own Mac, or read the rest of the docs.
From $19/mo · Bring your own key · Private cloud sync · Cancel anytime.