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 pauses for approval, 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 pauses for your approval first (see Approvals, 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 surfaces an approval (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.
APPROVALS IN CHAT
It pauses before the risky part.
Reading is free; consequences aren’t. When a step would do something it can’t quietly undo, the run stops and asks you first — in the same chat, on the same card.
When it pauses. Anything that reaches outside a safe read — sending a message, publishing, deleting, spending, changing a setting, running a command that mutates state — can trigger an approval. Pure reading, searching, and drafting generally flow without interruption.
What you see. The approval 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. Approvals 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 approvals.
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 approvals 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.
The kill-switch. Stop the run 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.
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.
Nothing is silently irreversible. The steps that could matter most are exactly the ones that paused for your approval first, so a stop or a redirect catches a run before a consequential action, not after it. 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 $29/mo · Bring your own key · Local-first · Cancel anytime.