Skip to content
AI Native CTO
Agentic EnterpriseEssay9 min read

From Copilots to Coworkers: Designing the Agentic Enterprise

A practical operating model for deciding what agents should do and how humans should remain in control.

The first phase of enterprise AI gave people better tools. The next gives software more responsibility.

That sounds like a continuation. It is not. Delegating work to software changes how the work is designed, managed and governed, and most organisations are approaching it with a procurement mindset rather than an operating-model one.

The agentic enterprise is an organisation in which people and AI agents work together to achieve business outcomes. Getting there is less about which platform you buy and more about decisions you have probably not made yet.

The demo problem

An agent is not a digital employee simply because it can call a few tools.

To work dependably inside a company, an agent needs more than a capable model. It needs a defined role, the right context, access to approved tools, boundaries on its authority, standards for good work and a clear route to a human owner.

Without those elements, the organisation has an impressive demo. It does not yet have a dependable digital workforce.

The gap between the two is where most agent programmes stall, usually about four months in, when the pilot meets a real workflow with real permissions and real consequences.

Six things every enterprise agent needs

Think of this as the operating system an agent runs on. All six have to be present.

Mission. A clear outcome, scope and definition of success. An agent given a vague goal will produce vague work, confidently.

Knowledge. Trusted, current and permission-aware organisational context. Not a document dump. An agent that can read everything the company holds is a data-exposure incident waiting for a prompt.

Tools. Approved systems and actions the agent can use to complete its work, with the same access review any human would go through.

Guardrails. Rules, permissions, spending limits and conditions for escalation. Autonomy should be proportional to consequence, and that proportion is a business decision, not a technical one.

Evaluation. Tests and live measures for quality, safety, cost and business impact. Model accuracy is not the measure. Whether the work was done well is.

Accountability. A named human owner who remains responsible for the outcome. If no one's name is on it, it is not in production, whatever the dashboard says.

A path that survives contact with the business

Six steps, in this order, because each depends on the one before it.

Find the work. Map high-volume, high-friction and high-value workflows. Look for work with a clear outcome, accessible knowledge and measurable quality. Work that fails any of those three is a poor first candidate however appealing it looks.

Set the boundary. Decide what the agent may recommend, prepare, execute or approve. These are four very different levels of authority and the difference between them is usually where the risk sits.

Build the context. Give the agent access to trusted knowledge, policies, examples, data and tools without flattening the organisation's permission model. This is the step most often rushed, and the one that most often forces a rebuild.

Evaluate before scale. Test the complete workflow, including failure, ambiguity and escalation. Measure business outcomes, not just model accuracy.

Redesign the role. Remove completed tasks from human roles. Increase responsibility for judgment, relationships, problem framing and exception handling. If the tasks leave but the role does not change, you have added supervision work rather than capacity.

Operate the workforce. Monitor quality, cost, drift, permissions and incidents. Agents require management even when they do not require line managers.

The risk is different in kind

This is the part that deserves board attention, and rarely gets it early enough.

An incorrect answer is inconvenient. An incorrect action can move money, expose data, change a customer record or interrupt a business process.

That difference is why the control model has to cover identity for every human and machine actor, least-privilege access to data and tools, approval thresholds based on consequence, complete logs of reasoning inputs, tool calls and outcomes, evaluation before release and during live operation, fallback behaviour when models, tools or data fail, and named accountability for every agent-owned workflow.

None of that is exotic. Most of it is the control thinking a regulated business already applies to people and systems. What is new is applying it to an actor that works quickly, at volume, and does not tell you when it is uncertain unless you have designed it to.

Where the leadership work actually is

Becoming agentic is not a software installation. It is an operating-model decision.

The questions that determine whether it works are not technical ones. Which work should remain human? Which work can be delegated, and at what level of authority? Who owns the outcome when a machine performed the steps? How does the organisation chart change when a team's throughput no longer depends on its headcount?

Those decisions belong to executives, informed by people who understand what the technology can and cannot do.

If your organisation is moving from copilots to agents, the right time to define the architecture, operating model and controls is before you scale, not after the first incident. Build an agentic enterprise, not a collection of agents.

Read the full definitionThe Agentic Enterprise
Explore the category

The AI-Native Briefing

A considered note on AI, technology leadership and the agentic enterprise. Written for people making real decisions, not watching from the sidelines.

Useful ideas only. Unsubscribe whenever you like.