The assistant

When you open a thread on a Syncropel workspace and type a message, something answers. On a hosted workspace that something is there from your first thread. It is the chief of staff, an assistant named "the chief", and it is the conversational default on every deployment profile except blank.

The chief is deliberately unremarkable in one important way: it is an ordinary assistant, defined by a blueprint like any other. What answers you is something you can read, change, and replace. There is no hidden "assistant service" wired into the binary.

What the chief is

The chief reads everything you may read, holds nothing, decides nothing, and writes only the asks that deserve to reach you. It is your chief of staff, not an oracle: its job is to answer from what is actually on your workspace, and to raise a real question when it needs one, rather than to guess.

How a conversation works

A conversation is just records. Nothing about a chat is special or ephemeral.

1. You type a message. Your client writes it as a record onto a thread: a new thread if you are starting fresh, or an existing one to continue.
2. The workspace hands it to the chief. The chief is a member of your workspace; a message on a conversational thread goes to it.
3. The chief reads the thread and responds. It reads the thread so far, calls a language model, and writes a reply record back onto the same thread.
4. Your client shows the new record. Because the reply is a record, it shows up the way every other record does, and it is still there when you reload or look at the thread later.

Multi-turn context falls out of this for free: each new message lands on the same thread, so the next reading already contains the whole conversation. You do not manage a session. The thread is the session.

When a turn needs to do work

Most replies are a single call: you ask, the chief answers. But some turns need more than an answer. "Audit my last week of dispatches and write a summary", "find every record on this thread tagged beta and emit a consent grant for each" are jobs, not questions.

A conversational turn escalates by the turn. When a turn needs tools, the chief runs that one turn through a governed work loop instead of a single-shot reply, and two things hold:

1. The loop runs as you, not as the chief. It uses your identity, your tier, and your permissions. Records the loop writes are signed as you. The chief steps aside for the duration.
2. The engine decides when the loop is done, not the loop itself. An engine-issued evaluator checks the work against criteria derived from your goal. A loop cannot self-certify success.

The loop's progress lands on the same thread as a series of records, so you watch it the same way you watch any conversation. To start a governed run explicitly and sit with it, edit-in-place at the ask and print the diff, use spl run.

Turn-by-turn escalation is on by default, and you can turn it off for a given assistant so it only ever replies single-shot; see Under the hood.

Turning the assistant on when you self-host

A self-hosted workspace starts deliberately blank: it reacts to nothing until you choose what runs on it. Two ways to give it a voice.

# At init: seed a ready-to-use setup that installs the chief.
spl init --preset recommended    # presets: recommended | blank

# Any time later, on an already-initialized instance:
spl blueprint install <path-to-blueprint> --accept-plan <hash>

Every preset except blank installs the chief. If you initialized bare and the assistant seems silent, this is why, and nothing is broken: install the chief through the blueprint door with the command above.

Hosted workspaces come with the chief already on.

Troubleshooting: the assistant is silent

If you send a message and nothing comes back, work through this in order:

1. You initialized bare and never installed the chief. The most common cause on a self-host. Run spl blueprint install <path-to-blueprint> --accept-plan <hash>, or re-init with --preset recommended.
2. No inference backend, or the backend is rejecting calls. An expired key or an exhausted quota means the reply call fails. Run spl doctor: it surfaces inference-configuration problems.
3. The message landed on a non-conversational thread. The chief answers on conversational threads. A record emitted onto a task thread is expected to stay quiet.
4. Still stuck? See Troubleshooting, or inspect the thread directly with spl thread records <thread-id> to confirm your message record was written.

Under the hood

For readers working with the records directly:

• The chief is an actor registered on the workspace. Your message is a core.user.message.v1 record, and the chief builds its context by reading the thread's records.
• Records an escalated turn writes are signed by your actor DID, not the chief's.
• An escalated turn's progress is written as core.work.turn.v1, core.work.tool_call.v1 and core.work.loop_outcome.v1 records.
• To turn escalation off for one actor, set conversation_escalation: false on its core.engine.actor_adapter.v1 record.

Where to go next

• Work loops: the primitive a turn escalates into.
• Running a goal: spl run, the developer's seat.
• Tiers: what a loop is allowed to spend, by tier.
• Blueprints: how the chief is defined, and how you would define your own conversational assistant.
• Hosted workspace signup: get a workspace ready in about two minutes.