How Polo works
Every task follows the same loop. A request arrives, a supervisor plans it, agents work with exact tools and budgets, any change is proposed as one exact operation, a person approves it, a runner executes it, a separate read verifies it, and the task reports the evidence and the cost.
1. A request arrives
Section titled “1. A request arrives”Work comes from the Ask Polo box, a chat mention, an assigned ticket, an alert, a failing uptime monitor or a schedule. Each accepted request becomes one task. Tasks run independently, so unrelated work proceeds at the same time. See Give work to Polo.
2. The supervisor plans
Section titled “2. The supervisor plans”Each workspace has one supervisor, named Polo. It takes every request that names no agent (the Polo decides choice), gives each part to the right agent on its team and reviews the result.
The supervisor has no tools of its own. It needs at least one agent that holds tools. When you name an agent, that agent takes the whole task.
3. Agents work with exact grants and budgets
Section titled “3. Agents work with exact grants and budgets”Each part of a task runs with one agent’s own tools and rules. An agent may create helpers for a narrow job, such as an investigator or a verifier. Every helper gets:
- an objective and acceptance requirements;
- only the tools it needs, never more than its parent holds;
- a model, a budget taken from the parent’s remaining allowance, and a deadline.
The platform checks these before anything runs. The model plans the work; it does not decide its own permissions. A task cannot exceed its budget by delegating or retrying. Limits on helpers, tokens and time are shown on each agent’s card under All limits.
Reading is done directly. An agent reads source in its own workspace copy, reads connected systems through its granted tools, and searches the knowledge it may see. When information is missing, it asks a question and waits. See Agents.
4. A change is proposed as an exact operation
Section titled “4. A change is proposed as an exact operation”Anything that changes a system outside the agent’s workspace copy is proposed, not done. The proposal names the system, the target and the content: for example the saved Terraform plan to apply, or the machine to restart and the state it should end in.
5. A person approves, or a standing approval covers it
Section titled “5. A person approves, or a standing approval covers it”The proposal appears on Approvals under Waiting for you.
- The approval is bound to that exact operation. If the plan changes, a new approval is needed.
- An approval expires. A change bound to a saved plan cannot be approved after the plan expires; Polo must plan again.
- Settings → Approval rules sets who must approve changes in each environment. A rule can require an approver other than the person who asked.
- An administrator can add a standing approval for one exact change. Polo then makes that change without asking and records that the rule approved it.
Rejecting a change does not end the task. Polo reads the reason and continues. See Approvals and guardrails.
6. A runner executes
Section titled “6. A runner executes”The approved operation is carried out by a runner: a small Polo program that holds the access to your system. It can be Polo’s default runner or one you run inside your own network. Credentials are used by the runner and are never given to the model. See Runners and vault.
7. A separate read verifies
Section titled “7. A separate read verifies”After the operation runs, Polo reads the system again and compares what it finds with what was approved. A Terraform apply is followed by a refreshed plan that must show no changes. A machine change is followed by a fresh read of the machine.
If the outcome cannot be confirmed, the task says so. A request whose answer was lost is shown as unknown and is not sent again.
8. Evidence and cost are reported
Section titled “8. Evidence and cost are reported”The task ends with what happened in one sentence, the changes and what became of each, the evidence Polo read, any artifacts such as reports or plans, and the cost. Model spend is shown per task. A model without a price is counted in tokens and never shown as $0. See Artifacts and Models and spend.
When Polo stops
Section titled “When Polo stops”Polo stops with an explanation when access, information, budget or a supported capability is missing. A failed task shows a plain reason on Tasks, and Home lists it under Needs you.
For the technical detail of each step, see Task lifecycle and Operation contract.