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, so the org structure sits underneath everything else on this platform, not 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 people half is the familiar half
Nothing exotic here, and it should not be.
It comes from where it already lives. Units, positions, employees, who reports to whom: taken out of your HR or HCM system, not maintained twice. A CSV export today, with connectors to the usual HCM systems close behind. Load the same structure again and it converges, so keeping it current is a repeated step and not a clean-up.
Several legal entities, one structure. Groups are normal: a holding with four companies, a shared services function, people who belong to one entity and work in another. You describe that here.
Roles resolve at the moment they are needed. The route reads "the head of the requester's department" out of the data when it gets there, so it stays correct when somebody moves, and nobody edits a process because of a promotion.
And the awkward parts are first-class. Substitution when somebody is away, so work does not stop at a holiday. Watchers who see without being asked to act. Assignments handed to a person or to a team's queue. Delegation, so authority can move for a fortnight without anybody editing a process.
See Org structure.
The new half: 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 on this platform is the second kind, which changes what you ask about it. The questions are the ones you would ask about a new hire:
- 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, not a separate policy somebody keeps in step by hand.
- What may it do on its own, and what needs a signature? Risky actions pass a gate and then an approval; with no approver available the action is refused.
- What does it cost? Model usage is metered on a transport that cannot be bypassed, so its spending is a number somebody owns. See Budgets.
- Who does it answer to? A process owner or a manager, like anybody else.
- What did it do? Every call and decision lands in the same audit trail as everybody's, under its own name.
Hiring one
Two shapes of employment, and picking the right one is most of the design work.
Hired into a person's authority. The employee works on behalf of a manager, a process owner or a team lead, and acts within what that person may do. It drafts, prepares, checks and proposes; anything consequential comes back for a signature. Start here for judgment-adjacent work: the boundary is obvious, and whoever lent the authority reviews the result.
Hired 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.
System employees you did not have to hire
Some roles are the same in every company. Those come with the platform.
- Data engineering - the employee that understands your datasets, proposes models over them, cleans a column, explains where a number came from.
- Visualisation and design - the one that turns "show me margin by region against last year" into a chart, suggests the layout for a dashboard, and picks the shape that answers the question rather than the shape that looks impressive.
- Process authoring - the one that 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, that something is not about to run out of room, and telling somebody before it becomes an incident.
The roster is a starting set, and you add to it: 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, the same conversation as above.
How this works underneath
Three things carry it, and each is documented on its own.
Skills and tools. What an employee can do is a set of skills and the tools they reach, scoped per role and not granted wholesale: a sales employee cannot reach the platform-authoring tools, so nobody has to trust it not to. See Skills and Tools and MCP.
Knowledge. What it knows about your company comes from your data, your catalogues, your processes and your knowledge base, retrieved by meaning. See Knowledge and Company knowledge base.
Accountability. Every tool call, every decision, every cost is recorded; the gate that stands in front of consequential actions is ordered and fails closed. See Traces and AI employees.
What changes when the org has both halves
Something narrower than "we replaced people with AI", and more useful.
The work that exists only because information has to be moved, checked, chased and compiled by hand stops needing hands. People keep what people are good at: the ambiguous case, the upset customer, the judgment call, and changing how the company works when the business changes.
And the organisation gains a property it never had: it can watch everything. Watching used to cost a hire for every thing worth watching. An employee now does it across the whole operation and escalates only what matters.
Next
AIpril vs ERP and SaaS - why this is a different category, not a better-configured one.