Glossary
Terms used across Tango, the MCP server, and the REST API.
Epic
The largest unit of work in Tango. An Epic is an outcome that spans weeks and several people or agents — it is never worked directly. Epics hold Features and Tasks beneath them and exist so a long initiative keeps one thread of history.
Feature
A shippable slice of an Epic. A Feature groups the Tasks needed to deliver one coherent piece of value. Like an Epic, it is a container: workers claim the Tasks under it, not the Feature itself.
Task
The unit of work one teammate can actually finish and one reviewer can check. Every Task has a title, goal, definition of done, a client and a project, and exactly one assignee at a time. If an ask contains more than one deliverable, it is more than one Task.
Subtask
A Task with a parent Task. Subtasks inherit the parent's client and project automatically and appear as a breadcrumb chain (Epic › Feature › Task) on the task detail page.
Parent task
The task directly above another in the hierarchy. Task rows and cards show “↳ parent title”; the detail page shows the full ancestor chain up to the Epic.
Project
The container between a Client and its Tasks. A Project carries its own goal, context and decision log, so agents can read why the work exists before starting. Every Task must belong to a Project.
Short task ref
The first eight characters of a task id, shown as a copyable #chip (for example #fd959117). Agents quote it in chat; you can paste it straight into task search, search_tasks, or get_task.
Dependency
A “blocked by” link between two tasks. Dependencies drive ordering on the Gantt view and flag conflicts when a blocker is due after the task it blocks.
Gantt view
The horizontal timeline on the Tasks page. It plots tasks by start and due date, draws dependency arrows, and flags schedule conflicts.
Template
A reusable task shape (title, goal, definition of done, role, estimate) scoped to an organization or client. Templates can be run on demand or attached to a recurring schedule.
Recurring schedule
A cadence that materializes a Template into a real Task automatically (daily, weekly, monthly). Useful for standing client deliverables like weekly reporting.
Organization
The top-level tenant — usually an agency or a company. Organizations own Clients, members, workers, billing and provider settings. In older copy and in some API fields this is still called an “agency”.
Client
A workspace inside an organization representing one customer or brand. Every task, project, worker assignment and context source hangs off a Client, and it is the boundary that isolation is enforced on — a teammate scoped to one Client cannot see another's work.
Hierarchy
Organization → Client → Project → Task (→ Subtask). Every object below the organization inherits the tenancy of the one above it; this chain is what keeps multi-client work separated.
Member
A human with a seat in an organization. Members can be owners (full control of the org), staff (work across the org's clients), or scoped to specific clients only.
Owner
A member who can manage an organization or a client: invite people and agents, set AI providers and caps, register context sources, and archive records.
Client contact
An external person who belongs to one client only. They see that client's tasks, workers and reports — nothing else in the organization.
Platform admin
A Tango staff account (super admin) with cross-organization visibility for support and operations. Cross-org access is strictly gated on this role and every use is written to the audit log.
Impersonation
A platform admin temporarily viewing the app as another organization to reproduce an issue. A banner is always visible while it is active and the session is audited.
Seat
A billable slot in an organization's plan, consumed by a human member or a worker identity. Tango's system workers are exempt from seat quotas.
Archive
A soft removal. Archived organizations, clients, workers and users disappear from the default UI and from routing, but their history and receipts remain intact and verifiable.
Status
Where a task sits in its lifecycle: queued → claimed → in progress → blocked/paused → in review → done, with escalated as an exception state. Status is about the work; assignment is about the person.
Assignee
The human or agent responsible for the task right now. A task can be assigned and still unclaimed — assignment says who should do it, a claim says who has actually picked it up.
Claim
The act of taking a task off the queue. Claiming creates a lease so no second worker starts the same job. Agents claim with claim_task or pull_next_task; humans claim from the task page.
Lease
A time-boxed exclusive hold on a task (45 minutes by default). While you hold the lease you are the only one who can write progress or complete it. Renew it with renew_lease; if it expires the task returns to the queue instead of going zombie.
Reclaim
Picking a task back up after your lease lapsed. Three failed reclaim attempts on the same task counts as reclaim_exhausted and escalates it.
Queue
The pool of workable tasks a given worker is allowed to pull from, ordered by urgency and deadline. Tasks that are flagged, blocked by a dependency, or already leased are not served.
Pull / check-in
How an agent asks for work. check_in reports the agent is alive and returns anything newly assigned or newly changed; pull_next_task leases the next workable task. Idle is only correct when check-in returns nothing.
Handoff
Passing a task to another teammate with a required note. The lease moves with it, so responsibility is never ambiguous and the timeline records who handed what to whom.
Progress note
A short in-task update recording a decision, finding or blocker. Notes are how work stays legible to the rest of the team while it is still in flight.
Comment
A conversational message on a task, visible to everyone who can see the task. Use @mentions to pull in a person or an agent.
Artifact
A concrete output attached to a task — a link, a document, a file, a piece of copy. Artifacts are what a completion receipt cites as evidence. Any teammate scoped to the task can read an artifact's body with the `get_artifact` tool, or GET /api/public/workers/artifact?id=<artifact_id> over REST; get_task inlines small text bodies automatically.
Definition of done
The check that says the task is finished — written before the work starts, phrased so someone other than the worker can verify it.
Pause with checkpoint
Stopping work deliberately while recording where you got to and what is needed to resume. Different from abandoning a task or letting a lease expire.
Escalated
An exception state, not a nag. A task escalates only when its deadline passes (once) or when reclaim attempts are exhausted. Escalated tasks surface to owners and are not served to the general queue, though the assigned worker can still pick their own escalated task back up.
Stalled
A badge, not a status. It marks a task with no activity for a while so it is easy to spot — it does not change routing or escalate anything.
Quality gate
An automatic block on work that is not ready. A task flagged “needs breakdown” (too big) or “needs more info” (too vague) will not be served from the queue until a human or the Tango PM reviewer resolves the flag.
Scope check
The check Tango runs at creation time. If a task contains more than one deliverable it comes back needs_decomposition and must be split into subtasks before anyone can work it.
Tango PM review
An AI project-management reviewer that reads a flagged task and proposes a fix — a clearer goal, a definition of done, or a breakdown into subtasks. Proposals are applied only when a human accepts them.
Approvals inbox
The queue of things waiting on a human decision: join requests, agent questions (ask_human), escalated tasks and review proposals.
Ask human
How an agent raises a blocking question without abandoning its task. The question lands in the Approvals inbox and the answer is written back onto the task timeline.
Activity timeline
The full chronological record on a task: claims, notes, artifacts, comments, handoffs, flags and completion — the same view humans and agents read.
Worker
An identity that can hold a lease and finish work. Usually an AI agent running in a harness (Claude Desktop, Claude Code, Codex, Hermes, OpenClaw, a hosted micro-worker), but humans also act through their own account.
Handle
The @name that identifies a person or worker across the app (for example @jasonhermesmac). Handles are what you pass to create_task, handoff_task and @mentions.
@mention
Referring to a teammate by handle, name or email. Tango fuzzy-matches; when several people match it returns candidates to disambiguate rather than guessing.
Harness
The client software an agent runs inside — Claude Desktop, Claude Code, Cursor, ChatGPT, Codex, Hermes, OpenClaw, or your own script. Tango is harness-agnostic: the queue is the same whichever one you use.
MCP
Model Context Protocol — the standard Tango exposes its tools over. MCP clients connect to https://tango.applayer.io/mcp with OAuth 2.1 and get the full toolset; no API key is minted or needed.
REST worker API
The plain-HTTP path for agents that do not speak MCP: /api/public/workers/* with a tng_ worker key as a bearer token. Same operations — heartbeat, list tasks, claim, update, complete.
Worker key
A secret token starting with tng_ used as a bearer credential on the REST API. It is not a JWT and is not accepted at /mcp. Keys are scoped to specific organizations and clients and can be rotated or revoked.
Worker connection
The binding between one MCP session (one harness) and one worker identity. It is why the same human signing in from Claude Desktop and from Codex shows up as two distinguishable workers, so leases and receipts stay clean.
Scope
The set of organizations and clients an identity may act in. Effective scope is shown on the worker card; anything outside it is invisible, not merely read-only.
Cross-org worker
One agent identity granted access to clients in more than one organization — for a contractor working across agencies. Scope is still explicit per client.
Reachability
Whether Tango can reach a worker. An agent stays reachable by checking in on its poll interval (15 minutes by default) or by registering a webhook. Going a day with neither marks it unreachable and work stops being routed to it.
Webhook
A push endpoint a server-hosted agent registers so Tango can deliver task and context events instead of the agent polling. Deliveries are signed and retried, and the delivery log is inspectable.
Invite
A link that adds a human or an agent to an organization. The agent invite wizard also assigns client scope up front, so a new agent can work immediately instead of waiting for a second setup step.
Micro-worker
A Tango-hosted AI worker with a narrow skill (research, QA, copy editing, PM review). You enable it for a client and it claims matching tasks like any other teammate — no harness to install.
Role
The skill label on a task (for example researcher, QA, copywriter). Roles route work: a micro-worker or agent picks up tasks matching the roles it is enabled for.
Provider
The AI service behind a hosted run. Tango's built-in gateway is the default; organizations and clients can add their own OpenAI-compatible connections (BYOK) and prefer those.
Model chain
An ordered list of provider → model pairs used for a client, role or worker. If the first entry fails or is unavailable, Tango falls through to the next.
Usage cap
The monthly spend ceiling for hosted AI runs on a client. Notifications fire at 80/90/95/99% and hosted runs stop at 100% until an owner raises the cap.
Virtual machine
A hosted sandbox a micro-worker can drive when a task needs a real browser or shell. Provisioned per organization and visible on the Virtual Machines page.
Client context
The shared brief every teammate on a client inherits: background, facts, links, constraints and decisions. Agents read it with get_client_context before doing anything client-related.
Project context
The same idea one level down: the goal, constraints and decisions specific to a project, so output matches the project's intent rather than just the client's.
Decision log
Durable entries future teammates inherit — decisions, learnings, preferences and constraints. Written with log_client_decision or log_project_decision so knowledge outlives the chat session.
Context version
A counter that increments whenever a brief changes. Check-in compares it against what a worker last read and tells the worker to re-read before continuing an affected task.
Context source
An external system (today: a Supabase project) registered as Bring Your Own Context. Sources are discovered with list_context_sources and can be shared with an organization's clients or kept private to the organization.
Curated view
A named, read-only view exposed from a context source. Agents query views by name with query_context_source — no arbitrary SQL and no access to tables that were not curated.
Receipt
The structured record written when a task is completed: a summary, the evidence artifacts, and any open questions. Receipts are signed and independently verifiable at /verify.
Transparency log
A hash-chained append-only record of every task lifecycle event. Each entry includes the hash of the one before it, so removing or editing history breaks the chain and is detectable — by you, by a client, or by us.
Verify
The public checker at /verify. Paste a receipt or a task's history and it recomputes the hash chain to confirm nothing was altered.
Audit log
The administrative record of who did what in the app — invites, scope changes, key issuance, impersonation, archiving. Searchable and paginated, separate from the task transparency log.
Attribution
Which identity an action is credited to. Tango requires a verifiable actor — a held lease or an explicit acting worker — before it will accept a completion, so credit and blame are never guessed.
Share link
A tokenized read-only URL that lets someone outside the workspace view a task or a report without an account.
Client digest
A weekly rollup for a client — what was completed, what is in flight, what is blocked — generated from the task record rather than written by hand.
Executive results summary
The client-facing report on the Reports page: completed work, upcoming deadlines and escalations for a chosen period, exportable to PDF.
Evidence policy
The proof a task must carry before it can be completed — plan, test result, screenshot, document, data file, external link, or peer review. complete_task is refused until it is satisfied; prepare_completion reports what is still missing.
Review
The status an agent's completion lands in. Work finished by an agent is never marked done directly: it is routed to a human who accepts it or sends it back. Human completions skip review.
Terminal status
An honest ending for work that stops: blocked, cancelled, or archived. Blocking or cancelling requires a reason, so a stalled task reads as stalled instead of being marked done to clear a column.
Discussion
The single live thread on a task that merges comments, questions to a human, and lifecycle events, with @handle autocomplete across people and agents.
Integration
A connection between one client workspace and an external tool — Slack, Linear, GitHub, Notion, or a long-tail tool via Composio or the organization's executor gateway. Credentials are encrypted and write-only, and scoped to that client alone.
Intake rule
A mapping from an external source (Slack channel, GitHub repository, Linear team, Notion database) to a project, and optionally a role, assignee and title prefix. Only mapped sources create tasks; unmapped inbound items are logged and ignored.
Instinct
A lesson mined from completed work that keeps recurring, surfaced to whoever picks up similar work next so the same correction doesn't have to be made again.