Agentic vs human processes

Which human processes apply to agentic workforces?

We have all spent extensive time building HR and governance processes designed around our human workforce. Now we need to decide what actually transfers to an agentic one.

What needs strengthening, and what is simply obsolete?

Some basics that apply to any workforce 

• Resource and people management assigned
• Dedicated user profile, id, permissions, least privilege access rights as default
• Audit logging of every action 
• Onboarding and context provision and reviews

Where agentic workforce needs additional controls

• quarterly or annual reviews are not sufficient, reviews need be ongoing and to trigger on changes to environment, configuration, scope, access
• regular context and knowledge updates to ensure they are still operating on latest data and they are not making up their own reality or not using data as intended
• off-boarding gets complicated, as every other agent that had a dependency on / interacted with the agent may need context updating to ensure they no longer expect that agent to be present as part of the process. You may need to update your .md files and provide workforce updates 
• A single identity for the agent is not sufficient, as an agent's permissions vary by task, not by deployment. A single standing identity with broad scope is the wrong model. You may need to iterate this to find the right mix.
• Trust based on ownership (we built it or its in our organisation) is a fallacy. An agent should not treat another agent's output as trusted simply because it originated inside your own environment.

Above all of that agents need continuous behavioural verification: proof that the agent is still doing, in production, what it was attested to do at deployment. You would not dream of doing this with a human employee but as agents can be silently upgrade overnight by a third party change or via a series of interactions you will need this for an agentic workforce.

Examples of two organisations on how they’ve implemented it

BNY now runs close to 140 ‘digital employees’, each with a system login, an employee number, an avatar and a human manager who assigns tasks and reviews output. About 100 people across the firm now do this job. One of them, Rachel Lewis, a two-decade BNY veteran who now leads AI enablement for the bank, oversees multiple agentic systems alongside human staff. The bank's uses a 16-step governance flowchart, covering review boards, compliance gates and model risk evaluation, maps every step between an idea and a working agent. The bank has said openly that this governance is never finished, only continuously revised. 

Microsoft's own internal account of governing agents at scale, published in June 2026, describes  a much larger population of employees, building agents themselves. Microsoft's answer was to implement their existing matrix platform-level approval model, tiered by risk and by which employee is building in which environment. This shows that an organisation does not need a bespoke agent-governance built from a blank page. It needs to understand the best trusted governance model for their workforce and operations.

Should we "treat agents as employees"?

This accountability question keep getting raised: when a digital employee gets something wrong, who owns that, the agent, the manager who did not catch it, or the engineers who built it?

What are your thoughts?

 

It is tempting to use "treat an agent like a person" as the whole answer: do not grant broad or unrestricted access, start with low-risk and non-sensitive work only, fold the new arrival into your existing security model rather than treating it as a one-off experiment.

But having lived through that we definitely found that greater control, more finely grained is required. 

To start with, how is digital employee is trained is fundamentally different. A new employee learns your company through months of mentorship, tacit knowledge, and accumulated judgement that lives in their head and nowhere else. An agent's capability comes largely from the foundation model your organisation uses (i.e. it is licensed from a vendor) a set of context that is provided at setup then the interactions and memory it builds up over time (training from experiences).

It is not quite right to say an agent does not learn the way a person does. Agents accumulate context: conversation history, retrieved memory, tool-use logs and, undergo model training or fine-tuning.  Similarly a person's judgement evolves gradually, through experience, but it rarely regresses overnight. A model update can change an agent's behaviour in a single release, in ways that are not visible until something specific breaks. 

As per the Forbes Technology Council, when an AI agent is abandoned or replaced, the formal decommissioning that typically happens for an employee does not happen. Most organisations have not yet learned to manage this, and its not as simple as using a checklist. 

What the data tells us

Numbers on AI adoption vary enormously

According to the WRITER AI adoption survey, 97% of executives say their company deployed AI agents specifically in the past year, and 52% of employees report already using them. 75% of executives expect AI agents to be part of their company's C-suite within five years, and 95% say roles and team structures are already changing because of AI.

A study by KPMG and the University of Texas analysed 1.4 million real workplace AI interactions across more than 2,500 employees over eight months. It found that only around 5% of users consistently showed the behaviours that separate routine use from high-impact AI use:

To really get value from AI you need to be treating the model as a genuine reasoning partner, iterating past the first answer and choosing tools deliberately rather than out of habit, or pre-defined. 

Four behavioural signals that separated the 5%

• Returning to AI frequently as a routine part of daily work.
• Persistence with refining outputs across several exchanges rather than accepting the first answer.
• The level of detail provided in prompts and instructions matter
• Deliberately choosing the tool or model for the task rather than default. 

The last one is where the highest productivity gains sit, and is probably teh largest organisational gap. It requires users to really understand what they are trying to achieve (their goal) the agent, all the tools and capabilities available to them and how to use the correct tool for the task - akin to a carpenter using the right tool for the job to get best outcome.

What we learned from zero trust 

Adopt the lessons from zero trust movement: never trust a request just because of where it came from; verify it, every time, regardless of origin, enforce least privilege and assume a breach. 

According to Gravitee’s Agentic AI Security report, only 22% of security practitioners treat AI agents as independent identities at all; the majority still rely on shared API keys or inherited user sessions, which makes it impossible to say afterwards which agent did what.

But the more important lesson from zero trust is what came next. Security architects extending NIST's model to agentic systems have concluded that identity verification is not sufficient for an actor that reasons and acts autonomously.

Agent-specific zero trust needs continuous verification of behaviour, knowing which agent is making a request is necessary, but knowing that the agent is still behaving the way it did when it was approved is crucial, and identity and access controls were never built to answer this. 

Subscribe for the latest BASTYN Trust Intelligence