Connect a model, ask Chief to create Bots with distinct jobs, and put them in a group chat with an admin. Give the admin a specific deliverable and tell it when to involve the other Bots. Review their sources and final output yourself before publishing or sharing.
DS Bot's team is a set of named assistants that can use different models and keep their own memory. Group conversations provide a shared work area. The workflow below is an example to adapt, not a claim that these instructions have been tested on every version.
What should you prepare?
- A working DS Bot installation and at least one configured model. First confirm Chief can answer an ordinary message.
- A small, non-sensitive brief and a working folder containing only files the team needs. Review permissions before allowing file or shell access.
- A clear definition of done: format, audience, deadline if relevant, and who approves the result.
Every model call uses the connected provider's allowance. Multiple Bots, memory review and handoffs can produce more calls than a single chat. Use a small first task and watch Settings → Usage.
How do you create the team?
In Chief's own chat, adapt this request:
Create a small team for a beginner's guide to a software tool.
Create Researcher, Writer, and Editor Bots. Researcher collects primary-source facts and records links and dates. Writer turns approved facts into a concise draft. Editor checks accuracy, missing conditions, and clarity. Create a group chat with you as admin and add all three.
Before creating or changing anything, show me the proposed roles and ask for my approval. Do not publish, send messages, change external accounts, or use sensitive folders.
Review the proposed names, roles and model choices in the interface. Chief has broad team-management rights, so check any approval before accepting it. If your version presents a different creation flow, use the controls shown there. Assign models to individual Bots only after checking they are available under your provider account.
How do you run one task from brief to final draft?
- Give the group a bounded brief. Define the audience, deliverable and the facts that need evidence. Ask the admin to identify unknowns rather than invent answers.
- Have Researcher collect evidence. Ask for original page URLs, retrieval dates and a short note on what each source supports. A search result or a model's memory is not itself proof.
- Review the facts. Open the important pages yourself, especially for prices, versions and commands. Pass a checked fact sheet to Writer.
- Have Writer draft. Request a direct answer, steps, prerequisites and a failure check. Ask it to label any recommendation that is not backed by a source as an editorial suggestion.
- Have Editor challenge the draft. Ask it to identify unsupported claims, ambiguous steps and changes that would break the user's task. Check each correction against the source.
- Approve the final output. Only a person should decide whether it is ready to share or publish.
Who answers in a group chat?
The group admin normally answers first and brings in members when needed. You can also @ a member directly. For example, ask @Researcher to check a release note, then ask the admin to incorporate the result. Bot-to-Bot handoffs can run work independently and return the result to the group; inspect the returned evidence rather than treating a handoff as an automatic fact check.
How do you keep roles from overlapping?
| Role | Responsible for | Should hand off |
|---|---|---|
| Researcher | Finding and recording evidence | Finished fact sheet and open questions |
| Writer | Explaining the approved facts | Draft and any unsupported claims |
| Editor | Checking accuracy and reader usability | Specific corrections, not silent rewrites |
A useful role includes a boundary. For example, tell Researcher not to invent a source and tell Writer not to turn a suggestion into a claimed test result. If two Bots repeat the same work, ask the admin to assign one owner per deliverable.
How do memory and privacy affect the team?
A Bot's own memory, a group chat's memory and team memory have different scopes. Group memory is read by members in that group, while team memory is shared more broadly. Inspect what is saved and remove or correct entries when appropriate. A Private Bot cannot join a group; its privacy setting separates it from other Bots, but it is not an operating-system sandbox and does not stop an authorized model provider receiving the conversation.
How can you reduce cost without losing control?
Start with one Bot for simple work. Use a group when specialization changes the result, set a narrow scope, and ask the admin to call a member only for a defined task. Check usage by Bot and model after a trial. Token counts are not a bill; provider pricing or subscription rules decide the actual charge.
What is the difference between Chief, a group admin and a member?
Chief is the first Main Bot and can manage the team. A Main Bot can manage groups and change or delete Bots; a group admin manages that group's settings and members. Ordinary members can participate and hand work to other members. Before approving a change, read which Bot is acting and what it wants to change.
Current project documentation describes two reply modes. In admin-first, the admin responds and can invite another member. In all-members, members speak in order. A message mentioning multiple members can start their work in parallel. These are behaviors documented for the project's current code; check your installed version and group settings if the controls look different.
| Need | Practical choice | Check before running |
|---|---|---|
| One short answer | Ask one Bot directly | Selected model and task scope |
| A draft with a separate review | Use an admin-led group | Who owns each handoff |
| Independent perspectives | Ask named members in parallel | Potential concurrent calls and provider limits |
| Several stages with acceptance criteria | Consider a group Goal | Version support, the goal and evidence expected at each stage |
Example: prepare a weekly product update
Suppose a small product team wants a weekly update for customers. This is an illustrative workflow, not a reported test. Give the Bots three public release notes or other approved documents; do not give them private customer records unless the provider and permissions are appropriate.
Prepare a weekly product update for existing customers.
Inputs: the three documents I provide. Do not use other sources without asking.
Researcher: extract changes with the document title, date and supporting passage.
Writer: draft a 300-word update in plain English. Separate released features from plans.
Editor: flag unsupported claims, missing dates and any promise we cannot substantiate.
Chief: coordinate the work and give me the draft, evidence table and unresolved questions.
Do not post, email, change files outside the approved folder, or publish.
Start with the Researcher's table. A useful row contains the claim, its source, the date, and whether it is released or planned. If a release note says “available to selected accounts,” preserve that condition. Ask the Writer to draft only from the checked rows; ask the Editor to compare the draft back to them. An Editor Bot may catch an omission, but it is not independent evidence that the original source is accurate.
Acceptance test: select two claims at random, open their supporting documents and check the wording. Verify that every date and availability condition in the final draft is present in an approved source. If a claim cannot be traced, remove it or mark it as unresolved before sharing.
Example: use a personal assistant team for a coding task
For a small code change, separate the person who proposes a patch from the person checking it. Use a disposable test project or a backed-up repository and approve the working folder deliberately. You can ask Chief for a Programmer and Reviewer, then give the group a brief like this:
In the approved project folder, propose a fix for the failing form validation.
First inspect the existing behavior and explain the smallest change. Programmer: implement only after I approve the plan. Reviewer: inspect the diff for regressions and suggest an appropriate test. Run tests only if I approve the commands. Do not deploy, push, access credentials, or change unrelated files.
Ask for the error, the files changed and the test result separately. A proposed test that was not run should be labeled as such. Review the diff and any command before approval; a Bot's working folder and permission preset affect what it can do, and the exact protection depends on the runtime.
How do you write a useful handoff?
A handoff should contain the task, the input location, the output format and a stopping condition. “Review this” leaves the next Bot to guess. “Check these four claims against the linked release notes, list mismatches, and do not edit the draft” makes the output easier to inspect.
Task: Check the draft's four technical claims.
Input: The draft and evidence table in this group.
Output: For each claim, say supported, unsupported, or unclear; quote a short relevant passage and give its location.
Stop: Do not rewrite the draft or search outside the approved sources.
If another chat is relevant, the documented + → Reference a chat control can provide it as context. Review what you attach. A shared group is not automatically a view into every member's private chat.
How much model usage can a team create?
Measure a representative small task rather than guessing from the number of messages. Open Settings → Usage before and after, record the time range and the per-Bot and per-model counts, then compare with your provider's billing or allowance. Memory review and coordination may also use model calls; token counts in DS Bot are not a currency bill.
Illustrative calculation, not a measured run: suppose a provider charges $1 per million uncached input tokens and $2 per million output tokens. A task using 20,000 input and 5,000 output tokens would cost (20,000 ÷ 1,000,000 × $1) + (5,000 ÷ 1,000,000 × $2) = $0.03. Actual charges depend on your provider, model, cache, minimums and plan; replace the hypothetical rates and counts with your own. Subscription quotas may not convert directly to dollars.
What if the team produces repeated or conflicting answers?
- Several Bots repeat each other: check whether all-members mode is enabled; switch to a more selective workflow if your version supports it. Specify one owner per stage.
- A member does not answer: confirm it is in the group, use its exact name in the mention picker, and test it in its own chat. Inspect its selected model and connection if it cannot answer there either.
- Two Bots disagree: ask each for its source and assumptions. Compare the underlying evidence yourself rather than counting votes.
- The task grows beyond the brief: stop the run, restate the deliverable and limit additional handoffs. Review pending permissions before resuming.
- Work appears stuck: check whether the Bot is waiting for your answer, approval, a tool, or the model provider. Record the app version and exact symptom before retrying.
A group Goal is useful only if the objective and stage checks are clear. If your release handles Goals differently, use a normal group message and a manual stage-by-stage review. Do not treat an unfinished or blocked stage as complete.
See the DeepSeek Bot introduction for the team model and the guides library for more agent setup references.