Tool, worker or director

I have run Ampron with my co-founder for over a decade. There are two of us in the leadership team. Every role that a larger company spreads across a whole executive team has been carried by the two of us. We have no outside investors and have not hired anyone above the operational level.

This is how a large share of small companies work. The founder changes hats every hour and never gets properly deep in any one role. That has been my working life too. That is why I do not look at AI executives as productivity tools. In my view the biggest mistake in this field is a category error, and it is rarely called by its name.

Three different things

An assistant is something you ask things of. A worker is something you give tasks to. A director is something you give a domain to.

A tool produces an output when you ask for it. The goal, the standard and the judgement of the result stay with you. A tool raises your throughput, but it does not change what you spend your attention on.

A worker carries out a task against a brief. You set the task and decide when the result is good enough. The worker breaks the work into steps, does them and makes limited decisions along the way. A worker cuts the time you spend on doing. It does not cut the time you spend deciding what should be done.

A director owns a domain. It receives that domain as a charter, not as a brief. Inside the domain it sets direction and priorities, coordinates with the other directors and hands the doing down to workers and tools. Ask it what is happening in sales and what to do about it, and you do not get a summary. You get a position, with reasoning and a recommended action. A director does not wait for a brief. It writes the briefs that the workers work to.

The difference is not technical. It does not depend on the model. It depends on what the system is made to own.

The test is simple. Ask of every AI system in your office: what does this thing decide on its own, without being asked? A tool decides nothing. A worker decides how to carry out a task someone else defined. A director decides what to work on, in what order and to what end. If the answer is “nothing”, you do not have a director, whatever the label says.

The label says one thing, the architecture another

A board approves an AI project called “deploying a Sales Director”. Six months later the leadership team is disappointed. The system writes slightly better emails and answers tenders slightly faster. What went live was an assistant. The label said director, the architecture said assistant. The architecture wins every time.

The second case is more insidious. The company does try to build a director, but builds it on a worker’s architecture. Over the first weeks the system quietly sinks back into worker behaviour, because people find it more comfortable to deal with it that way.

The chief executive asks the new Sales Director about the status of one deal. Then he asks for a draft email to the customer. Each request is sensible and useful. None of them is a director’s work. A real director, six weeks in, would already have taken a position on that deal on its own. The human is using the system as a fast, knowledgeable assistant. The system lets him. Both are satisfied. The deployment is failing.

Worker behaviour is the floor of every agent system, the place gravity pulls everything back to. Every interaction sinks there unless the architecture and the chief executive actively pull the system up. That pull is not in the prompt. It is in the charter, in the working rhythm and in the expectation the chief executive sets: a director does not wait to be asked. The most dangerous part is that the absence of that pull cannot be seen.

A director must be able to refuse

One question separates a director from everything else. Can this agent refuse a direct instruction from the chief executive?

A tool does not refuse. A worker may refuse narrowly, when an instruction breaks clearly defined limits. That refusal comes from a rule, not from judgement. For a director the answer has to be yes. A Technical Director that cannot push back when I want to ship a release it judges not ready is not a director. It is an assistant in a director’s uniform.

This is uncomfortable. Most chief executives hesitate when they first grasp it. The hesitation is understandable, but it is also the diagnosis. If you will not give the agents the right to refuse, you want the benefit of the architecture without paying its price. The price is real authority. Being willing to hear “no” is the entry fee. If you will not pay it, you are building a worker.

What I would tell another founder

I did not understand at first why this matters so much to me. Only after several months of working with a personal AI leadership team did I see that it addresses a gap small companies have always lived with. Real executive judgement has been available to those who can afford to hire it. Most small companies cannot. At Ampron the agents work at the director tier.

Before you give an AI system the title of director, ask two questions. What does it decide on its own, without being asked? Is it allowed to tell you “no”? If the answer to both is no, you have not created a director. There is no shame in that, because workers are useful. But call the thing by its right name, because the label does not change the architecture.

Where I am wrong about this, I hope readers will correct me.