An organisation is its resources
Strip away the software and a company is a short list of things: who is here, what each of them can do, what each is responsible for, and who answers for what happened.
People, their skills, their roles. Every process with an owner. Every action attributable to somebody. That is what makes the work possible to run at all, which is why this block sits underneath the others instead of in a personnel module off to one side.
The list now has two kinds of entry. Some of your resources are people. Some are not, and you hire, scope and hold them to account the same way.
The agents nobody owns
Right now the usual way to put AI into a company is to bolt it on. A chat assistant beside the CRM. A scheduled job that summarises something overnight. A script somebody wired to a process because they could. A tool a team built in a fortnight and never told anyone about.
Each of them works. Together they are a problem, and not a technical one: every question you would ask about a member of staff has no answer:
- What is it allowed to do? The scope lives in a prompt, or in whatever credential it was handed on the day it was built.
- Who pays for it? The spend turns up on a bill and is attributed to nobody.
- Who asked for it? There is no requester, no owner, and nobody to talk to when it does something wrong.
- Who does it answer to? Nobody. Which also means nobody notices when it stops working.
- What happened? Its actions are in its own logs, if it has any, and not in the record of the work it touched.
- And when the person who built it leaves, it keeps running.
That is not a failure of the agents. It is what happens when a capability arrives before there is anywhere to put it.
And an employee is not a chat, nor a job on a timer. A chat answers when spoken to; a scheduled job runs whether or not it is still the right thing to do. Neither holds a task, carries responsibility for an outcome, escalates to a named person, or shows up in a queue as the reason something is waiting. An organisation cannot be run by things that only respond and things that only repeat.
Here they have a place, and it is the same place people have. An AI employee is a role in the organisation: hired by somebody, answering to somebody, with a scope that is data rather than a sentence in a prompt, a budget that is a line somebody owns, and actions that land in the same history as everybody else's. Every question above has an answer, because the org structure is where those questions are asked and answered for people already.
That is the argument for the whole block: putting AI into the organisation is the difference between having a capability and having a workforce.
Why the two belong in one block
Because everything downstream needs both, and needs them to work identically.
A process route resolves an approver: it does not care whether the answer is a person or an employee that is not. A permission decides which rows are visible: same rule, same enforcement, either way. An audit trail records who did what: one trail, both kinds of actor, under their own names. A task is assigned, a substitution applies, a budget is spent.
Keeping people in one system and AI in another would mean maintaining two answers to every one of those questions, and reconciling them forever. So there is one organisation, and it has two kinds of member.
Where to go next
- Your organisation - units, positions, people and roles: where the structure comes from, how substitution and delegation work, and how several legal entities live under one roof.
- AI employees - what one is, the two ways of hiring, what they cost, and the ones that come with the platform.
- Under the hood - how a role becomes an enforced scope, and what stops an AI employee doing more than it should.