Glossary
The terms Polo’s app, documentation and code use, in alphabetical order. Where the code uses a different name from the app, both are given. For a guided introduction, start with Key terms.
Acceptance criteria: The conditions a specialist’s result is judged against. The supervisor writes them when it delegates, and reviews the evidence against them.
Access token: A token a member creates under Settings → MCP access so an MCP client or the plungo command line can work as that member. It is read only or read and act, with a separate switch for approving changes.
Agent: A named Polo in a workspace with its own model, budget, instructions and tools. The code calls it a Polo profile.
Agent specification: The immutable record of what one agent run is allowed to do: its objective, grants, model route, budget and deadline. The control plane writes it; the model cannot change it. In code, AuthorizedAgentSpec.
Approval: A person’s decision that one exact operation may run. It is bound to that operation, its target, its arguments, the plan or digest it applies, and an expiry.
Approval rule: A workspace setting, per environment, that says who may approve, how many approvals are needed, whether requesters may approve their own changes, and how long a request waits.
Approval window: How long a proposed change waits for a decision before it expires.
Artifact: A file a task produced and stored, such as a report or a change bundle.
Binding: A digest of the connection a change was proposed against: its provider, endpoint, registered scope and credential. If the connection changes, the approval no longer applies.
Budget: The most a task or agent run may spend on model calls. A specialist’s budget is reserved out of its parent’s.
Capability: One thing Polo can do on a connection, identified by an ID such as terraform.plan or terraform.apply. Each is either a read or a write.
Capability area: One of the 28 groups Polo’s scope is divided into, such as Kubernetes or Incident response. See Capabilities.
Capability family: A group of capabilities that share a provider, a runner and a purpose. Each family has one maturity level, and an area takes the lowest level of its built families.
Case: One piece of work Polo’s supervisor manages: a task, an incident or a scheduled assignment. In the app it is a task; in code the supervisor workflow is CaseWorkflow.
Cell: A deployment unit that workers are bound to. The control plane refuses commands from a worker of another cell.
Check: A fixed, typed command an agent may run in its sandbox, such as python.pytest or terraform.validate. An agent cannot run arbitrary shell commands.
Claim: A worker’s time-limited hold on a run, renewed while it works. Only the worker holding the claim can write to the run.
Command: A versioned request the runtime sends to the control plane, such as claim, delegate or propose_operation. Commands are idempotent: sending one twice returns the first answer.
Connection: A system registered with a workspace that Polo can reach: a runner, an endpoint, an MCP server, a repository or a linked account. See Connections.
Control plane: The NestJS API in api/. It owns all product state, policy and approvals, and is the only part that writes to the database.
Delegate: See Specialist.
Delegation proposal: What the supervisor sends when it wants a specialist: an objective, acceptance criteria, the tools it should have, a model class, a budget and a deadline. The control plane checks it and either issues an agent specification or refuses.
Dispatch: Sending an approved operation to its runner or provider. It happens once.
Environment: A name such as production or staging on a task or a target. It selects which approval rule applies.
Evidence: The recorded observations a result rests on: tool results, receipts, check output. A supervisor cannot accept a result without citing evidence.
Fence: An identifier issued with a claim that every later command must carry. Canceling a task clears it, so a late command from a stopped worker is refused.
Fingerprint: A digest of everything a reviewer approves: the task, the run, the operation, the binding, the capability, the arguments and the runner’s review. A decision must name the fingerprint it reviewed. For an MCP tool, the fingerprint is a digest of the tool’s definition.
Grant: Permission to use one capability on named resources. Agents hold grants in their profile; a task pins them when it starts; a specialist can only receive a subset of its parent’s.
Guardrails: An owner’s limits on an agent: read-only, allowed environments and services, and things it must never do. The control plane enforces them.
Helper: The app’s word for a specialist.
Incident: A record opened when a monitor fails or an alert arrives, holding the investigation, any remediation and whether the service recovered.
Intake source: A place tasks come from besides the app: Slack, Google Chat, Gmail, Jira, ClickUp or an alert source. Polo identifies the workspace from the authenticated installation, never from the message.
Knowledge: Documents a workspace gives Polo to search: runbooks, service notes, team notes and incident records.
Maturity level: How strongly a capability is proven: planned, implemented, verified locally, verified with a connected provider, or operated in a pilot.
MCP: Model Context Protocol. Polo can use tools from an external MCP server, and Polo is itself an MCP server. See MCP.
Model class: A name in an agent’s profile that maps to a model route. A specialist asks for a class, never for a provider endpoint.
Model route: A configured way to reach a model: a provider, a model and its price, or a subscription.
Monitor: An uptime check that probes a public HTTPS endpoint on a schedule and opens an incident after consecutive failures.
Observation: One recorded result of something an agent did or read. Observations are what evidence refers to.
Operation: One exact action on a connected system, either a read or a proposed change. A change is stored as an operation request and follows the operation contract.
Outbox: A table where the control plane records events for Temporal in the same transaction as the state change. The relay delivers them.
Polo: Plungo’s AI DevOps teammate. Also one agent of a workspace.
Pre-authorized action: An administrator’s standing approval of one exact operation, with a daily limit and an expiry. The app calls it a standing approval. Only operations whose arguments are fully known in advance qualify.
Profile: An agent’s settings: model routes, budget, limits, instructions, guardrails and grants.
Provider: In the control plane, the code that speaks for one kind of connection: it lists targets, reviews, dispatches and verifies. In code, OperationProvider.
Question: A clarification an agent asks a person. The task waits until it is answered; the answer adds context and grants nothing.
Receipt: The record a runner or provider returns for a request: its identifier, status and result. Runners keep their receipts, so a repeated request returns the same one instead of running again.
Reconciliation: Settling an operation whose outcome is unknown by running its verifying read again.
Relay: The control-plane process that reads the outbox and starts, signals or cancels Temporal workflows. Separately, a linked runner relays jobs over its own outgoing connection.
Resource key: The identity of the thing a change acts on. Polo allows one unresolved change per resource key at a time.
Review: The runner’s read-only preview of exactly what a proposed change would do, such as a saved Terraform plan. It is what the approver sees, and it is checked again at approval.
Rework: A further round of planning and delegation after the supervisor’s review did not accept the evidence. Limited to two rounds.
Run: One execution of one agent inside a task. The supervisor has a root run; each specialist has its own.
Runbook: A knowledge document tagged with a service and environment. Alert tasks name the runbooks that apply.
Runner: A small service the customer runs near their systems. It holds the credentials, accepts only signed requests within its configured scope, executes them and keeps receipts. See Runners and vault.
Runtime: The Python worker in runtime/ that runs the supervisor and specialists on Temporal. It holds no database credentials.
Sandbox: A private, offline checkout of a repository at a pinned commit where an agent reads, edits and runs registered checks. Nothing in it reaches outside systems.
Scope: What a connection is registered for: the stacks, databases, namespaces or accounts it may touch. A runner refuses anything outside it.
Skill: Three related things: a typed command that runs in the sandbox, a knowledge document of kind skill that an agent reads as guidance, and a product setup such as the Terraform skill. See Tools and runners.
Specialist: An agent the supervisor creates for one part of a task, with its own objective, tools, budget and deadline. It runs as a child workflow. The app calls it a helper; the code also says delegate.
Standing approval: See Pre-authorized action.
Supervisor: The agent that plans a task, delegates specialists and reviews their evidence. Also the workspace agent that takes a request addressed to no one and hands each part to an agent of its team.
Target: One thing a connection can act on, such as a Terraform stack, a database or a Helm release, with its environment and service.
Task: A piece of work given to Polo. Its status is queued, running, succeeded, failed or canceled.
Team: The agents a supervisor’s task may hand work to, fixed when the task is created.
Tenant: The code’s word for a workspace. Every table row carries a tenant ID, and PostgreSQL row-level security keeps tenants apart.
Unknown: The outcome of a change that was approved and sent when Polo cannot confirm whether it took effect. It is not retried and not reported as failed. See States.
Unresolved cost: Spend that may have happened but was not confirmed, such as a model call whose answer never arrived. It is kept apart from known cost and never counted as zero.
Vault: Named secrets a workspace stores once and uses by name, for example as a connection’s credential. A value goes in and is never shown again.
Verification: A separate read, after a change, that checks the system is in the state that was approved. A change counts as succeeded only when it is verified.
Verifier: For an MCP write tool, the read-only tool that checks its result. A write tool cannot be granted without one.
Worker: A process that does background work for the control plane with its own key: the runtime worker, the scheduler and the watchers.
Workspace: A company’s space in Polo, with its members, agents, connections and tasks. The code calls it a tenant. Separately, an agent’s isolated workspace is its sandbox checkout.