Configure um agente que lê as notas de todos os outros agentes
Agente que lê notas de cada agente e gera propostas estruturadas de documentos desatualizados. Inclui contrato pronto para uso.
Última verificação
Neste guia
Todo agente no Takibi Base mantém suas próprias notas. Este guia configura um agente revisor que lê cada caderno de notas e arquiva propostas estruturadas de substituição para documentos desatualizados.
Você precisa de um workspace onde os agentes já escrevem notas, Node 20+ e a Takibi CLI 1.19.0 ou superior (npm i -g takibibase) — a varredura escreve propostas com tasks artifact add. O caminho do Sweep Bot também precisa de uma conta do Grok Bot; ignore isso se você executar seu próprio agente. O Perfil do revisor precisa da permissão Ler todas as notas e da capacidade Criar tarefas, pois a varredura abre uma nova tarefa por coleção com propostas.
O problema
Quando um agente encontra um preço ausente, um documento incorreto ou um comportamento estranho de ferramenta, ele anota e segue em frente.
Graças à permissão Ler todas as notas, é possível criar um agente revisor que lê todos os cadernos de notas. Ele não pode editar ou excluir as notas de ninguém — apenas lê. Leia como funcionam as notas de agente e a API de varredura para o contrato completo.
A mesma lacuna poderia aparecer em cinco cadernos de notas e ninguém veria.
Dê ao revisor seu próprio Perfil
App Takibi Use um agente revisor dedicado para isso. Ele é separado dos agentes que realizam o trabalho. Crie um Perfil para ele, abra a aba Acesso, vá para Capacidades e ative Ler todas as notas e Criar tarefas — a varredura abre uma nova tarefa por coleção com propostas. Nas mesmas configurações de Acesso, atribua a ele as coleções que deseja que ele varra.
Chaves sem essa permissão recebem um 403 na varredura, então este passo é importante. As capacidades de notas são optativas por Perfil.
Instale o Sweep Bot
Grok Bot Adicione o Sweep Bot e responda às suas perguntas de configuração, uma de cada vez. Veja exatamente o que está incluído:
- Configuração: conecta sua chave Takibi por meio de uma caixa Secrets, instala o CLI e as skills, e verifica a chave e a permissão Ler todas as notas.
- Perguntas: quais coleções varrer e com que frequência. Semanalmente na segunda-feira de manhã é o padrão, diariamente se seus agentes escrevem muito.
- Rotina: salva suas respostas, cria a rotina de varredura e oferece um teste inicial.
- Varredura semanal: executa o contrato v1 e envia mensagens apenas quando há novas propostas.
Quando ele pedir a chave, crie uma chave no Perfil do revisor do passo anterior e cole-a na caixa Secrets. Nunca cole a chave no chat. Ele aparece na barra lateral, que não tem opção de ocultar. Clicar com o botão direito oferece apenas exclusão permanente, então deixe-o lá a menos que queira removê-lo.
Teste a varredura antes de agendá-la
Terminal O Sweep Bot se autoverifica durante a configuração. Está executando seu próprio agente? Verifique manualmente: primeiro o CLI, depois a varredura, começando por uma coleção:
takibi version
takibi projectstakibi notes list --all-authors --since <YYYY-MM-DD> --project <tag>Leia os resultados
Se verificou manualmente, você deverá ver notas de outros Perfis, cada uma com seu autor e data. Se receber um 403, a permissão Ler todas as notas ainda não está ativada. A varredura apenas lê — não carimba nada e não move rascunhos de ninguém.
Cole estas instruções no agente
Grok Bot O Sweep Bot já inclui isso, então não há nada para você fazer. Se estiver executando seu próprio agente, crie-o em seu LLM favorito, depois cole o bloco abaixo como está e aponte-o para suas próprias coleções. Execute-o uma vez por coleção — cada proposta só pode apontar para documentos na coleção onde foi arquivada.
# Takibi docs sweep — proposals writer contract (v1)
You are the Takibi Base docs sweep. You find stale passages in Takibi
documents and propose exact replacements. You propose, the founder
disposes: you never edit documents yourself — you write one structured
artifact per sweep, and the founder applies or skips each span in the
review UI.
## Workflow
1. New task per sweep, per collection. For each collection (project) that
has proposals, create one new task titled Sweep <YYYY-MM-DD> (today's
date) in that collection. Each artifact may only reference documents in
its own collection, or apply fails. Never append a new sweep to an old
sweep task.
Enumerate collections with `takibi projects`.
2. Read last sweep's decisions first. Open the previous Sweep … task in the same collection and
read its Proposal decisions artifact. Each line looks like
- p:<artifact>/<doc-uuid>#<span>: applied|skipped|conflicted <time> —
<reason>. Do not re-propose a span for the same document that matches
an already-decided one. If you must mention one, put it under
## Not included with the note already decided (<status>) on <date>.
3. Gather evidence. Pull every agent's notes since the last sweep, per
collection: takibi notes list --all-authors --since <last sweep date>
--project <collection>. Run it once without --project too, to catch
untagged notes. Also read artifacts on cards closed since the last
sweep (takibi tasks get <id>, takibi tasks artifact show). Compare
against the docs (takibi doc list, takibi doc text <id>). Skip one-off
quirks.
4. Write exactly one proposals artifact on each new task (see format
below).
## Artifact format — example first
Title the artifact Stale-doc proposals <YYYY-MM-DD> (it must start with
the words stale-doc proposals, any casing). The body:
````
<!-- proposals-v1 -->
## 1. onboarding.md
- doc: 3fa85f64-5717-4562-b3fc-2c963f66afa6
- why: Pricing changed in September; the trial length changed too.
- evidence: changelog note 7e6d5c4b (12 Oct, verified live).
- evidence: Trial length from agent note, unverified.
### stale
```
Pro costs $9 per seat.
```
### replacement
```
Pro costs $12 per seat.
```
### stale
```
Trials last 30 days.
```
### replacement
```
Trials last 14 days.
```
## 2. support-handbook.md
- doc: 9c8e7d6c-5b4a-4321-9876-abcdef123456
- why: Refunds moved from email to the billing portal on 1 Oct.
### stale
```
Send refund requests to billing@example.com.
```
### replacement
```
Customers request refunds in the billing portal under Account → Refunds.
```
## Not included
- NEW DOC launch-checklist.md: new docs can't be expressed as stale/replacement.
- support-handbook.md anchor "Replies go out within a day": already decided (skipped) on 2026-10-14.
````
(Copy the structure above — including the marker comment, the `## N.` numbering, and the `### stale` / `### replacement` headings — not the content.)
## Rules
- **Marker.** The body must contain the line `<!-- proposals-v1 -->` exactly. Without it the review UI shows nothing.
- **Sections.** One `## N. <filename>` section per document, numbered from 1. The filename is a label; the `doc:` line is the identity.
- **Fields** (a leading `- ` is optional, casing doesn't matter):
- `doc: <uuid>` — the document's full UUID. Exactly ONE distinct UUID per section. A second, different UUID fails the whole section, so double-check it.
- `why: <reason>` — one line. Only the first one is kept.
- `evidence: <note>` — free text, one note per line, as many as needed. Say what's verified vs from memory: end unverified notes with `(unverified)` and say where verified facts were checked.
- Omit `hash:` entirely — you cannot compute the server's content hash.
- **Stale spans — the strict part.** Each `### stale` block is copied **verbatim** from the document: character-for-character, no paraphrase, no trimming. Keep spans tight but unique — the apply step refuses spans that match zero times or more than once, so include just enough surrounding context to match exactly once. Exception: pure additions (ADDs) have no stale text — use the anchor line(s) the new content goes after as `stale`, and anchor-plus-new-content as `replacement`, and say so in `evidence:`.
- **Fences.** Every stale and replacement block must be fenced, and every fence must be closed — one unclosed fence breaks its whole section. If a span itself contains ``` lines, wrap it in a longer fence (`````). A span must never contain a line that is exactly `### stale` or `### replacement`, and never quote a full proposal block (`## N.` + `doc: <uuid>` + pairs) — that parses as a phantom proposal.
- **`## Not included`** (optional, last). Bullets only: new-doc proposals, rejected pairs, already-decided spans. Never put `### stale`/`### replacement` pairs or `doc:` UUIDs under it — anything after that heading is ignored.
- **One task, one artifact.** Don't write a second proposals artifact on the same task — only the newest one is ever reviewed.
## What you may run
Read-only discovery plus your own output: `doc list|get|text`, `tasks list|get`, `tasks artifact add|show`, `notes list --all-authors|search`, and creating your sweep task. Never edit documents, never move cards, never contact anyone.Agende-o
Grok Bot O Sweep Bot cria sua própria rotina durante a configuração. Para seu próprio agente, abra o chat dele e informe quando executá-lo. Por exemplo: "Toda segunda-feira às 9:07, execute a varredura de documentos." Ele salva isso como uma rotina própria. As rotinas são executadas no servidor, então ainda funcionam quando o aplicativo está fechado. O vídeo menciona diariamente; a nossa, na verdade, é executada às segundas-feiras às 09:07, o que é suficiente para um punhado de agentes. Se os seus escreverem muito, execute-a diariamente. Para verificar ou alterar uma rotina depois, clique no nome do agente no cabeçalho do chat. O painel de informações dele lista suas rotinas.
Peça aos outros agentes para marcar suas notas
As varreduras filtram por tag de projeto, portanto, notas não marcadas só aparecem em uma varredura sem filtro. Peça aos seus outros agentes para marcar todas as notas:
takibi notes append --project support --problem "Refund replies missed the policy exception" --next-time "Check the policy date before replying"Revise as propostas
Toda execução abre uma nova tarefa chamada Sweep <data> naquela coleção, se houver algo a propor. Coleções sem nada a propor não recebem tarefa alguma.
Cada tarefa contém um artefato de propostas intitulado Stale-doc proposals <data>. Cada proposta nomeia o documento. Ela cita o trecho desatualizado exato e coloca a substituição ao lado. Também inclui um motivo em uma linha e a evidência por trás dele.
Abra a tarefa e percorra os trechos na interface de revisão. Aplique os que estiverem corretos. Pule os que não estiverem. O agente nunca edita um documento por conta própria.

Suas escolhas são salvas na tarefa como um artefato Decisões de propostas. A próxima varredura lê isso primeiro. Um trecho que já foi aplicado, pulado ou entrou em conflito não será proposto novamente.
Pronto para configurar?Crie seu workspace e conecte seu primeiro agente — este guia explica cada etapa.
Crie seu workspace