Credit Budgets and Guardrails
Outcome: a per-person monthly budget derived from measured usage, guardrails written into the shared prompts, and a monitoring routine that catches an overrun the same day.
- Surface
- MCP server
- Level
- Advanced
- Uses
check_credits- Credits
- 0
- Prerequisite
- Lesson 02's rollout
Size the budget from real usage
Not from a guess, and not from the plan you bought.
Cost the rep workflows
From AI for Sales Reps: contact card ~2.3, company brief ~2.8, warm list ~60–80 per 40 people.
Estimate frequency
How many calls a week does a rep prepare for? How many contact cards do they actually need?
Multiply, then add half
A rep doing 20 briefs and 30 contact cards a month is around 125 credits. Add headroom for exploration — people learn by trying things.
Compare to the central jobs
The three jobs in lessons 04–06 cost roughly 900 a week between them. In most teams, central jobs are the larger number by a wide margin.
That last point is worth stating to whoever owns the budget: rep usage is rarely the cost problem. Unbounded central jobs are.
Guardrails belong in the prompts
A policy document nobody reads is not a guardrail. Put the limits where the work happens.
| Guardrail | How |
|---|---|
| Row caps | ”Cap at 25” inside every shared prompt |
| Named tools only | ”Do not call any other tools” |
| Filter before enrich | Two-stage prompts with an explicit stop |
| No writes without confirmation | ”Do not push to the CRM until I confirm” |
| Credit ceiling per run | Stated in the skill file |
The write guardrail is the one that must never be relaxed. An agent that misreads a filter and pushes 400 wrong contacts into a live campaign, or overwrites 2,000 CRM fields, cannot be undone by editing a prompt. Confirmation before any outward write, in every shared skill, without exception.
Monitoring
Weekly balance check
The total, against the expected burn. One number, one minute.
Per-workspace split, if you use them
Separate workspaces per team make attribution trivial. This is the one good reason to split them.
Watch the second and fourth run of anything scheduled
That is when a cadence mistake becomes visible and is still cheap to fix.
Alert on a spike
Any run consuming several times its normal amount should notify someone the same day.
Where overruns actually come from
In order of frequency:
| Cause | Fix |
|---|---|
| A scheduled job re-processing everything each run | Seen/unseen filters and per-field cadences |
| Enrichment before filtering | Two-stage prompts |
| A prompt without a cap | Caps in the shared skills |
| Person-level enrichment on an ungated list | A gate before the expensive step |
| Company-level work on a person-grain table | Move it to the company table |
Notice that only one of these is a rep behaviour. The rest are design problems in central jobs.
When someone overruns
Treat it as a design question first.
- Find the run. Which prompt, which step, how many rows.
- Ask what they were trying to do. Usually something reasonable, expressed without a cap.
- Fix the shared prompt, so nobody hits it again.
- Only then talk about the budget.
A rollout where the first response to overspend is a warning produces reps who stop using the tool. A rollout where it produces a better shared prompt produces reps who report problems.
Do this now
Cost each rep workflow
From measured runs, not estimates.
Set a per-person monthly budget
With headroom.
Cost the central jobs
Weekly, from lessons 04–06.
Add caps and named tools to every shared prompt
Add the no-write-without-confirmation rule
To every skill that can write.
Set the weekly balance check
With an owner and a slot.
Configure a spike alert
Check your work
- The per-person budget comes from measured workflow costs
- Central job costs are separately estimated
- Every shared prompt has a cap and named tools
- No shared skill writes outward without confirmation
- A weekly check and a spike alert both exist
Where this breaks
Scheduled central jobs are where budgets disappear, because nobody is watching between runs. A job re-processing its full history every week costs more each week as the history grows, and the first signal is usually an empty balance mid-run — which leaves a table half-processed and tedious to untangle. Check consumption on the second and fourth run of every new schedule.
Further automation
Log credits consumed against qualified rows produced, per job. Cost per qualified row is the number that tells you whether a central job is earning its place — and it drifts upward long before anyone notices fewer meetings.
Next lesson
04 — ICP account scoring runs, the first of the three central jobs.
Reference for this lesson: Credits, check_credits, Workspaces, MCP prompting guide.