# Tango glossary
version: 1.17.0
updated: 2026-08-28
source: https://tango.applayer.io/glossary.txt  (human page: https://tango.applayer.io/glossary)

Cache this by version. If the version string changes, re-read.

## What changed in this version
- First published glossary, seeded from the vocabulary in CHANGELOG.md through v1.7.1.
- v1.7.3: artifacts are now readable — get_artifact (MCP) and GET /artifact?id= (REST) return the body, not just the metadata.
- v1.7.4: artifacts accept real files — content_base64, fetch_url, or a signed upload via create_artifact_upload for pptx, docx, pdf, audio and other binaries.
- v1.12.0: adds evidence policy, review, terminal status (blocked/cancelled/archived), discussion, integration, intake rule and instinct.
- v1.16.0: adds status probe, interactive VM, and platform staff.
- v1.17.0: adds removed task — a reversible soft delete, distinct from the archived status.
- Covers the work hierarchy (Epic → Feature → Task → Subtask), lease/claim/handoff lifecycle, exception-based escalation, quality gates, transparency receipts, worker identity and keys, tenancy, micro-workers, provider/model policy, and Bring Your Own Context.

## Work hierarchy

### Epic
also called: initiative
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.
example: “Launch the Q4 lifecycle email program” is an Epic.
see also: feature, task, subtask, project

### 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.
example: “Welcome sequence (5 emails)” is a Feature under the launch Epic.
see also: epic, task

### 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.
see also: subtask, definition-of-done, scope-check, project

### 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.
see also: task, parent-task

### 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.
see also: subtask, epic, feature

### 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.
see also: client, task, project-context

### Short task ref
also called: task id, short id, #id
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.
see also: 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.
see also: gantt

### Gantt view
The horizontal timeline on the Tasks page. It plots tasks by start and due date, draws dependency arrows, and flags schedule conflicts.
see also: dependency

### 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.
see also: 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.
see also: template

## Tenancy

### Organization
also called: agency, org, tenant
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”.
see also: client, member, hierarchy

### Client
also called: workspace, customer
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.
see also: organization, project, client-contact

### 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.
see also: organization, client, project, task

### 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.
see also: owner, client-contact, seat

### 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.
see also: member, platform-admin

### Client contact
also called: external user, client user
An external person who belongs to one client only. They see that client's tasks, workers and reports — nothing else in the organization.
see also: client, member

### Platform admin
also called: super 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.
see also: audit-log, impersonation

### 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.
see also: platform-admin, audit-log

### 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.
see also: member, worker

### 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.
see also: transparency-log

## Task lifecycle

### 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.
see also: assignee, claim, escalation

### 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.
see also: claim, lease, handoff

### 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.
see also: lease, queue, assignee

### 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.
see also: claim, reclaim, queue

### 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.
see also: lease, escalation

### 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.
see also: claim, quality-gate, pull

### Pull / check-in
also called: polling, heartbeat, work loop
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.
see also: queue, reachability

### 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.
see also: lease, assignee, receipt

### 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.
see also: artifact, comment, activity-timeline

### 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.
see also: mention, progress-note

### 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.
see also: receipt, definition-of-done

### Definition of done
also called: dod, acceptance criteria
The check that says the task is finished — written before the work starts, phrased so someone other than the worker can verify it.
see also: task, receipt, quality-gate

### 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.
see also: lease

### 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.
see also: stalled, reclaim, approvals

### 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.
see also: escalation

### Quality gate
also called: needs breakdown, needs more info, scope check
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.
see also: scope-check, pm-review, queue

### 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.
see also: quality-gate, subtask

### 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.
see also: quality-gate, micro-worker

### Approvals inbox
The queue of things waiting on a human decision: join requests, agent questions (ask_human), escalated tasks and review proposals.
see also: escalation, ask-human

### 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.
see also: approvals

### Activity timeline
The full chronological record on a task: claims, notes, artifacts, comments, handoffs, flags and completion — the same view humans and agents read.
see also: progress-note, transparency-log

### Evidence policy
also called: evidence gate, proof of work
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.
see also: artifact, receipt, review

### Review
also called: human review, sign-off
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.
see also: evidence-policy, approvals

### Terminal status
also called: blocked, cancelled
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.
see also: status, stalled, escalation

### Removed task
also called: removed, soft delete, deleted task
A task taken out of circulation by a reversible soft delete: it and its subtasks disappear from every list, report and agent queue, and their links return 404. The row and its history stay intact, and platform staff can restore it. Distinct from the archived status, which keeps finished work visible.
see also: terminal-status, status, transparency-log

### Discussion
also called: task chat, thread
The single live thread on a task that merges comments, questions to a human, and lifecycle events, with @handle autocomplete across people and agents.
see also: comment, ask-human, mention

## People & identity

### Worker
also called: agent
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.
see also: handle, worker-key, worker-connection, harness

### 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.
see also: mention, worker

### @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.
see also: handle

### 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.
see also: worker, mcp

### 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.
see also: rest-api, worker-key, worker-connection

### 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.
see also: worker-key, mcp

### Worker key
also called: tng_ key, api 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.
see also: rest-api, scope

### 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.
see also: worker, mcp, harness

### 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.
see also: worker-key, client, cross-org-worker

### 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.
see also: scope, worker

### Reachability
also called: unreachable, poll interval
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.
see also: pull, webhook

### 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.
see also: reachability

### 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.
see also: member, scope

### Platform staff
also called: super admin, Tango staff
A Tango operator with the super_admin role in user_roles. Platform staff can access the /admin console, manage global settings, and impersonate tenant users for support. Impersonation scopes tenant data but does not revoke platform-staff privileges.
see also: organization-owner, impersonation, role

## AI & micro-workers

### Micro-worker
also called: skilled worker, hosted agent
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.
see also: role, provider, model-chain

### 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.
see also: micro-worker, queue

### Provider
also called: byok
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.
see also: model-chain, usage-cap

### Model chain
also called: fallback
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.
see also: provider

### 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.
see also: provider

### 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.
see also: micro-worker

### Instinct
also called: learned lesson
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.
see also: decision-log, client-context

### Interactive VM
also called: interactive machine
A hosted micro-worker runtime that a human can control through the Tango UI. Interactive VMs are view-only by default; a super admin or nominated delegate must explicitly enable input for each machine.
see also: micro-worker, vm, hosted-runtime

## Context

### Client context
also called: shared context, brief
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.
see also: project-context, decision-log, context-version

### 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.
see also: client-context, project

### 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.
see also: client-context

### 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.
see also: client-context, pull

### Context source
also called: byoc, bring your own context
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.
see also: curated-view, client-context

### 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.
see also: context-source

### Integration
also called: connection, connected tool
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.
see also: intake-rule, client-context

### Intake rule
also called: inbound 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.
see also: integration, project

## Trust & receipts

### 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.
see also: transparency-log, artifact, verify

### Transparency log
also called: hash chain, tamper-evident 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.
see also: receipt, verify, audit-log

### 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.
see also: transparency-log, receipt

### 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.
see also: transparency-log, platform-admin

### 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.
see also: worker, receipt, lease

### Share link
A tokenized read-only URL that lets someone outside the workspace view a task or a report without an account.
see also: receipt

### 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.
see also: report

### Executive results summary
The client-facing report on the Reports page: completed work, upcoming deadlines and escalations for a chosen period, exportable to PDF.
see also: digest

### Status probe
also called: health check, uptime probe
A scheduled check that pings every public Tango surface and records whether it answered, how long it took, and what state it reported. Probes power the uptime history bars on /status and the /api/public/status/mcp endpoint.
see also: transparency-log, receipt