Chat Is a Question. Digital Labor Is a Token Budget

A question to a person is cheap. A night shift is not.

That is the distinction most small businesses are missing as they move from “ask the chatbot” to “let the agent handle it.” One is a question. The other is digital labor. They look similar on a screen. They are not similar on a bill, in risk, or in who is allowed to stop the work.

Chat is one pass. You ask. The model answers. You decide whether the answer is good enough. The meter runs once. The human remains the halt owner because the human is still in the room.

Digital labor is a chain. The system plans, calls tools, reads what came back, corrects itself, and may spawn sibling agents to chase the same goal. The meter runs until an outcome appears — or until nobody is watching. That is not a cheaper question. That is overtime with no time clock.

Historically, shops already knew this. You could ask the clerk where the invoice went. That cost a minute. You could also leave a crew in the building overnight to “finish whatever is left.” That cost money, mistakes, and a key. The difference was never intelligence. It was authority, duration, and who could shut the lights off.

Treat standing agent work the same way.

The operating unit is not “AI is cheap now.” The operating unit is a token budget with a halt owner. One request is many decisions. Context grows with the job. Multi-agent work is not a clever trick; it is a multiplier. Creator-cited research numbers will bounce around — four times the tokens for an agent versus chat, fifteen times for a swarm — but the operator lesson does not bounce. Chat, agent, and swarm are different cost classes. If you do not name the class before the job starts, you will discover it on the invoice.

So write the job as a Token Budget Card before you turn anything always-on:

• Token class. Is this a question, a single-agent job, or a swarm? If sibling agents are not required, forbid them.
• Expected loop count. How many plan-tool-observe passes is this allowed to take before it must stop or ask?
• Approval door. Draft is the default. Send, pay, delete, publish, and change live systems wait for a named person.
• Halt owner. Who can kill the loop at 2 a.m. without asking the model for permission?
• Proof artifact. What file, receipt, or test proves the work happened? If the agent can only pinky-promise, it did not finish.

That card is the missing middle between two mistakes.

The first mistake is treating every model call like a chatbot. People paste a goal into a box that can browse, write, click, and retry, then act surprised when a “quick look” burns a day’s worth of tokens and still has nothing they would sign. They did not buy an answer. They hired a crew with no supervisor.

The second mistake is treating cheaper tokens as a reason to loosen the job. When a unit of work gets cheaper, volume rises. Shops that cut the price of overtime did not get less night work. They got more of it, sloppier, with less adult supervision. Cheaper tokens are a reason to tighten the Done Contract, not a reason to let agents generate work for other agents while you sleep.

Unreliability is the cap the market will not say out loud. If the labor cannot be trusted, a lower price does not create a market. It creates a mess that still needs a human to unwind. That is why the honest email example in this week’s signal was not “the bot sent it.” It was draft plus approval — or autonomous send. Autonomous send is the lock-in demo. Draft plus approval is the business.

None of this requires a new vendor, a rented always-on computer, or a branded “digital employee.” Those are packaging. The work is older: instructions, memory, tools, files, permissions, and an observe-and-correct loop. Whoever owns that harness treats models as suppliers. Whoever rents the whole stack is renting a night shift they cannot inspect.

AgentC Foundry’s version is blunt. Packaging the work is the skill. Prompting is not.

A packaged job answers four questions a chatbot never has to answer:

1. What does done look like in a file someone else can open?
2. How many loops may it take to get there?
3. Who approves the irreversible step?
4. Who stops it when the bill or the risk exceeds the job?

If you cannot answer those, you do not have digital labor. You have an open tab.

This is also why “just let it run” fails in operations even when it looks fine in a demo. Demos hide loop count. They hide sibling spawn. They hide the send button. They hide the person who was sitting next to the laptop ready to yank the cord. A real shop cannot staff a demo. It needs a card on the job: class, budget, door, owner, proof.

Start with one standing workflow — inbox triage, quote follow-up, weekly report, exception log — and refuse to run it as chat. Name the token class. Cap the loops. Keep draft as the default. Put a halt owner on the card who is a human with a calendar, not a model with a goal. Require a proof artifact before anyone calls it done.

Then look at the bill the way you would look at overtime. If a job that should have been one question is burning agent-class tokens, the prompt is not the problem. The job was misclassified. If a job that should have been one agent is spawning a swarm, the model is not the problem. The contract failed to forbid siblings.

The companies that get this right will not sound like they bought an AI workforce. They will sound like they finally put a time clock on work that used to hide inside a chat window. Chat stays cheap, because a question should be cheap. Labor gets a budget, an approval door, and someone who can stop it.

That is the difference between using a model and employing one.