# Talk & the Overseer

> Project and workspace assistants that understand the work, delegate it to threads, and report back without editing code themselves.

**Talk** and the **Overseer** are assistants for deciding what needs doing and keeping track of the result. Neither has a code sandbox, a repository to edit, or file and command tools. When a request calls for a build, they hand it to a project thread that can do the work. Their job is to see, decide, delegate, and report in plain language.

## Talk: one project

Open a project's **Talk** view to ask about its work. Talk can read that project's threads, plans, documents, Knowledgebase, settings, and usage. It can find out who started work, check what a thread actually finished, and report the outcome with a link to the thread. If you ask for a feature, Talk starts a work thread with a self-contained brief rather than pretending to build it in the conversation. That thread runs in its own sandbox; Talk does not.

For a project without a repository, Talk can start its first build. It reports what was built and checked before you decide whether to publish. Changes to unfinished work can go back to that thread; new work or changes to published work get a new thread. Questions and results come back to Talk.

Talk can start a plan's **Build** and use **Ship it** on a thread when you ask. On a project without a repository, publishing can create one first; if GitHub permission is needed, you get a **Connect GitHub** card. Talk can also create a separate project for an app that belongs elsewhere, but asks you before moving the request out of the current project. It does not change your personal account settings or delete projects. Read [Plans & Build](https://darting.dev/docs/plans-and-build/) and [Ship it & pull requests](https://darting.dev/docs/ship-it-and-pull-requests/) for those handoffs.

## The Overseer: your workspace

The **Overseer** is your personal assistant outside the team and project tree. It has the same no-sandbox shape as Talk, but its view spans the teams, projects, threads, and documents you can access. Ask it which work finished, what a thread cost, who prompted it, or how several projects are progressing. It can inspect a particular project's knowledge and settings without asking you to paste them into chat.

To get work done, the Overseer starts a thread in the project you name and can follow that thread's updates. It can also create projects from a GitHub URL or from scratch, create a repository for a project that has none, start a plan build, or ship a thread on request. It can read or change your supported profile and appearance settings, and project settings where your role allows it. It does not have tools to change your billing or global limits. See [Usage & limits](https://darting.dev/docs/usage-and-limits/) and [Roles & permissions](https://darting.dev/docs/roles-and-permissions/).

## Decisions stay with you

They check the thread or setting before claiming a result, then summarize it in plain language and link the underlying work. A background update is not permission to build or ship: tell them when you are ready.

An irreversible action such as deleting a thread or project **parks on an approval card**. The card names the target and consequence; you approve or deny it, and the assistant cannot answer its own card. Actions through connected accounts or vaulted credentials can likewise require a review card showing what would be sent before they run. The boundary is simple: the assistants can arrange work and explain its state, while consequential decisions remain yours. See [The vault & login browser](https://darting.dev/docs/vault-and-login-browser/) for credential approvals.