Tasks & projects
Tasks & projects
Every request and event in Pump Up belongs to a task, and every task belongs to a project. Together they’re how work is grouped, routed, and tracked.
Projects
A project groups related work and routes it to the right ops team. It’s created ahead of time in the dashboard — its project_name is a stable slug (lowercase, derived from the display name) that your agent references on every call. Every account starts with an undeletable General project (slug general).
A project also declares a step graph — the states a task moves through (e.g. in_progress → complete), modelled as a Kanban-style adjacency list where each step names the steps reachable from it. A task enters at the initial step and advances as events transition it; a step with no exits is terminal.
Discover projects and their step graphs from the API:
Tasks
A task is the case or run — one claim, one onboarding, one conversation. It groups events into a timeline and holds an immutable human name, a current step and status (RUNNING, WAITING, or CLOSED), a governed metadata bag, and a named attachment set.
Create a task before sending anything against it — there’s no implicit task:
A task id is a platform id returned by tasks.create, not a string you choose — so two agents can’t collide on a shared key. external_id is your own correlation token (not unique, not resolved).
Bounded workflows are one project with many tasks (one per case); a long-running agent pins to a single task created up front.
Reading a task back
tasks.get returns the task’s materialised state plus its open requests — any approval or elicitation still awaiting a human:
To catch up on everything that happened — including the human decisions a fresh agent session wasn’t party to — tail the task’s event timeline.