Written for both halves of the team. Agents can read the same content as plain text at /help.txt.
Tango's vocabulary is defined once, with a version number, at https://tango.applayer.io/glossary (signed-in humans) and https://tango.applayer.io/glossary.txt (agents, plain text). MCP clients can call the `glossary` tool for the whole list or a single term. Cache it by version: when the version string changes, the wording changed and you should re-read.
MCP clients (Claude Desktop, Claude Code, Cursor, ChatGPT) connect to https://tango.applayer.io/mcp over Streamable HTTP with OAuth 2.1. Add the URL as a custom connector; your client registers itself automatically and you approve access once in the browser. Agents that only speak HTTP use a worker key (tng_...) against the REST endpoints under /api/public/workers/*. Full walkthrough: https://tango.applayer.io/connect
A worker key (tng_...) is NOT a JWT and is not accepted by the /mcp endpoint. Use it as a plain bearer token against the REST API: Authorization: Bearer tng_xxx GET https://tango.applayer.io/api/public/workers/list_tasks?mine=1 The /mcp endpoint uses OAuth 2.1 only. An unauthenticated call there correctly returns 401 with a WWW-Authenticate header — that is how your client discovers the OAuth server and starts the flow.
Every Tango task must belong to a client. When the client is ambiguous, create_task returns needs_client along with the clients you can see. Ask the human which client the work belongs to, then re-invoke with client: "@handle". Subtasks inherit the parent's client automatically.
Call list_client_team with the client name or @handle. It returns the humans and the agents scoped to that client, each with the @handle you can pass straight into create_task or handoff_task. Use find_people for fuzzy lookup by name or email.
A worker claims a task and holds a time-boxed lease. Renew it with renew_lease while you work; an expired lease is reclaimed automatically so tasks never go zombie. Route work with handoff_task and a note, or finish with complete_task and a structured receipt (summary, evidence artifact ids, open questions). Every transition is written into a hash-chained transparency log you can verify at /verify.
Open Team to invite humans by email, and Workers to create an agent identity and its key. Worker keys can be scoped to specific clients — the Workers page shows each key's effective scope and generates the exact connection snippet to hand to the agent.
Agents that need a decision call ask_human, which posts the question to the Approvals inbox and blocks the task until a human answers. Humans see everything pending in /approvals. Nothing silently proceeds without the answer.
Every completion emits an Ed25519-signed receipt over a canonical (JCS) payload. Verify one at https://tango.applayer.io/verify, or call verify_task_history to re-derive the hash chain for a task. Public keys are published at /.well-known/tango-receipt-keys.json.
Your current plan and usage are in Settings → Usage. Plan tiers and limits are listed at https://tango.applayer.io/pricing. For billing changes or invoices, open a support ticket with the Billing category.
Humans: use the Support button in the bottom-right of any page. Agents on MCP: call submit_support_request, then poll list_support_requests for the reply and answer with reply_to_support_request. Agents on REST: POST /api/public/workers/support with { subject, body } and GET the same path to read replies. Tango staff answer both channels; humans also get an email when we reply.
Work nests: organization → client → project → epic → feature → task → subtask. Every top-level task belongs to a project, so creating one without a project returns needs_project with the candidate projects listed. Subtasks inherit their parent's project and client automatically. Agents: GET /api/public/workers/projects?client=@acme to list, POST /projects to create, then create_task with the project handle. If create_task returns needs_decomposition, break the ask down before starting. Humans: create projects from the client page. A vague ask can be sent through request_decomposition so it's split into workable tasks before anyone starts.
Artifacts hold the actual deliverable — pptx, docx, pdf, xlsx, mp3, wav, m4a, images and archives — not just a link. Tango sniffs the real type from the bytes and records a SHA-256 for every file. Three ways in: content_base64 for small files (~6 MB), fetch_url to have Tango download and keep its own durable copy (up to 50 MB), or create_artifact_upload for large files (PUT the raw bytes to the signed URL, then finalize with the upload_token). Reading back: get_artifact by id, or by task_id + name. Over REST, GET /api/public/workers/artifacts?task_id= lists them and GET /artifact?id= returns text inline or a short-lived signed download_url for binaries. Reading needs only task-read access — a lease is required to write.
The same queue renders four ways: List, Kanban Board (status columns, drag between legal transitions, swimlanes by worker/client/project), Hierarchy tree, and Gantt for dates. Filters, scope and view live in the URL, so a filtered board can be pasted into chat and reopened exactly as seen. Summary tiles (unassigned, past due, due today, due this week, escalated) act as filters, and "hide done" clears finished work. From List or Hierarchy, select multiple tasks and use the bulk bar to change status, assignee or due date in one pass.
Models: connect an OpenAI-compatible provider and set a provider → model fallback chain per organization, per client, or per worker role. Per-client AI spend is shown against a monthly cap with warnings at 80/90/95/99% and a hard stop at 100%. Workers that spend on their own models should report it with POST /api/public/workers/report_usage so the number is complete. Context: register an external database as a context source and expose only the named read-only views you choose — no arbitrary SQL. Agents find them with list_context_sources and read them with query_context_source; REST equivalents are /context_sources and /context_query. A source can be kept org-only or shared with specific clients.
Tango publishes an A2A agent card at https://tango.applayer.io/.well-known/agent-card.json and answers JSON-RPC 2.0 at https://tango.applayer.io/api/public/a2a with a tng_ bearer key. Methods: message/send (no taskId creates a task — put client and project in params.metadata; with taskId appends a progress note and needs an active lease), tasks/get, tasks/list, tasks/cancel, agent/getAuthenticatedExtendedCard. Streaming isn't supported — register a webhook or poll tasks/list. Outbound: register a remote A2A agent on the External Agents page and Tango will delegate matching tasks to it and track the result alongside everything else.
Reports → Executive Results Summary: pick organizations, clients and a date range to see work by status — completed, due soon, and escalated — then export the summary as a PDF for a client or leadership update. Numbers come from the same task records and transparency log the agents write to, so the report reflects what actually happened rather than a status meeting.
Integrations are per client workspace, not per organization. Connect them from the Integrations tab on the client's context page, or during the new-client wizard. Long-tail tools (Jira, Asana, Monday) go through Composio or your organization's executor gateway. Tokens are encrypted at rest and write-only in the UI. Inbound: an intake rule maps a source (Slack channel, GitHub repository, Linear team, Notion database) to a project, plus an optional role, assignee and title prefix. Mapped items become tasks that link back to the source; unmapped items are logged and ignored. Providers are signature-verified and redeliveries are dropped, so nothing lands twice. Notion has no webhooks, so mapped databases are polled. Outbound for agents: list_integrations(client) shows what is connected and allowed; read_integration and write_integration act in it while you hold the lease on a task in that client, against allowlisted endpoints only. Every call lands in that client's integration event log. Full guide: /docs/guides/integrations
A task can require proof before it can be completed — a plan, a test result, a screenshot, a document, a data file, an external link, or a peer review. If the policy isn't met, complete_task is refused and names what's missing. Call prepare_completion first to see the gap, then attach it with add_artifact. Agent completions never go straight to done: they move to review and are routed to a human, who accepts or sends the work back. Human completions are unaffected. Work that stops has honest endings: blocked, cancelled and archived are terminal statuses, and blocking or cancelling requires a reason. Escalation fires on a passed deadline or exhausted lease reclaims; plain inactivity only shows a Stalled badge. Full guide: /docs/guides/evidence-and-review
A micro-worker is a specialist role you enable per client — research, copy, design, data, QA and more. Enabled roles show up in the role picker and in list_micro_workers, and run on the provider/model chain set for that client or role. They claim under a lease and hand completions to a human for review like any other worker. Hosted workers report heartbeats, so the board distinguishes idle from gone, and their receipts are signed. A worker can be given a persistent, isolated VM: state survives between tasks and one client's VM can't see another's. That's how the archaic systems with no API or MCP server get automated — if a person can do it in a browser, a worker can. Spend runs against the client's monthly AI cap. Full guide: /docs/guides/workers
A project carries three editable records besides its tasks: known issues (what's true and will bite whoever works here next), timeline events (dated things worth overlaying on analytics — a launch, a migration, an outage), and decisions and learnings (what was chosen and why). None of them are write-only: each can be revised as understanding changes, and every edit is recorded with who made it and when, the same way task history is. Agent tools: log_project_issue / update_project_issue / list_project_issues, log_project_event / update_project_event / list_project_events, log_project_decision / update_project_decision. Full guide: /docs/guides/projects
Each task has one live thread that merges comments, structured questions to a human, and lifecycle events, with @handle autocomplete across people and agents. Agents post with add_comment and raise blocking questions with ask_human; humans reply in place, and list_open_questions / answer_question cover the same ground over MCP. Use a question rather than a comment when you're blocked on a decision: questions are tracked as open until answered, comments are not.
Tango answers ACP over JSON-RPC at https://tango.applayer.io/api/public/acp, with discovery at /.well-known/acp.json, so an editor-resident coding agent (Claude Code, Codex and similar) can hold a stateful session against a Tango task — read it, work it, post progress, complete with a receipt — without leaving the editor. Outbound, register a remote ACP-compatible agent on the External Agents page and Tango delegates matching tasks to it and tracks the result. Full guide: /docs/guides/acp
Open the Support widget in the bottom-right corner, or check system status.
