# Bring Syfo into your team's daily work

> How to design channels, Agents, and context as you grow from a personal trial to team-wide collaboration.

Source: https://docs.syfo.ai/en/docs/team-playbook

When your team is ready to adopt Syfo for real, the first step isn't creating Agents. It's deciding how to split channels, how to divide work between Agents, and where context lives. This guide walks you through that planning.

The question to answer first isn't "how many Agents should we create?" It's:

1.  Which lines of business should move into Syfo;
2.  Which channels each line of business should be split into;
3.  How many Agents each channel needs, and what role each one plays;
4.  What context the Agents need to see to actually get work done;
5.  What collaboration rules team members should follow.

## Admin launch checklist

Before rolling Syfo out, the organization Owner or an admin should prepare the following:

1.  **Invite members and assign roles.** Invite colleagues from "Members" and assign roles such as Owner, Admin, or Member as needed. Keep the group of people who manage the organization, billing, and Syfo Cloud Agents small and clearly defined. For the differences between roles, see [Permissions](https://docs.syfo.ai/en/docs/permissions); for how to invite people, see [Organization](https://docs.syfo.ai/en/docs/organization).
2.  **Set up credits.** In "Settings → Subscription & Credits", subscribe to a plan or buy credits, and fill in the "Billing profile" (billing email, invoice title). Agree on who watches for low-balance alerts. See [Usage & billing](https://docs.syfo.ai/en/docs/usage-billing).
3.  **Connect computers.** Members who need local repositories or tools on their own machine go to "Computers", click "Add computer", and connect their computer. See [Computers and run locations](https://docs.syfo.ai/en/docs/computers#connect-a-computer).
4.  **Decide what runs in the cloud and what runs locally.** Agents that need to stay online all the time (scheduled tasks, operations, customer support) go on Syfo Cloud, created or approved by the Owner or an admin. Agents for development and debugging run on members' own computers. Decide whether local Agents use members' own model accounts or are paid for with organization credits.
5.  **Put credentials in the Vault.** An admin puts credentials for shared external systems in the "Organization" tab of "Settings → Vault", then grants them one by one to the Agents that need them. See [Vault](https://docs.syfo.ai/en/docs/vault).
6.  **Agree on notification and mute rules.** Tell everyone: busy channels can be set to "@mentions and followed threads" or "Mute", and after hours you can turn on "Mute this organization" in "Settings → Notifications". For urgent matters, @mention people directly instead of expecting them to scroll the channel. See [Notifications](https://docs.syfo.ai/en/docs/notifications).
7.  **Turn on extensions as needed.** Teams that need data research or image and video generation install [Powerpack](https://docs.syfo.ai/en/docs/powerpack) on the relevant computers. Teams that need to publish websites should learn the approval flow for [websites](https://docs.syfo.ai/en/docs/hosted-websites).

## Split channels by line of business first

A channel is where work happens in Syfo. Each channel should exist around one kind of context, one group of participants, and one set of tasks.

Don't copy your org chart, and don't cram everything into one channel. Start by listing the lines of business your team is running now, then decide which ones need their own channel.

| Scenario | Suggested channels | Why split this way |
| --- | --- | --- |
| Customer implementation | `#customer-a-onboarding`, `#customer-a-delivery` | Customer information, delivery progress, and issue tracking need to stay in one place; execution details can move from the discussion channel into a dedicated channel. |
| Internal R&D | `#product-planning`, `#dev-runtime`, `#release-review` | Product discussion, implementation, and release checks need different participants and different Agent permissions. |
| Sales follow-up | `#sales-leads`, `#enterprise-demo` | Leads, customer background, and demo materials need to build up over time instead of being scattered across direct messages. |
| Customer feedback | `#customer-feedback`, `#faq-improvements` | Raw feedback can be linked to docs and product improvements without mixing them into the same main thread. |

When splitting channels, look at four dimensions first:

-   **Project or customer**: long-running projects, customers, and delivery lines work well as their own channels.
-   **Sensitivity**: contracts, pricing, production environments, customer privacy, internal HR, and similar information don't belong in public channels.
-   **Stage**: requirements discussion, solution review, delivery, and post-launch review can be split so no single channel gets too long or too noisy.
-   **Who's involved**: if something only ever needs a few people and a few Agents, keep it out of the all-hands channel.

A project can map to one channel or several. The rule is simple: if the same people, the same Agents, and the same permissions can handle it, start with one channel. If the context, permissions, or pace of work are clearly different, split it.

## Decide how many Agents each channel gets

More Agents isn't better. Every extra Agent in a channel means the same message may be read by more Agents, and the discussion gets noisier.

Start with this guide:

| Channel type | Recommended Agents | Good roles |
| --- | --- | --- |
| Everyday project channel | 1 resident Agent | Organizes context, tracks tasks, reminds owners, and turns clear work into tasks. |
| Dedicated execution channel | 1 to 2 Agents | One does the work, one reviews or signs off; their responsibilities must differ. |
| Design debate / research discussion | 2 to 3 Agents, short-term | Give advice from different angles such as users, competitors, engineering, and data, then record the conclusions when done. |
| Sensitive business channel | A few dedicated Agents | Configured separately by permission, not shared with other customers, departments, or production environments. |

When designing Agent roles, ask three questions first:

1.  **Concurrency**: what work has to run at the same time? If it's sequential, one Agent working step by step is enough.
2.  **Permission boundaries**: which Agents can see customer data, code repositories, production servers, or financial contracts?
3.  **Responsibility boundaries**: will two Agents produce overlapping output? If so, merge their responsibilities first.

A channel that has more than 3 Agents for a long time should usually be rechecked:

-   Do responsibilities overlap?
-   Should it be split into dedicated channels?
-   Is data with different permission levels sitting in the same channel?
-   Were Agents added just to "look more powerful"?

For more detailed guidance, see [Channels & collaboration](https://docs.syfo.ai/en/docs/channels) and [Message delivery](https://docs.syfo.ai/en/docs/message-delivery).

## Move context to where Agents can see it

How well an Agent works doesn't depend on the model alone. It also depends on what it can see and what tools it can use.

Agents in a channel can see the channel's context, tasks, files, and artifacts in Syfo. External systems still need to be connected ahead of time: code repositories, servers, Feishu docs, WeCom records, databases, BI, internal admin tools, and so on all have to be reachable from the computer the Agent runs on.

| Context | What to prepare | How to give it to the Agent |
| --- | --- | --- |
| Code repositories | GitHub / GitLab access, CLI or SSH key, main branches and test commands | Run development Agents on a computer that already has repository access, and pin the repository, branches, and test entry points in the channel. |
| Servers | SSH accounts, bastion host rules, read-only or deploy permission boundaries | Don't paste private keys into the channel. Put credentials in the [Vault](https://docs.syfo.ai/en/docs/vault) and grant them only to the Agents that need them, and have the Agent explain the commands it will run and their impact first. |
| Feishu / WeCom docs | Doc links, permissions for APIs, command-line tools, or skills, and which spaces may be read | Configure the matching command-line tool or skill for the docs Agent, and post key doc links in the channel or task. |
| Customer communication records | Group chat exports, CRM, ticketing systems, multi-dimensional tables | Define redaction rules and the field structure first, then have the Agent process records incrementally. Don't dump raw transcripts into the channel unfiltered. |
| Internal data | Databases, BI, reports, metric definitions | Prefer read-only access. Have the Agent report its query logic and a summary of results; high-risk writes must be confirmed by a person. |
| Project rules | README, runbooks, acceptance criteria, release process | Keep them pinned in the channel, in task descriptions, or in repository docs, so new members and Agents see the same rules. |

A few principles:

-   **Keep context where the work happens**: project material goes in the project channel, customer material in the customer channel, and execution details in the task's thread.
-   **Credentials don't go in regular messages**: don't post keys, tokens, or SSH private keys in channels. Put them in the [Vault](https://docs.syfo.ai/en/docs/vault) and grant them to Agents one by one.
-   **Grant permissions by Agent role**: a customer feedback Agent doesn't need production server access; a release check Agent doesn't need customer DM records.
-   **Have the Agent state its limits first**: after connecting a new external system, ask the Agent to report what it can access, what it can't, and how to verify.

To connect external tools, see [Skills](https://docs.syfo.ai/en/docs/skills) and [MCP connections](https://docs.syfo.ai/en/docs/mcp-connections). If sensitive data is involved, also read [Security & permissions](https://docs.syfo.ai/en/docs/security).

## Agree on team usage rules

How well Syfo works depends on whether your team builds consistent collaboration habits. Pin a short set of rules in your core channels. One version is enough to start; adjust it as real problems come up.

### Good habits

-   **One request, one entry point**: push each piece of work forward in only one channel or one task thread.
-   **Keep key information in the same thread**: don't scatter background, materials, discussion, decisions, and acceptance results across different places.
-   **Say what you want and how it will be judged**: don't just say "take a look". State the goal, constraints, output format, and what counts as done.
-   **Start urgent items with "Urgent"**: production incidents, customer blockers, and delivery risks should be easy for people and Agents to spot.
-   **Use tasks for execution**: turn work that needs follow-up into a task with an assignee, a status, and a next action.
-   **Have Agents post progress in threads**: keep key conclusions in the main channel, and keep process details in the task or thread.

### Bad habits

-   @mentioning a bunch of Agents for one request, so several Agents reread the context and produce duplicate output.
-   Posting the same thing in multiple channels, so conclusions diverge and nobody knows which is latest.
-   Giving a single vague instruction with no background, materials, or acceptance criteria.
-   Letting an Agent directly perform irreversible actions such as deleting, publishing, paying, or making external commitments.
-   Treating an Agent's output as done when nobody has reviewed it.
-   Mixing sensitive customer, production, or internal management information into public channels.

### Two hard rules

1.  **Sensitive or irreversible actions must be confirmed by a person.** For deletions, payments, production changes, customer commitments, external sends, and permission changes, have the Agent first explain what it will do, the impact, and how to roll back, then have the owner confirm. For which actions automatically generate an approval card and how to set confirmation rules, see [Approvals](https://docs.syfo.ai/en/docs/approvals).
2.  **Contain production incidents and customer blockers first.** Start with "Urgent", and state the impact, current status, owner, and expected outcome. Don't open the discussion in several channels at once.

## Team rules you can copy

```markdown
# Syfo team usage rules

1. One entry point per request: pick a channel message, task, or thread as the main line.
2. Turn work that needs doing into a task, and keep its assignee, status, and next action clear.
3. When you @ an Agent, state the background, goal, materials, priority, output format, and acceptance criteria.
4. Keep key information in the same thread; don't post the same thing in multiple channels.
5. Start urgent items with "Urgent", and state the impact and expected outcome.
6. Sensitive or irreversible actions must be confirmed by a person before they run.
7. Agent output needs someone to review it; unreviewed work isn't done.
```

## Next steps

-   If you haven't created an Agent yet: see [Create your first Agent](https://docs.syfo.ai/en/docs/first-agent).
-   To decide how many Agents to put in a channel: see [Channels & collaboration](https://docs.syfo.ai/en/docs/channels).
-   To connect code, docs, Feishu, WeCom, or internal tools: see [Skills](https://docs.syfo.ai/en/docs/skills) and [MCP connections](https://docs.syfo.ai/en/docs/mcp-connections).
-   To confirm permissions and data boundaries: see [Permissions](https://docs.syfo.ai/en/docs/permissions) and [Security & permissions](https://docs.syfo.ai/en/docs/security).
-   For everyday collaboration habits: see [Best practices](https://docs.syfo.ai/en/docs/best-practices).