AI organisation

AI employees

Employees with a role, a manager, a scope, a budget and a record, hired into the same organisation as everybody else, not agents that perform tasks

Employees, not agents

An agent is a thing that performs a task. An employee is somebody with a place in the organisation: a role, a manager, a scope of what they may see and do, a budget they spend against, skills they were hired for, and a record of what they did that outlives any single task.

AI here is the second kind, which changes the questions worth asking about it. They are the ones you would ask about a new hire:

The question The answer it must have
What is it for? A defined role, in a defined part of the operation
What may it see? The same row-level and field-level rules that apply to a person
What may it do alone? Risky actions pass a gate and then an approval - with no approver, refused
What does it cost? Metered on a transport that cannot be bypassed
Who does it answer to? A manager or a process owner, like anybody else
What did it do? Every call and decision, in the same audit trail, under its own name

What one does

The work that is necessary and never needed a person's judgment:

  • Watching - the deal that has not moved in eleven days, the stock that runs out before the next delivery, the request sitting unassigned since Friday, the invoice that does not match the order.
  • Collecting and checking - looking a company up, filling in what can be filled in, verifying a record against another system, flagging a field that contradicts itself.
  • Working something up - turning three lines somebody typed into a brief a reviewer can decide on: the goal, the problem, the value, the effort, the scope. That was an analyst's job.
  • Preparing decisions - assembling the numbers, the history and the comparable cases, so deciding takes two minutes instead of forty.
  • Doing the routine - the transfer between systems, the monthly compilation, the follow-up nobody sent.
  • Escalating - the moment something falls outside what it may do, it stops and hands over, with what it found and not a shrug.

Two ways to hire one

Picking the right shape is most of the design work.

Into a person's authority. The employee works on behalf of somebody - a manager, a process owner, a team lead - and acts within what that person may do. It drafts, prepares, checks and proposes; anything consequential comes back for a signature.

This is the shape for judgment-adjacent work, and it is where most companies should start: the boundary is obvious, and whoever lent the authority reviews the result.

With standing authority for a system-wide job. Some work is on nobody's behalf: watching every dataset for a refresh that failed, checking every invoice against every order, keeping a catalogue in step with an external system. That employee holds its own scope, granted deliberately and narrowly, and somebody monitors the work instead of approving it case by case.

The rule of thumb: delegate authority when the work needs judgment; grant it when the work needs coverage. Either way the scope is data, so you can read it, review it and cut it back.

What it costs, and who owns that number

Every model call goes through one metered transport, so an employee's spending is a figure somebody owns rather than a surprise at the end of the month. Budgets are set per employee, and the platform enforces the limits instead of reporting them after the fact.

That also makes the comparison honest: an employee that watches a queue continuously has a cost you can put next to what it replaces. See Budgets.

The ones that come with the platform

Some roles are the same in every company. Those arrive with the platform.

  • Data engineering - understands your datasets, proposes models over them, cleans a column, explains where a number came from.
  • Visualisation and design - turns "margin by region against last year" into a chart, suggests a dashboard layout, and picks the shape that answers the question rather than the one that looks impressive.
  • Process authoring - turns a described approval into a working process with its routes, roles and conditions.
  • Platform operations - the DevOps employee: watching that the installation is healthy, that scheduled work ran, that a refresh did not fail quietly, and telling somebody before it becomes an incident.

A starting set. The roster is configurable, and companies add their own: the employee that knows your industry's rules, your pricing policy, your quality standard. Building one means describing what it is for and what it may do.

Next

Under the hood - how a role becomes an enforced scope.