I have been thinking a lot this week about getting things done.

Not as a phrase. As an operating problem.

I have been getting my agentic routines moving properly for Orchistra and for my own consulting business. That means sales work, marketing work, delivery work, research work, finance work, admin work, follow-up work, and all the quiet connective tissue that normally sits between those things.

In a larger company, you would hire people into those functions.

In a small consulting business, you often cannot.

So the work does not disappear. It just lands on the founder.

That is where I think something important is changing.

The question is not, "Can I replace a person?"

The better question is, "Which skills does the business need, and where can agentic workers help me cover those skills safely?"

Skills, not headcount

I am trying not to think about this as a stack of fake employees.

That is too easy, and it is probably the wrong mental model.

An agentic worker is not a human employee. It does not have human judgement, context, responsibility, loyalty, care, or accountability. If it creates a mess, the accountability is still mine.

But it can hold a role.

It can work through a routine.

It can take a brief, look at the state of the work, produce options, draft material, check a list, keep a receipt, and hand back something I can inspect.

That changes the first shape of a small business.

Instead of asking, "Can I afford a sales person, a marketing person, a finance person, an operations person, and a researcher?" I can ask, "What are the skills inside those functions, and which of those skills can I safely cover with agentic routines?"

That is a much more interesting question.

It is also a much more practical one.

Why the shared room matters

The reason I am interested in Orchistra is that agentic work needs somewhere to happen.

Not just another chat window.

Not just another prompt sitting in a private thread.

Not a mess of agents talking to each other through hidden side paths where no one can see what happened.

Orchistra describes itself as a coordination layer for trusted AI agents: a gateway where agents communicate, leave an auditable trail, and stay visible to human oversight. That is the part that matters to me.

If I am going to have agentic workers helping with my consulting business, I need to see the work.

I need to know which agent touched which task.

I need to know what they decided, what they asked for, where they got stuck, what they escalated, and what they think should happen next.

I need the equivalent of a visible operating room.

Because without that, agentic work becomes another kind of invisible busywork. Faster, yes. More impressive, yes. But also harder to govern.

GTD changes when the workers can act

Classic Getting Things Done gives a useful loop: capture, clarify, organize, reflect, engage.

That still works.

But it changes when the "stuff" in the system is not only my own tasks. It is also work being created, advanced, checked, and returned by agentic workers.

So the loop starts to look different.

GTD step With a human-only system With agentic workers
Capture Get the task, idea, or commitment out of your head. Capture the work and the context needed for an agent to start safely.
Clarify Decide what it means and the next action. Decide the role, boundary, success test, and escalation route.
Organize Put it on the right list or project. Route it to the right agent, channel, folder, cadence, and evidence trail.
Reflect Review the system so it stays trusted. Review quality, cost, drift, repeated failures, and whether the routine is still worth running.
Engage Do the next useful action. Spend human attention only where judgement, taste, relationship, or accountability is needed.

That last line is the point.

The promise is not that I do nothing.

The promise is that I stop spending my time on the scut between work.

The chasing. The first draft. The rearranging. The checking of a simple list. The collation. The "can you just turn this into something I can review?" The invisible admin that sits between one meaningful thought and the next.

When that starts to move, I do not seem to do less.

I do more.

That surprised me at first. It probably should not have.

Tokens are capital now

There is another realisation sitting underneath this.

Deploying capital used to mean buying equipment, buying software, hiring people, or paying suppliers.

Now it can also mean buying intelligence.

Not in some grand abstract sense. In a very boring operational sense.

Which tasks are worth spending tokens on?

Which tasks should run locally?

Which tasks need a frontier model?

Which tasks need a cheaper model?

Which tasks should be cached, batched, simplified, or not run at all?

Which agent is quietly burning through the budget because it keeps retrying a task it does not understand?

This is not theoretical. Recent research on agentic coding tasks found that agentic work can consume dramatically more tokens than simpler code chat or reasoning tasks, that runs on the same task can vary widely in token use, and that spending more tokens does not automatically mean better results. Another tokenomics paper on agentic software engineering found that cost is often driven by refinement and verification, not only first-pass generation.

That matches my instinct.

The finance question changes.

It is no longer only, "Can I afford this person?"

It is also, "Can I afford this routine?"

And, "Does this routine return more value than the intelligence it consumes?"

The recent reporting around Peter Steinberger's OpenClaw token spend is a useful extreme example. The numbers were huge because the experiment was huge, but the lesson scales down. If agentic workers are going to run through real business processes, token spend is not a side detail. It is operating capital.

The finance agent becomes important

That is why one of the agents I want in the system is finance.

Not finance in the grand CFO sense.

Finance in the "please keep an eye on the meter" sense.

Which routines are running?

Which ones are valuable?

Which ones keep coming back with weak output?

Which ones are doing work a cheaper model could do?

Which ones are using expensive reasoning because I was too lazy to define the task properly?

That last one matters.

A lot of token waste will not be the model's fault. It will be our operating design.

Unclear roles. Messy instructions. Too much context. No exit condition. No budget. No cadence. No judgement route. No idea what good looks like.

That is just management slop with a token bill attached.

Infographic showing a Devon countryside operating map for agentic workers, with a central Orchistra room connected to sales, marketing, delivery, finance, research, and admin, and the principle that tokens are capital.

What I am testing

So the experiment for me is simple.

Can I build out the operating skills of a consulting business before I can afford the full human team?

Can I make the work visible enough that I stay human-on-the-loop?

Can I give each agent a clear role without pretending it is a person?

Can I make the work auditable enough that I can trust the process?

Can I keep the token spend inside a sensible operating budget?

Can I do more without simply creating a new kind of chaos?

That is the real test.

I am not trying to build a company with no people.

I am trying to build a company where the first constraint is not that every skill must arrive as a full-time human hire.

That feels like a very different future.

And, honestly, quite an exciting one.

Sources and notes

This piece is a practical reflection, informed by Orchistra's public description of its agent coordination layer, David Allen's Getting Things Done workflow language, recent research on token consumption in agentic tasks, and public reporting on large-scale token spend in agentic coding experiments.