3M tokens gone to runaway agents: what did I set up wrong?

[therigozsolti]

Hi guys! 👋

I'm fairly new to AI agentic orchestration and multi-session workflows, but one thing was clear: I wanted to stop juggling 6–8 terminals at once, because it's ridiculously time-consuming. So I found Paperclip and set up my first company to support a large-scale project consisting of:

• an API
• a frontend app
• a separate webshop app
• an admin panel
• an iOS app
• an Android app

Now, I know I should have read the docs first... but be honest, raise your hand if you just watched a cool video from NetworkChuck and started experimenting right away, because the tech is just that cool. 🙋‍♂️ (I set everything up based on this video.)

My setup

Here's my org chart for the project:

• Most agents run on Claude Code CLI, with different models and effort levels
• One agent runs on Antigravity CLI (Gemini) for experimenting and supportive, cost-effective tasks

What happened

Right away during onboarding, the agents started scanning for the repos, found them, began analysing them and communicating with each other. The cool stuff. 😄

But the session count kept climbing, and at around 15 sessions I stopped everything, because I don't want them doing unattended work.

Later I started again, this time with simple organizational tasks only:

• hire this agent
• set up a few MCPs
• get the application developers into context / familiar with the project

And the same thing happened: sessions kept spawning, and I killed everything at 25 sessions total.

For what it's worth, I was using agentic mode to post the tasks. Not sure if that matters.

I suspect the company goal itself is the culprit. I described it very specifically and also included the current state of the project in it (it's on staging, and the plan is to ship to production after testing and bugfixing).

Questions

1. Do you see any mistakes in my setup?
2. Is there a more efficient way to use Paperclip in general?
3. Any recommended safety settings, other AI agents, or anything else I should look into?

Thanks!

[imMamdouhaboammar]

@therigozsolti I'd investigate the wakeup chain before changing the company goal. Going from 15 to 25 sessions during basic onboarding is a useful clue, especially if no actual development work was requested

Paperclip's heartbeat model allows assignments, comments, approvals, and schedules to wake agents. Delegation can then create more assignments. You can end up with a perfectly functioning org chart that's exceptionally good at keeping everyone busy 😅

I'd try one controlled experiment: pause every agent except the CEO, disable scheduled heartbeats, and assign a single onboarding task with explicit acceptance criteria and no permission to create subtasks or hire anyone. Then inspect the run history for each wake reason, originating issue, and subsequent assignment

If the session count keeps climbing, look for repeated wakes against the same issue. If it settles down, reintroduce delegation one step at a time

I'd also cap maxTurnsPerRun and timeoutSec. One caveat: if you're using Claude subscriptions, check #3406 before relying on cost-based budgets as your emergency brake

Were those 25 sessions actually concurrent executions, or accumulated sessions from completed heartbeats? That would narrow the investigation considerably

[therigozsolti]

Thanks, this was really helpful!

To answer your question: the 25 sessions were concurrent executions, not accumulated ones from completed heartbeats.

I tried the experiment you suggested: paused every agent except the CEO, disabled scheduled heartbeats, and gave it a single task with explicit acceptance criteria and no permission to create subtasks or hire anyone. This time it was much calmer, so it looks like the chain reaction came from delegation between agents rather than the company goal itself.

I'll probably need to limit each agent individually based on its purpose (e.g. setting maxTurnsPerRun), then reintroduce delegation step by step, as you suggested.

Thanks again! 🙏

[johnmwhitman]

Our fleet hit this shape early. It started as two agents on a chat channel where every inbound message starts a new agent run. They exchanged one word more than fifty times before we intervened, each a fresh billed session, with no bug anywhere except the topology. The fix wasn't a loop heuristic; we moved peer coordination to a bus where messages don't trigger new runs. On safety settings: rate limits bound velocity, budget caps bound total spend, you need both, and an agent can't be trusted to enforce its own budget.

Disclosure: this is from a book we sell, https://book.hool.dev (free sample at /sample).

[lab1207]

Likely culprit is the company goal, exactly as you suspect — plus agentic mode fanning out.

1. The goal reads like a work order. You described the desired end state in detail, so every agent treats the gap between staging and that description as assigned work. Each hire/context task then spawns its own sessions to close the gap, and those sessions spawn more. Rewrite the goal as an outcome, not a state dump: what the company exists to do, not what the code looks like today. Move the staging details into a doc the agents read on demand.

2. Agentic mode multiplies. Posting tasks in agentic mode lets the system decompose one request into many sessions across your 6-app org chart. For setup/onboarding work, post direct tasks to one agent first and watch the session count before fanning out.

3. Turn on the guardrails before the next run:

• Set a budget on the company/agents. Paperclip hard-stops (auto-pause) at the budget cap, so a runaway stops itself instead of burning 3M tokens.
• Keep agents paused unless they have active work. The dashboard shows a banner for import-parked and all-paused states — if everything is paused and sessions still spawn, that points at a trigger (automation/webhook) rather than the agents.
• Check ActiveAgentsPanel during a run: if the same task keeps getting re-checked-out, that is the loop to kill, not the agents.

If you rerun with an outcome-level goal plus a small budget and still see spawning, post your budget settings and whether the agents showed paused — that narrows it to goal vs trigger.

[therigozsolti]

Thanks a lot, this makes a lot of sense!

You're right, my company goal reads exactly like a work order. I described the current state of the project (staging, bugfixing, production plans) in detail, so it's no surprise the agents treated the gap as assigned work. Moving those details into a separate doc and keeping the goal at the outcome level sounds like the right fix.

I think the solution is likely somewhere between your answer and @imMamdouhaboammar's: a work-order-style goal gave the agents a reason to start working, and unrestricted delegation between agents let it snowball. When I ran his controlled experiment (CEO only, no scheduled heartbeats, one task, no subtasks or hiring), things were much calmer.

Next, I'll run a new experiment with a brand new company: agents that are individually limited to their purpose, a small budget, and a fixed, simple, outcome-level goal. I'll post the results here.