/v1/loops, then assign it to one or more agents with assignedLoops on /v1/agents.
Loops are not Missions. Missions orchestrate project work and tasks; loops define how an agent routes its own runtime behavior through deterministic steps.
The runtime contract is ProjectLoopConfig JSON. You can also author a loop as static TypeScript DSL source (export default defineLoop({...})) and pass it as { "source": "..." }; Polpo compiles it to the same JSON before validation and storage. The compiler recognizes the DSL helpers statically. The DSL is an authoring layer, not arbitrary executable orchestration code.
Use type: "tool" for deterministic sandbox/tool actions with no model turn. Use toolChoice on type: "agent" when the model should still reason but must call a tool. Loop JSON must not contain secrets; custom tools read external credentials from project Connections through ctx.connections.
At runtime, Polpo executes the selected project loop as a shared context graph. A tool step writes its result into the context bag at saveAs (or the tool name when saveAs is omitted), and each later agent step receives that context as runtime data in its system prompt. saveAs does not create shell variables; for example saveAs: "timing.start" creates context.timing.start, which later guards and agent steps can read.
When a chat completion or task specifies loop, the loop must be assigned to the target agent with assignedLoops. Loop selection is explicit; omitting loop uses the normal runtime behavior.
Loops can also carry enterprise controls:
permissionsare readable allow, deny, or approval gates for resources such astool,step,model,human, andloop.policiesare expression-based compliance gates for rules that depend on runtime context or payload.hooksrun deterministic tool actions at lifecycle points such asloop:start,tool:before,tool:after, andloop:end.
tool step, a lifecycle hook, or an agent step toolChoice must exist in the project tool catalog and be enabled for the target agent.
List loops
Returns all project-level loop definitions.Get loop
string
required
Loop name.
Create or replace loop
The request body can be either the canonical loop JSON or{ "source": "...TypeScript DSL..." }.
curl
curl
Replace loop
Replaces the full loop definition. The request body uses the same shape asPOST /v1/loops: canonical JSON or { "source": "...TypeScript DSL..." }.
Delete loop
Deletes the project-level loop definition. Agents that still reference the loop should be updated with/v1/agents/{name}.
Run audit
Lists recent loop runs. Filter withloopName, agentName, sessionId, user, status, and limit.
Returns one persisted loop run including status, context, approval state, and trace events.
Approves a loop run that is waiting on an approval gate and resumes execution from the checkpoint.
Rejects a loop run that is waiting on an approval gate.
Permission audit
Lists runtime permission, policy, and approval decisions extracted from loop traces. Filter withloopName, agentName, sessionId, user, kind, outcome, resource, hook, runStatus, and limit.
Use this endpoint to answer why a tool, model, step, human gate, or loop transition was allowed, denied, or sent to approval.
Hook audit
Lists deterministic hook tool calls and results extracted from loop traces. Filter withloopName, agentName, sessionId, user, hook, tool, phase, outcome, runStatus, and limit.
Use this endpoint to inspect setup/finalization hooks, before/after tool hooks, audit hooks, and failed hook executions.
Dashboard governance
Loop Studio includes dedicated audit surfaces:- Run detail shows the persisted trace, context bag, approval metadata, and event payloads for one loop run.
- Permissions shows permission, policy, and approval decisions across runs.
- Hooks shows lifecycle hook executions across runs.
- Governance aggregates recent runs, controls, hook evidence, coverage, and attention signals for GRC review.