Team

A team is several agents of one project that work together with you. One of them leads: the guru. The guru talks with you, gives you a position, turns your goals into work for the right teammate, reviews what comes back and tells you where things stand. The other members do the work.

Ready-made, the solo founder team has five members:

Nothing leaves the company without you. A teammate can prepare a message to a prospect or a customer; it waits under Needs you until you approve the exact text.

Create a team

• From Home: Build my team ▶ creates a new project for your company's team.
• From a project: 👥 Team in the World, in Data & go live, or in the Lab's command palette adds the team to that project. Existing agents are kept.

Fill in your company, what you sell, your name, the language the team writes in, a daily budget and whether it works on a schedule, then Create the team.

What it writes:

• one agent per member: agents/<id>/AGENT.md, objectives/work.md (how the member works) and context.yaml (what it has in hand and which doors it may open);
• five knowledge areas to fill in: knowledge/company, product, market, brand and sales. Write your offer, ideal customer and prices in knowledge/company: the team never invents a price;
• team.yaml: who is on the team, who leads, how work flows, when they work, the budget.

Two things only you can do stay listed at the top of the Guru tab until they are done:

• describe your offer, your customer and your prices in knowledge/company;
• choose the team's brain in Data & go live. Claude is recommended because it can search and read the web itself. Without an API key, choose Installed CLI to use Claude Code or Kiro CLI with its own login; with Claude Code, a member's smaller Claude (Setup → Brain) runs there too.

Without a brain the team rehearses: each member shows what it would work from, so you can try the whole flow first.

Each member has its own context

Every member is an ordinary agent of the project, so SEIF's escalation of options applies to each one:

• the prospector has the company and the market in hand;
• support has the company in hand and the product guide when it matches;
• the guru can open doors to market, brand, sales and product.

Open the World and choose an agent to see exactly what it is given. Edit a member's instructions with Setup → Edit → Instructions… (they open in the Lab).

Each member is also an agent of the Agent Workspace: Setup → Agent Workspace… opens it there, where you can edit its behavior, try it, give it capabilities, write test scenarios and create releases. It is the same agent, in the same files: what you change there is what the team works with. See One agent system.

Who sees what, and how they talk (conversations are not knowledge)

The science behind this is in the book (livro-didatico): quem seleciona é a perspectiva, o orquestrador vê retornos, não transcrições, conteúdo externo não escreve orientação, conversa não é evidência.

• A member without conversations still sees who a contact is (contact_lookup: name, relation, owner, notes), never what was said, and is told which teammate owns those conversations.
• An arriving message is looked at by the member who owns the conversation (the agent bound to the line, then the one who answers that relation, then any member with conversations); the lead sees the suggestion on the card.
• When the founder asks the lead about conversations, the lead delegates a bounded work item to the owner and reviews the return: findings with evidence (date, message id), what is unknown, proposals. It never asks for the transcript.
• A lesson from conversations ("this argument worked") becomes knowledge only when the founder approves it: the member puts it as a proposal in its hand-back. A transcript is never copied into knowledge/, a report or memory.
• Nobody, agent or developer session, reads WhatsApp, the Evolution server or its database directly: conversations come from the project's record (also in the project's Git) or through conversation_read. On OpenBot, through the hand-off ({"conversation": "<number>", "from_line": true} as an API request).

Talk with the guru

The Guru tab is a conversation that is remembered. Ask for a position, give a goal ("Find 5 companies that could buy from us this week"), or ask where things stand. The guru:

• checks the board before speaking about progress;
• delegates one bounded piece of work per teammate: a title, a brief and what "done" looks like;
• asks a teammate a quick question when it needs a fact or an opinion now;
• tells you what it delegated. Each delegation appears under its answer, and a click opens it on the board;
• comes back in the chat when it is finished: what was done, what it led to, and what waits for you.

The board and the pipeline

Work moves through Queued → Working → Waiting review → Done. Stuck holds work that is waiting for your answer or that failed. A card says when a message from that work waits for you.

Click a member on the left to see only their work.

• A teammate hands work back with a status (complete, partial, blocked, inconclusive), a summary, a report and one item per result. A company found is an item.
• The guru reviews hand-backs: it accepts what meets the brief with sources, sends the rest back with a concrete note, or rejects it. "A narrative is not proof." After two revisions an item comes to you.
• Flows move accepted work on. In the solo founder team, every opportunity the prospector hands back becomes one piece of work for the sales strategist. The strip at the top of the board shows each step and what it holds now. A hand-back without separate items (a model that answered in prose instead of submit_work) still flows on as one item carrying the whole result, and the work's log says so: accepted work never stops silently between two members.

Open a work item for:

• the brief, the result, the report, the sources and the history;
• where it came from, and what it led to (each proposal, and whether its email waits for you).

Accept, ask for a revision with a note, reject, try again or cancel it yourself.

To review everything yourself instead of the guru, set Setup → Who reviews hand-backs → Me, every time. ＋ New work gives a teammate work directly.

Needs you

Needs you is the project's one queue: the Agent Workspace shows the same list under Needs you.

The funnel

A team with funil/funil.yaml gets the Funil tab: each checkpoint with its leads, what is due today, the send queue and the WhatsApp line. The day's plan becomes approvals in Needs you (one per message, one per write to a connected API); approved messages leave from the send queue, spaced and in business hours; a lead's reply comes back as a card with the conversation, to answer, move or file. See funnel.md.

Messages and documents

• Messages is the team channel. It has new work, hand-backs, reviews, findings someone else needs, and your answers. Write to one member or to everyone; members read it with their next work.
• Documents is what the team produces. These are plain files under team/, versioned with the project and editable in the Lab:
• team/reports/: one file per hand-back;
• team/shared/: lists built together, such as leads.csv and pipeline.csv;
• team/proposals/: one proposal per opportunity;
• team/marketing/: copy, materials and UX/UI proposals.

The office, routines and budget

While the Team screen has been opened, the team's office stays open until the app closes:

• queued work runs by itself, one item at a time;
• routines start on time.

Routines run in the team's time zone, at most once a day each. One missed by less than an hour still runs. The solo founder team has four:

• prospecting on weekdays at 09:00;
• a customer and usage report on Mondays at 08:30;
• a brand and UX improvement on Wednesdays at 10:00;
• the guru's daily brief at 18:00.

Turn them on or off in Setup. ▶ Run the team now runs the queue and the routines that are due.

Spend today, in the top bar, estimates the cost as tokens × the model's list price. Web searches are counted, not priced. When the daily budget is reached, the team stops starting new work.

A model without a list price (a local or unknown model) is marked ▲. The daily limit cannot count it. Setup → Brain can give a member a smaller model (Sonnet or Haiku) for routine work.

On a server, run the office without the app:

runtime/node runtime/engine/team-office.mjs --project /path/to/team-project

It prints one JSON event per line. Standard input takes one command per line:

• {"cmd":"chat","id":"1","message":"…"}
• {"cmd":"run"}
• {"cmd":"stop"}

The web and data

What a member may do is part of the agent it is: the same list in Setup → May and in the Agent Workspace's Capabilities → Built in, kept in the member's AGENT.md. Capabilities defined in the project and connected to a system (Tool contracts) are offered to a member too when its knowledge settings allow them; writes wait in Needs you.

Safety

Members read web pages, documents and conversations that someone else wrote, so the team treats that text as data, not orders.

• Nothing leaves without you. A member only prepares a message. The card shows exactly where it goes: one email address or one phone number, normalised. That is the address used when you approve; a phone number hidden in a longer text is refused. Approving twice never sends twice.
• Reading the web without Claude: a member opens only addresses that already appeared in its work, so injected text cannot make it call out with your data. Those sources are its brief, documents, data, the pages it read and the links a search found.
• With Claude Code, a search is a separate call to Claude Code with only its WebSearch tool: no terminal, files, page reading or MCP. Only the links WebSearch returned are kept, never text the model wrote.
• Private, local and network addresses are refused in every spelling, including IPv4 inside IPv6, before and after redirects.
• The connection goes to the address that was checked, and at most 1.5 MB is read.
• Each member sees its own context. Documents are read under team/ only; knowledge reaches a member through its own areas and doors.
• A member that talks to customers never holds the company's systems. An agent whose audience is external (it answers students, customers, the public) cannot hold the connected APIs (api): whatever a customer writes reaches it, so a request could otherwise read or change partner, sales or payment data. The rule holds wherever grants are read (the team, its hand-backs from OpenBot, the hosted MCP server whichever token asks, Trinity and OpenBot exports, a routine's reads). Granting api to an external agent, or making an agent with api external, is refused with the reason; a file that still declares it is listed in Contexto → Configuração with one click to clean it. An external agent looks things up through the read-only lookups the owner configured (Connected data) and hands a change to a person or an internal teammate.
• A team.yaml from someone else, for example through Git, is held back on this computer:
• it cannot set a key or an address for a member's model; only a Claude model name is kept;
• its schedule does not run until you confirm it in Setup;
• projects it asks Support to watch are read only after you press Allow.
• Bounds:
• Flows cannot form a circle.
• The guru delegates at most 8 items at a time.
• A daily number of runs (60 by default) bounds models without a list price.
• Work accepted again after a revision does not flow on twice.
• Interruptions: work left running when the app closed goes back to the queue when the office opens again. You can cancel running work; its late result is kept in the history and goes nowhere.

Files

# team.yaml
name: Lumen team
company: Lumen
owner: Ana
language: Brazilian Portuguese
timezone: America/Sao_Paulo
lead: guru
members:
  - { id: guru, title: Guru, role: …, glyph: 🧭 }
  - { id: prospector, title: Prospector, role: …, glyph: 🔎 }
  - { id: closer, title: Sales strategist, role: …, glyph: 🤝, model: { provider: anthropic, model: claude-sonnet-5-5 } }
flows:
  - { id: opportunities-to-proposals, from: prospector, to: closer, each: item, brief: "Plan the commercial approach… {item}" }
routines:
  - { id: daily-prospecting, name: Find new opportunities, member: prospector, at: "09:00", days: [mon, tue, wed, thu, fri], brief: …, enabled: true }
review: lead        # or owner
autoRun: true
budget: { dailyUsd: 3, maxWorkPerRun: 6, maxRunsPerDay: 60 }
watch: [../my-live-agent]

What each member may do is in its own agent file:

# agents/closer/AGENT.md (frontmatter)
workspace:
  closer:
    capabilities: [web, documents, data, send]

A team.yaml written before this (with abilities: per member) keeps working until the team is saved, which moves them there.

The board, messages, approvals, the conversation with the guru and the spend are kept on this computer in .seif/team/state.json, which is Git-ignored. Actions and messages asked outside the team's work wait in .seif/approvals/queue.json.

Not in this version

• Sending email directly: approved emails open in your email app.
• LinkedIn or CRM automation. Connect a CRM as data, or send to n8n through the live agent's API.
• Several work items at once: the office runs one at a time.
• A team that works while the app is closed, except when the office runs on a server.

Proof

bash scripts/prove-team.sh runs the team's engine tests and the native journey, which writes the screenshots in evidence/team/.

The engine tests cover:

• the template: five agents, each with its own context, a lead, a flow and routines;
• the guru delegating;
• prospecting flowing into one proposal per opportunity;
• approvals: the email opens ready to send;
• revisions, retries, a stuck item coming back to the founder, and answers that unblock work;
• rehearsal without a model;
• the daily budget;
• routines in a time zone;
• documents kept under team/;
• Claude's web tools, and public-pages-only reading for other brains;
• the office running work by itself.

The native journey: Home → build the team → the guru delegates → the team works through the queue → open a work item → approve an email → read the lead list → message the team → shape the team in Setup.