When AI becomes a colleague and transforms the organizational chart

For two years, generative AI was just another tool on the workstation: you ask it a question, it answers, you repeat. Agents change the nature of the relationship. An agent receives an objective, chooses a sequence of actions, executes them using the company's tools, and reports the result. It no longer simply helps someone do their job: it does part of the work. And as soon as an entity does work, it has a place, explicit or implicit, within the organization. This article explores this place: what really changes in the organizational chart when AI becomes a colleague, who becomes responsible for it, what this requires of managers and support functions, and where to begin.

This article was published in September 2025 and completely rewritten in September 2026, based on our observations in the organizations we support. The examples have been anonymized and simplified.

From assistant to agent: what really changes

The difference between an assistant and an agent lies not in the power of the model but in the workflow. An assistant responds to a request and stops. An agent perceives the context, plans, acts within tools (messaging, CRM, ticketing system, document repository), checks the result, and repeats until the objective is achieved or a rule forces them to stop. In concrete terms, a support agent receives a ticket, searches for the applicable procedure, gathers missing information, proposes or implements the fix, and then closes or escalates the issue. A sales prequalification agent reads an incoming request, matches it with relevant offers, prepares an initial response, and submits it to a salesperson. A reporting agent collects the same data each month, compiles the report, and highlights any changes.

This shift has an often underestimated consequence: an assistant belongs to the person using it, while an agent belongs to a process. They act without being observed at each stage, they have an impact on the company's systems, and their errors have a cost that falls not on an individual but on a team, a client, or a partner. This is why the question of the organizational chart arises: it's essential to know to whom the agent "reports," who is accountable for their actions, and who decides when to stop them.

What appears on the organizational chart

Organizations that have moved beyond the pilot stage converge on four visible changes. These do not replace the hierarchical organizational chart; they are superimposed upon it.

Each agent has a named owner. Not a department, not a committee: a single person, usually the one already in charge of the process. The owner defines what the agent is authorized to do, approves their instructions, reviews a sample of their work, and has the authority to suspend them. An agent without an owner is an agent that no one corrects; they drift silently until an incident occurs. In practice, this is the first line missing from the inventories we audit: we know which agents exist, but rarely who is responsible for them.

The agents are counted as capacity, not as personnel. The classic mistake is to present an agent as "the equivalent of two FTEs." This formulation alienates teams and distorts management, because an agent doesn't take on a single role; they take on tasks distributed across several roles. The most successful organizations describe the agent by what they handle ("triage and initial response on 60% of level 1 tickets") and then look at how people use the freed-up time. It's this second aspect, not the first, that justifies the investment.

The manager's scope expands to include non-human colleagues. A support team leader who manages eight people and three agents no longer has the same job. They must allocate work between staff and agents, decide what should remain the responsibility of staff (sensitive situations, angry customers, new cases), interpret indicators that combine data from both groups, and arbitrate when an agent and a staff member contradict each other. This isn't a technical skill; it's a job design skill, and it can be learned.

New roles are becoming established. Three roles recur everywhere, under varying names: the agent designer, who translates a process into instructions, sources, and safeguards; the business expert, who evaluates outputs and provides support to the agent in critical situations; and the governance manager, who maintains the inventory, assesses risks, and arbitrates production deployments. In small organizations, these three roles are filled by one or two people. In larger organizations, they become separate functions, often reporting to the transformation department or the HR department.

Who governs: the business, IT, HR triangle

The deployment of agents creates tension between three functions that were not accustomed to making decisions together. The business defines the opportunity: which process, which performance objective, which acceptable level of quality. The IT department guarantees the architecture, security, data access, and integration with existing systems; it is the IT department that "provisions" the agents, just as it used to manage workstations. The HR department becomes the conductor of this coexistence: it identifies tasks, anticipates job evolution, organizes skills development, and champions the collective narrative without which adoption fails.

When one of these three functions is missing, the result is predictable. Without expertise, you get technically flawless agents that no one uses. Without IT support, you get cobbled-together agents accessing data they shouldn't see. Without HR support, you get teams duplicating the agent's work "to check" and negate any expected gains. A small, monthly committee, bringing together these three voices and the owner of each agent in production, is sufficient in most organizations; the important thing is that it exists before the first agent goes live, not after the first incident.

Recruiting, training and evaluating an agent

The analogy with recruitment is useful because it imposes discipline. An agent is "recruited" based on a job description: the process they will be responsible for, the tools they will have access to, what they are authorized to decide independently, and what they must submit to a human. They are "trained" with a reliable body of knowledge (up-to-date procedures, examples of correct answers, documented edge cases) and instructions that outline the tone, rules, and prohibitions. They undergo a "trial period": a few weeks in an assisted mode, where each piece of work is reviewed before being implemented, before gradually gaining autonomy in cases where they are correct.

Finally, it evaluates itself, and this is where the analogy becomes demanding. A production agent must have a dashboard shared with the human team: volume processed, escalation rate, error rate measured on a reviewed sample, and recipient satisfaction. The most advanced organizations read the team's performance on a single line, combining human and agent performance, which emphasizes shared responsibility and avoids the trap of "the agent made a mistake." And like a colleague, an agent can be retired: when the process changes, when the error rate increases, or when a better tool becomes available. Planning its departure from the outset prevents zombie agents from continuing to run because no one dares to shut them down.

Adoption: the real bottleneck

In practice, technology is almost never the problem. What's the problem is the teams' reaction. New recruits readily adopt a digital colleague who accelerates their skills development. Experienced employees initially see it as a challenge to their expertise, sometimes a threat, and react in two ways: they bypass the agent, or they redo their work. In both cases, the benefit is lost.

Three key factors make all the difference. Leading by example: managers who delegate to agents themselves clearly motivate their teams; those who talk about it but don't actually do it paralyze them. Transparency about what happens to the time freed up: if teams don't know what's expected of them once the agent is in place, they assume the worst. And involvement in the design process: an agent whose instructions have been written with the people who were doing the work is embraced; an agent who is imposed on them is simply endured. This last point is the most cost-effective and the most overlooked.

The risks that a human colleague does not present

An agent makes mistakes differently than a person: confidently, on a large scale, and effortlessly. A poorly worded instruction produces the same error on a thousand files before anyone notices. Overly broad access allows data to leak that no employee would have submitted. An agent negotiating, placing orders, or responding to clients can commit the company in a way that no one has approved. The control framework must therefore include what no HR manual provides: explicit limits on actions (amounts, scope, types of decisions), logging of everything the agent does, sample review, and a stop button that the owner can activate without going through the IT department.

Transparency towards recipients is part of the framework. A client or colleague must know they are interacting with an agent and must be able to request human assistance. This isn't just a regulatory requirement; it's also what protects the relationship when the agent makes a mistake. Usage studies, moreover, reveal a persistent paradox: even the most digitally savvy users prefer a human voice for requests they consider critical or unique. A good organization isn't one that automates everything; it's one that knows precisely where human intervention is necessary.

What jobs are becoming

When an agent absorbs the procedural aspects of a role, what remains is not an empty role but a repositioned one. The Level 1 technician becomes an agent supervisor and case manager for the escalated cases. The administrative manager becomes an analyst of what the data reveals. The recruiter spends less time screening and more time persuading. The customer service representative handles fewer requests, but they are more complex and require listening and judgment. In each case, the core focus of the job shifts from execution to design, control, and relationship building.

This requires skills development on two levels. On the one hand, new skills for everyone: formulating a clear objective for an employee, providing them with the right resources, critically reviewing their work, and knowing when not to delegate. On the other hand, strengthening what the employee is currently lacking: solving poorly defined problems, negotiation, empathy, and the ability to make decisions with incomplete information. HR departments that build their training programs around these two axes prepare the organization; those that merely raise awareness of the tools prepare for disengagement.

Where to start

The starting point isn't technological. It consists of choosing a well-mapped process, with clean data and no disputes over responsibility, and then clearly defining four things before building anything: what the agent will do, who will own it, what they won't be allowed to do, and what the team will do with the freed-up time. These four lines fit on a single page; their absence explains why most pilots never progress beyond the demonstration stage.

Next, a short, assisted pilot program, with the people who were doing the work manually, a shared dashboard from the first week, and a monthly review of the business, IT, and HR triangle. Then a second agent, reusing what was learned from the first. The key lies less in initial perfection than in the ability to iterate: models progress at a pace that renders any overly rigid planning obsolete, and an organization that already has three agents in production, governed and accepted, learns faster than one that prepares thirty on paper.

Agentic AI doesn't eliminate work; it redistributes it. The question is no longer whether agents will be present in the organization, but whether this role will have been designed or imposed. An organizational chart that names its agents, their owners, and their boundaries is not a dehumanized chart; it is a chart that still knows who is responsible for what.

To go further: the hybrid human/agent worker and how mastering agent-based AI without hindering innovation.