I Started Using Paperclip. Now I Burn Millions of Tokens

A few weeks ago I was talking to my colleague Rick Roque about my agentic company.

If you have been following this blog, you know the company already existed. Cursor is Number One. I wrote about that in I’ve turned Claude into my first officer. Under it I have agents doing IT, Marketing, Security, and other jobs, some running on Tanzu, some on Kubernetes, and some on an old laptop that has somehow become part of the corporate infrastructure.

The agents talked on Slack. I had the setup in departments. I gave them jobs. What I did not really have was a company. I had a collection of agents and a very large pile of Markdown files explaining to those agents how the company was supposed to work.

Rick told me to look at a project called Paperclip.

The company was living inside the agents

Before Paperclip, most of the organizational logic lived in the instructions themselves.

Number One knew that when something belonged to IT, it should go to IT. IT knew what it was responsible for. Marketing knew what it was responsible for. There were rules for handing things down, rules for reporting things back up, rules about what happened when something failed.

It mostly worked. But my org chart was basically a text file.

The workflow engine was a text file.

The escalation policy was a text file.

I have written before about SOUL.md, and about turning my primary agent into Number One from Star Trek. I genuinely think agent identity matters. Giving an agent a clear role changes how it communicates and does things and, at least for me, makes the entire interaction better.

But then you add a rule. Then another. Then something goes wrong, so you add a paragraph explaining that. Then the agent does something stupid at 2am and you add another VERY IMPORTANT instruction so it never does that again.

Eventually you open AGENTS.md or SOUL.md or CLAUDE.md (insert your favorite agent du jour) and discover that you have written a small autobiography mixed with an employee handbook mixed with a runbook.

When an agent did something wrong, my natural reaction was to make the instructions more specific, like this:

Don’t do X.

Always do Y.

Except when Z happens.

When Z happens, do this instead.

Humans write procedures this way all the time. The problem is that an LLM is not executing that file like code. It is context. The more I stuffed into that context, the more opportunities I created for instructions to compete with each other.

The specific instruction often wins over the general one. Something I added six weeks ago to solve one particular problem could suddenly influence a completely different task. Rules about identity sat next to operational procedures. Company structure sat next to reporting style. Standing orders sat next to examples.

Everything was technically written down, but not everything was being followed.

I had accidentally built the agent equivalent of a 400-page employee handbook and then wondered why nobody remembered page 317.

Paperclip forced me to look at this differently.

Paperclip became the desk

The first change was organizational. Instead of making the agents themselves remember how work moves through the company, Paperclip gives the company somewhere for the work to live.

The easiest way to think about it in my environment is as the company’s desk. Work is a ticket. It has an owner. It has a parent and a child. One ticket can block another.

Number One will receive something and hand the actual work to IT. IT does the job, reports back on its issue, and the parent, which is Number One, can close when the dependency is actually finished.

So instead of an LLM trying to be a ticketing system based on Markdown files, I now have a ticketing system.

This matters because if Number One delegated something to IT, the state of that delegation used to exist partly in the conversation, partly in Markdown, partly in Slack, and partly in the agent’s understanding of what was happening.

Now there is an object to follow.

IT owns ticket INS-58.

When IT finishes, Number One wakes up and verifies the result, and the organizational state is outside the model.

Then I cleaned up the brain

Once the organizational structure moved out, the files started looking ridiculous.

Why was Number One’s identity file explaining how departments work?

Why was a role file carrying operational procedures?

Why were permanent facts sitting beside temporary instructions?

Why did every agent need to read everything?

So I started breaking it apart, with the help of my loyal Number One.

The principle is very simple:

One file should have one job.

Identity is identity.

Role is a role.

Company structure is company structure.

Standing orders are standing orders.

Operational knowledge belongs with the operation.

Department knowledge belongs with the department.

And a task should pull in the things it needs rather than carrying the entire history of the company into every inference. Boom, now my agents started working.

My local model on the DGX finally got to work

This produced a very welcome effect, which is that my local model started working. A lot.

I have written before about the DGX Spark and my determination to make the thing earn its keep. It runs my local models behind Ollama. These days that is Qwen 122B, with Llamagate in front so I can see what is actually happening.

The agents that were wired to the local model, Hermes and Tanzu and the rest, did not work efficiently, because everything was working off disorganized Markdown files, which I explained in the previous part.

Once the departments had Paperclip heartbeats and actual work could arrive without me sitting there initiating it, the utilization changed dramatically.

Before the department timers came on, I was seeing roughly ten local-model runs in a day and around thirty thousand tokens.

Once the Paperclip timers came on I have recurring tasks and reports, beyond the sporadic work I give the company, and now it stands at millions of tokens of quality work a day.

Same hardware.

Same model.

The difference is that work started arriving without me carrying it there.

That is the main reason I am writing this post. You can see the utilization of my DGX in real time on the top of my homepage and more extensively on the lab page.

It is definitely not magic

There have been plenty of problems. More than I can count.

I had agents wake on the wrong ticket.

I had a department report on a parent while the child it was supposed to work on sat untouched.

I had agents leave a task without producing the file they were supposed to produce.

At one point the reporting wrapper was effectively saying “IT left without finishing” even when the agent was Marketing, which is the kind of thing that makes your imaginary company feel remarkably like a real company.

I also discovered what happens when several autonomous departments decide they all want the local GPU at once, when four Hermes wake-ups could fill the only Qwen slot with 30K-token prompts while I was trying to talk to the interactive Infra agent. That did not bode well.

So now I had to implement prioritization on Llamagate so interactive work beats background corporate work.

Llamagate now has priorities. A human conversation can preempt a Paperclip background job, and after the interactive request finishes the background work gets the GPU again.

This is the part I enjoy about building this stuff. Solve the agent problem and discover the scheduling problem.

Solve the scheduling problem and discover the context problem.

Solve the context problem and discover that Marketing has been pretending to be IT for three hours.

The big lesson is structure

I started looking at Paperclip because Rick showed me an interesting agent orchestration project. I ended up using it to remove organizational responsibility from the agents themselves, and to remove a bunch of other responsibilities from their identity files.

The old architecture asked the model to know too much. Who you are, who everyone else is, how the company works, where work goes.

That is not really an agent architecture.

The system I have now is much more boring, and much better.

Paperclip knows the work.

The org files know the company.

The role files know the job.

The identity files know the person.

The department files know the department.

The operational files know how to operate things.

And the model gets to spend more of its context doing the actual task instead of reconstructing my company from prose. I think that is the direction I am going to keep pushing this.

And my local model is doing more work now than it ever has.

That seems like a useful lesson.

More on this as it develops.