Agency OS
Plans and blueprints
How an agent proposes changes to your workspaces from a blueprint or template, and how you review, approve and apply them.
The Plans screen lists changes an AI agent has proposed for your client workspaces, such as setting up a new workspace with its team and tokens. Nothing in a plan is written until it is approved.
Who can open it
Any member of an agency on the Pro plan can see plans. Only an agency operator can approve or reject one.
Blueprints, templates and plans
A blueprint describes a whole workspace: the workspace itself, its team, its rates and the rest of its setup. A template is a blueprint saved under a name so it can be reused. Templates are versioned, and your agency can use its own templates or ones PYLO provides.
An agent makes a plan from a template plus the client's details, or from a whole blueprint. The plan lists every change it would make, marking each as a create, an update, already in place, or blocked with the reason. Making a plan writes nothing.
An agent needs an agency token with Plan to make plans. If its token also has Apply, it can apply a plan without anyone approving it. Otherwise the plan comes here. You issue these tokens in Agency settings.
What a blueprint can carry
Besides the workspace, its team and its rates, a blueprint can set:
| Section | What it holds |
|---|---|
| mode | Parallel or live, for the whole workspace and piece by piece. The same switch as the workspace's own mode, so switching anything to live still needs a person to approve it. |
| approval_policy | How each class of plan is approved in this workspace: applied straight away (internal changes only), by a code, or in the app only. An agent never changes this on its own: the plan applies only once an owner approves it here. |
| sales | What each call outcome sets in the CRM, who files the form for a no-show, the reason lists, the commission basis (recorded, verified or after fees), the end-of-day cutoff, the order of each call list, the dialing cadence, the sales-ops jobs and whether they name people in a channel, deductions, and how far a typed figure may differ from the logs before it is flagged. End-of-day questions listed here are added to the end-of-day forms. |
| team | The members, and the rules the team runs on: roles, levels, pay rules, which access each role gets in each tool, and what happens when someone leaves (their access revoked and their work reassigned, never deleted). A plan that changes pay rules is money, so a person approves it. |
| stack, provision, naming | The tools a client runs on and the templates that build them. See Stack and provisioning. |
Your agency's own templates carry these sections too, versioned with the template. When a template changes, the agent plans the change for each client on it, one plan each, never silently.
Reviewing a plan
- Open Plans in the sidebar. Plans waiting for approval come first, each with its workspace, state, template and age.
- Click a workspace name to open the plan. The header shows its state, the template and version, and when it expires.
- Read the list of changes, each showing the value before and after.
- Press Approve and apply, or cancel and then press Reject it. Rejecting writes nothing, and the agent has to make a new plan.
The plan page also shows what approving will skip under Not yet, each with what has to happen first, how many things are already as the plan wants, and anything kept as it is, because a plan never deletes. If a plan writes nothing at all, press Close it.
After approving
PYLO applies the changes in order. If one fails, it stops there and the plan shows which change failed and why. If the plan issued tokens, they are shown once under Tokens issued; copy them straight away, as PYLO keeps only a fingerprint.
Plan states
| State | Meaning |
|---|---|
| Waiting for approval | Ready for an operator to decide |
| Applied | Every change was written |
| Stopped at a failure | Applying stopped partway; the plan says where |
| Rejected | Declined, nothing written |
| Expired | Not decided in time |
| Out of date | The workspace changed after the plan was made |
For an expired or out of date plan, ask the agent to plan again. See The Claude plugin for working with agents.