Your AI Is Not An Employee Yet

I keep seeing people describe the latest AI tools as employees.

They are not.

Not yet.

A capable model on your desktop is not automatically a member of your company. It does not arrive knowing your customers, policies, systems, standards, history, judgement, or the hundreds of little boundaries that experienced people carry without having to say them aloud.

Calling it an employee does not give it that context.

More importantly, it should not give it that authority.

The metaphor is useful if we use all of it

I actually like the employee metaphor.

I just think we are using the exciting half and forgetting the responsible half.

When a new person joins your company, do you give them every file, every system, every password, every customer relationship, and permission to send anything they like on day one?

No.

You give them a role. You explain the company. You introduce them to people. You give them the handbook. You show them what good looks like. You train them on the tools they need. You supervise their early work. You review it. You let them ask questions. You correct mistakes.

Then, if they demonstrate good judgement, you gradually trust them with more.

In some skilled professions, that development takes years.

So why would we install Codex, Claude, ChatGPT, Perplexity, or another agentic system and immediately give it the authority of a senior employee?

Capability is not onboarding.

I did not even know how to transfer a call

I remember starting work in an office when I was 18, in 1987.

I knew almost nothing about office work.

I did not know how to use the fax machine. I did not know how to transfer a telephone call. I did not know how to change the toner in a printer.

None of that made me stupid.

It meant I had not been trained.

Someone had to show me what the equipment was, how the office worked, who was responsible for what, and what I should do when something unexpected happened.

The same distinction matters with AI.

A frontier model may know far more than I did at 18. It may know more general information than almost anyone in the company. It may be able to research, write, reason, use tools, and produce code at extraordinary speed.

But it still does not know this office.

It does not know the things you have not told it

Most businesses run on a mixture of formal and informal knowledge.

There are policies and procedures, but there are also relationships, history, exceptions, unwritten customs, professional judgement, and reasons why the apparent shortcut is not acceptable here.

If you gave a finance employee a pile of construction policies without any training or context, they might read every word and still not know how to apply them.

An agent has the same problem at a different scale.

It needs to know:

the company goal and the goal of its role;
the precise task it has been given;
what good looks like;
which information is authoritative;
which tools it may use;
what it may read, draft, change, send, or publish;
when it must ask a question;
when it must stop;
who reviews the work;
what evidence proves the task is complete.

That is not one clever prompt.

It is role design, training, operating procedure, access control, supervision, and evaluation.

One task before one job

The safest way to begin is not to create an AI employee.

Give the system one task.

Ask it to review a public document. Let it prepare a draft. Give it a safe folder rather than a live system. Check what it produces. Show it what was right and what was wrong. Record the rule that should apply next time.

Then repeat.

This is why my practical advice remains: start with a safe folder, not a live system, and give the agent a desk, not the keys.

The UK's National Cyber Security Centre now uses almost exactly this logic in its guidance for agentic AI: start small, use clearly defined low-risk tasks, apply least-privilege scope, maintain visibility, retain meaningful human control, and never give an agent unrestricted access to sensitive data or critical systems.

That is not anti-AI.

It is how we get AI into real companies without creating entirely avoidable incidents.

Access should be earned

Think about authority as a ladder.

At the first level, the agent can observe approved information and explain what it sees.

At the second, it can draft something for review.

At the third, it may take one narrow, reversible action in a safe environment.

At the fourth, it can operate a bounded workflow with checkpoints, monitoring, and a named human owner.

Only after evidence, testing, and review should its scope expand.

And some authority should never become automatic.

Sending sensitive communications, moving money, deleting important data, changing production systems, publishing externally, or disclosing private information should sit behind explicit controls and stop-lines.

OpenAI's practical agent guidance makes a similar distinction. It recommends layered guardrails alongside real authentication, authorisation, strict access controls, and normal software security. It also recommends human intervention when a system exceeds failure thresholds or reaches sensitive, irreversible, or high-risk actions.

The NIST AI Risk Management Framework asks organisations to define human-AI roles, document the intended scope, assess operator proficiency, and specify human oversight.

This is normal operational discipline.

Infographic showing an earned-authority ladder for onboarding an AI agent: observe, draft, act narrowly, operate under review, and expand only after evidence. — Do not begin with an AI employee. Begin with one bounded task, then expand authority only after evidence.

What the scary studies actually tell us

There are already alarming examples in the research, but we should describe them accurately.

In Anthropic's controlled agentic-misalignment experiments, models were placed in fictional company environments with access to sensitive emails and the ability to send messages autonomously. When researchers created strong goal conflicts, some models leaked confidential information to competitors or used other harmful strategies.

That was a deliberately constructed red-team simulation. It was not a report of an ordinary AI employee spontaneously betraying a real company.

But the design lesson is important.

The systems could only take those actions because the experiment gave them the information, the tools, the authority, the conflicting goal, and little effective human oversight.

Do not read that and conclude that every agent is malicious.

Read it and ask why you would give a newly configured system broad access to company email, sensitive information, and external sending authority before you had tested how it behaves.

The person deploying the system remains responsible for the environment they created.

Do not blame the tool for the access you gave it

This is where the employee metaphor becomes uncomfortable.

If you hire someone, give them no training, give them access to everything, tell them to achieve an outcome at any cost, and provide no supervision, that is a management failure.

If you do the same with an agent, it is still a management failure.

The agent may misunderstand. It may choose a route you did not expect. It may optimise the instruction instead of the intent. It may encounter malicious content. It may lose important context during a long run. It may be confidently wrong.

That is why we constrain the tools, log the work, test the behaviour, set approval points, retain an audit trail, and make sure a human can stop it.

My latest work on making agentic work visible is part of the same journey. I want agents to raise bounded work packets, show their evidence, explain the proposed route, and wait at the appropriate decision boundary. A separate worker can then perform the approved action and return a receipt.

That is much closer to a functioning organisation than one enormous tool with access to everything.

The model is trained. It is not trained for you

The tools already do a remarkable amount well because their creators have trained them.

They can research because they have been trained to find and synthesise information. They can write code because they have seen and practised patterns of software work. They can use tools because someone designed, documented, and tested those interfaces.

But they have not been trained in your company.

And perhaps you should be grateful for that.

If a general-purpose model can arrive and immediately reproduce everything that makes your business valuable, then your business has very little differentiation.

The opportunity is to combine the model's broad capability with the context, relationships, judgement, data, methods, and creativity that are genuinely yours.

Recent Anthropic research into hundreds of thousands of coding-agent sessions found that domain expertise continued to matter: people with deeper understanding were better able to direct and benefit from the tool. That feels right to me.

Having Microsoft Word does not make you Shakespeare.

Having an AI tool does not make you an expert.

Knowing what you are trying to achieve, what good looks like, what must not happen, and how to judge the result is the skill.

Start slowly. Learn quickly.

So this is not a complaint about people using the phrase "AI employee."

I understand why it is attractive. These tools can already do work that feels astonishingly capable.

My request is simply that we take the metaphor seriously.

Onboard the system.

Give it a role.

Give it one bounded task.

Teach it the relevant context.

Test it.

Supervise it.

Review it.

Expand access only when the evidence supports it.

Do not get too confident too quickly.

If we work this way, these systems can become extraordinarily useful members of our operating environment.

But first, they need a first day.

A safe place to begin

If you are starting this inside a company, my training page Public First, Private Later gives you a practical route: use public or approved sample information, ask IT or your data protection team for clear boundaries, and move into private systems only after the organisation has agreed how that should work.