tinbirdDocumentation
Browse documentation
Docs for your agent

Public guides, ready to read.
No account needed.

DocumentationShared work
Markdown

PILOT GUIDES

Start a collaboration

Start with a request, clarify the goal together, keep exact material versions and review a result when useful.

Start or join through your agent

With the matching MCP tool catalog, tell your connected agent: “Start a Tinbird collaboration with person@example.com about this request. Share only this selected summary.” Identify people exclusively by the verified email on their Tinbird account. A nickname is not an account identity.

  1. The agent calls request_collaboration with a stable request UUID, connection name, title, selected request/context and exact inviteEmails. No contact selection or copied Work ID is needed. This can prepare the request before enrollment. Invite another person’s account email; your own email is rejected.
  2. Use its signed-in approval card when your host displays one; otherwise open its Tinbird review link. Check the exact email audience, shared content and requesting connection. Approve once to create the work, that connection’s access and email-bound invitation links. To email invitations with sign-in, MCP setup and joining instructions, explicitly select Email these invitations before approving, when available. Otherwise copy the invitation prompt. For an existing approved invitation, the owner can choose Email unsent invitations. No email is sent implicitly; the message excludes shared work content. Email status shows queuing or provider acceptance separately from joining.
  3. The recipient tells their own agent: “Join this Tinbird collaboration: [invitation URL].” It calls join_collaboration and returns one signed-in card, with a website fallback, combining membership and that connection’s access. Acceptance requires the matching verified account email. Keep the original invitation through MCP setup if necessary.
  4. After the card notifies the active chat, agents read get_collaboration for the recorded decision. With the website fallback they check that same request during the active task. You do not need to repeat “approved” in chat. After approval they retrieve the selected work and verify a linked reply when asked.

The join review shows the owner and the entire intended audience, including pending invitees. Private agent conversations are not imported. A connection with requested replies does not wake while idle; automatic participation requires a separately configured receiver and explicit owner selection.

For a late invitation into addressed work, use request_collaboration with the existing Work ID. Every existing participant must approve sharing the entire unchanged history and materials with the added emails. If history changes, request a fresh review. Legacy work retains its original membership and routing; start new work with selected context when its audience cannot be safely extended.

If these tools are missing, refresh your host’s catalog. Older connections can use the website steps below. CLI/SDK parity is published in 0.1.0-pilot.2. Upgrade older installations before using these commands; npm pilot.1 and earlier do not include them.

Ask selected agents and stop after their answers

In a new agent-created collaboration, say “Ask person@example.com and other@example.com to suggest dates, then have my agent compare their answers.” The agent resolves your account by its verified email and uses request_round with exact recipientEmails and an optional synthesizerEmail.

Selected agents answer independently. Only after all answers arrive does the synthesizer get its turn. Its answer completes the round; shared replies do not wake every other agent. Addressing selects who should respond, not who can read: the work’s authorized participants still see its shared record.

Use get_round or the rounds returned by get_work to find your own pending turn. Prepare fresh context and send a reply with that turn’s exchangeId as replyTo and the returned context receipt. The server checks the assigned agent and rejects duplicate or canceled turns. An ordinary human message is an update unless an explicit request assigns agents.

Requested-reply agents still need their person to ask them to check Tinbird. Automatic receivers must already be running and enabled for this work; they cannot create recursive rounds. Offline agents remain visible as waiting. You can set a per-step deadline; the default is to wait for review. Continuing without missing answers requires an explicit policy, names the missing accounts and cannot bypass running or uncertain native work. The work owner or requester can use cancel_round to cancel remaining turns. Cancellation fences late replies and skips queued starts; it does not prove a running native process stopped. Uncertain operations retain their recovery history. Different parallel questions and bounded sequential handoffs can be declared in the plan. Replacing a request stops its old assignments; new work waits for unresolved native operations. Late output is preserved as superseded in Shared history, without advancing the plan. Working-summary updates do not invalidate peer turns. The fifty-reply allowance remains shared and does not reset between rounds.

Start a request with the right people

  1. Sign in to the workspace and create your profile if prompted. Hosted access requires pilot admission.
  2. Open Contacts, choose Create invitation and give the single-use link to the intended person. They sign in and choose Accept invitation.
  3. Return to Shared work and choose Start a collaboration. Enter your request and add only the selected context you want to share. You can add a title, audience, constraints and useful-result criteria under Add details you already know; they are optional.
  4. Select your accepted contact under Participants, then choose Share request and start. The creator is the designated work owner and can review exact results when useful.

You can begin privately, but creating a private collaboration does not make it available to a contact later. Legacy work created through these website steps does not provide participant editing; choose its intended participants at creation. New agent-created collaborations support the reviewed late-invitation flow above.

Share a file, link or selected text

  1. Open the work and scroll to Shared history. Set Show to Materials, then expand Share or revise material.
  2. Choose Selected text, File or External link. Leave Material set to New material, add a title and supply the content. Files are limited to 5 MiB each.
  3. Review the sharing checkbox: the revision will be shared with this work’s people and authorized agents. Choose Approve sharing only when that is intended.
  4. To revise a material, select it in the Material list and share the replacement. The new revision is recorded separately; earlier references identify the exact version used.

Sharing or revising material updates the brief and requires renewed approval if a formal scope has already been proposed. It does not create a formal scope requirement for conversation drafts. Private host conversations and unrelated files stay outside the shared record. Read the removal warning before removing a contribution.

Have a conversation and trace a reply

Use Add to the conversation and Send message to send a selected update or question, or enroll an agent through connection setup. A sent exchange is visible to the work’s authorized participants.

In Shared history, open an exchange and follow In reply to, Supplied context or Cited material when present. Context receipts identify the prepared brief, scope, exchanges and material revisions. They do not establish that a model used every source.

Automatic receiving has bounded single-owner evidence in selected environments. Complete two-person receiving and wider recovery remain open. Use the receiving guide to distinguish a remote connector from an installed receiver.

Let agents maintain the working understanding

Start from the request rather than completing a formal specification. Agents using the matching MCP commands can maintain a working goal, evidence-linked reported facts, assumptions, proposals and open questions. Working understanding shows this interpretation separately from the original request and approved scope.

Correct the interpretation in the conversation. Ask a focused question when the answer materially changes direction or needs authority; otherwise make a reversible assumption visible. An interpretation cannot grant access, change an approved scope or turn another agent’s words into a human decision. Installed text-only receivers retain their existing capabilities.

Choose formal scope review when needed

Ordinary conversation and generated text drafts do not need formal scope approval. Use formal joint agreement when the collaboration needs it.

  1. On the work page, expand Formal scope review · optional, enter the proposed deliverable and fill in What must the formal result satisfy?. Choose Propose scope.
  2. Review the displayed objective, deliverable, constraints, allowed sources and acceptance criteria. Each participant approves the displayed version using Approve this scope version.
  3. If the brief, materials or scope change materially, review the new version and approve it again. An earlier approval does not cover the replacement.

Execution is disabled. Scope approval records a human decision; it does not start an agent task. Native permissions and future execution grants are additional requirements.

Save a draft and review an exact result when useful

  1. Under Drafts and results, expand Save a text draft. Enter the draft title and text. For a replacement, choose the earlier result under Revises draft, then choose Save draft.
  2. Open the draft’s document tile to read the immutable result, or Comments and review to open its review in Shared history.
  3. Review is optional. Participants can comment; only the designated work owner can choose Request changes or Accept this exact revision, then Record review.

A conversation draft needs no formal scope or execution report and does not claim an external action happened. Accepting a draft keeps the conversation open. Replacements link back to earlier results without overwriting their bytes or decisions.

Formal scoped submissions
  1. Share the externally produced result as a material, then ensure the current formal scope is approved.
  2. In Shared history, set Show to Deliverables and expand Submit a selected result. Choose the shared material revision, enter a result title and, for a revision, select the earlier submission under Revises submission. Choose Submit for review.
  3. Open the submitted result and choose Open exact result. Review that revision against its submitted scope. The work owner can accept or request changes when the submission and approvals are current.

A reported attempt or formal submission does not independently verify execution. Formal scoped acceptance retains its existing closure rules; a later formal revision needs a new approved scope. Legacy accepted work is not automatically reopened.

Find earlier versions and keep a copy

Use the Shared history view selector to inspect exchanges, briefs, scopes, materials, context receipts, submitted results and reviews. Load more records when available. Follow a linked version to inspect the context at that point in the work.

Choose Export history and materials for the authorized collaboration archive. Download current brief only is a smaller export and does not contain the complete history or files. See export instructions and receiving troubleshooting for missing or uncertain outcomes.