AI Agents and the Next Layer of Organisational Execution

Artificial intelligence is moving from generation to execution.

The first wave of generative AI adoption was largely defined by assistance. Users asked models to draft, summarise, classify, brainstorm, translate, explain, or analyse. These use cases were powerful because they lowered the cost of knowledge work and gave individuals access to new forms of productivity.

AI agents represent the next shift.

Rather than simply generating an answer to a prompt, an AI agent is designed to pursue a task through multiple steps. It may interpret an objective, retrieve information, use tools, call software functions, reason through alternatives, produce an output, request approval, update a system, or coordinate a workflow. McKinsey describes AI agents as systems based on foundation models that are capable of acting in the real world, planning, and executing multiple steps in a workflow.

This is why AI agents matter. They move AI from a conversational interface toward an execution layer.

For organisations, the implications are significant. If generative AI changed how people produce information, agentic AI may change how work is coordinated, delegated, monitored, and completed. The question is no longer only whether AI can assist a person with a task. The question is whether AI can become part of the workflow itself.

What Is an AI Agent?

The idea of an intelligent agent is not new. In foundational AI literature, Michael Wooldridge and Nicholas Jennings described agent theory as concerned with what an agent is, how agents can be represented, and how software or hardware systems can be designed to satisfy the properties associated with agency.

In modern applied AI, the term usually refers to a system that can observe or receive information, reason about a task, decide what to do next, and take action through tools or connected systems. A survey on large language model-based agents describes AI agents as artificial entities that sense their environment, make decisions, and take actions.

Large language models have changed the practical frontier of agent design. Earlier autonomous agents often operated in restricted environments with limited knowledge. LLM-based agents can draw on broader language, reasoning, planning, and tool-use capabilities, which has led to a surge of research into autonomous agent systems.

One useful way to understand the modern AI agent is through three components: a reasoning layer, a perception or context layer, and an action layer. A survey of LLM-based agents describes a general framework comprising “brain, perception, and action”, which can be adapted to different applications.

In business terms, this means an agent is not just a chatbot. A chatbot responds. A co-pilot assists. An agent acts within a defined operating boundary.

That boundary is critical.

Why Agents Matter for Organisations

The significance of AI agents is not that they are more impressive than chatbots. It is that they may be better suited to the way organisations actually operate.

Work is rarely a single isolated task. Most organisational work is made up of sequences: a request is received, information is checked, a record is opened, documents are reviewed, a response is drafted, approval is sought, a system is updated, a report is generated, and an outcome is communicated.

This is why workflow design is central to AI value. MIT Sloan research argues that AI’s largest impact comes not merely from improving individual tasks, but from reshaping entire workflows: how tasks are sequenced, grouped, and handed off between humans and machines.

AI agents are important because they can operate across sequences. They can support a chain of work rather than a single prompt. In a well-designed environment, an agent might receive a defined request, retrieve relevant information, classify the matter, prepare an output, send it for human review, and update a workflow status after approval.

This is the point at which AI begins to support organisational execution.

That does not mean agents should be given broad autonomy. It means they should be designed around specific workflows where their role, authority, data access, review requirements, and failure conditions are clearly understood.

The Adoption Signal

The market is already moving toward agentic systems.

McKinsey’s 2025 global AI survey found that 88% of respondents reported regular AI use in at least one business function. It also found that organisations are beginning to explore AI agents, with 23% of respondents reporting that their organisations are scaling an agentic AI system somewhere in the enterprise and a further 39% reporting experimentation with agents.

The same survey also shows that agent deployment remains early. McKinsey found that most organisations scaling agents are doing so in only one or two functions, and that no more than 10% of respondents in any individual business function reported scaling AI agents.

This matters because it separates market interest from operational maturity. Many organisations are interested in agents. Far fewer have embedded them into core workflows at scale.

Gartner has predicted that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028. Gartner has also warned that more than 40% of agentic AI projects may be cancelled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls.

The signal is clear: agentic AI is likely to become a major enterprise software pattern, but adoption will not automatically translate into value.

The organisations that benefit will be those that distinguish between agents as a novelty and agents as governed workflow infrastructure.

From Task Assistance to Workflow Execution

The value of AI agents will be determined at the workflow level.

A single AI assistant can help a user draft an email. An agentic workflow can receive a customer request, identify the relevant account, retrieve policy information, draft a response, flag exceptions, recommend next steps, and route the matter to the right person for review.

A single AI assistant can summarise a document. An agentic workflow can ingest a document, classify it, extract key fields, compare it against internal rules, identify missing information, create a task, and prepare an approval pack.

A single AI assistant can generate a report. An agentic workflow can monitor inputs, retrieve data, generate a report, identify anomalies, request human confirmation, distribute the final version, and archive the output.

This is the difference between productivity and execution.

The evidence base for AI in workplace settings is still developing, but early research supports the idea that well-designed AI assistance can improve operational performance. A study published in The Quarterly Journal of Economics examined the staggered deployment of a generative AI assistant to 5,172 customer support agents and found that access to AI assistance increased productivity by 15% on average, with particularly strong gains for less experienced and lower-skilled workers.

That study concerned AI assistance rather than fully autonomous agents, but the lesson is relevant: AI creates value when it is embedded into a real work context, aligned with the task, and used by people operating inside an organisational process.

Agentic AI extends this logic. It asks whether AI can support not only the production of an answer, but the movement of work through a process.

Where AI Agents Can Create Value

AI agents are most useful where work is repeatable enough to structure, variable enough to require reasoning, and valuable enough to justify integration.

The most promising early use cases are likely to be narrow, high-frequency workflows with clear inputs, outputs, permissions, and escalation points.

1. Internal Service Desks

Agents can support IT, HR, finance, procurement, legal intake, facilities, and operations support by triaging requests, retrieving policies, asking clarifying questions, preparing responses, and escalating exceptions. McKinsey reports that agent use is commonly reported in IT and knowledge management, including service-desk management and deep research use cases.

2. Document Processing

Agents can assist with reviewing, classifying, extracting, summarising, and routing documents. This may include contracts, compliance files, procurement documents, client intake forms, claims, reports, correspondence, and internal approvals.

3. Knowledge Retrieval

Agents can query internal knowledge bases, retrieve relevant materials, cite sources, and help staff apply institutional knowledge. This is especially useful in organisations where policies, procedures, templates, manuals, and prior work are distributed across multiple systems.

4. Reporting and Analysis

Agents can collect information, prepare recurring reports, identify anomalies, draft commentary, and route outputs for human review. This is particularly relevant where reporting processes are repetitive but still require judgement or contextual interpretation.

5. Customer and Client Interaction

Agents can support service pathways by classifying requests, retrieving customer information, drafting responses, suggesting next steps, and escalating matters that require human intervention.

6. Workflow Coordination

Agents can coordinate multi-step internal processes, such as onboarding, approvals, compliance checks, due diligence, procurement workflows, and operational task management.

These use cases share a common pattern. The agent does not replace the organisation’s operating model. It becomes a controlled participant within it.

The Control Problem

The same feature that makes agents powerful also makes them risky: they can act.

A generative AI system that produces a poor answer may create reputational, legal, or operational issues. An agent with access to systems can create broader consequences. It may send an email, update a record, retrieve sensitive information, trigger a workflow, execute a function, or interact with another application.

This is why autonomy must be treated as a design variable, not a default setting.

OWASP identifies “Excessive Agency” as a major risk in LLM applications. It attributes this risk to excessive functionality, excessive permissions, and excessive autonomy, and notes that the impact can affect confidentiality, integrity, and availability depending on which systems the LLM-based application can interact with.

The risk is not theoretical. OWASP provides scenarios where an LLM-based agent is granted more capabilities than required, such as an email assistant with both read and send permissions when it only needs to summarise messages. It recommends limiting extensions, minimising functionality, avoiding open-ended tools, minimising permissions, executing actions in the user’s context, requiring user approval for high-impact actions, and logging or monitoring downstream activity.

Australian and international cybersecurity agencies have made a similar point. Joint guidance published through the Australian Cyber Security Centre warns that agentic AI systems increase attack surfaces because they rely on tools, external data sources, memory bases, and interconnected components. The guidance also notes that external data sources can enable indirect prompt injection attacks, and that agentic systems can introduce cascading failures and multi-step attacks across connected components.

The implication is clear. The question is not simply whether an agent can perform a task. The question is whether the organisation can constrain, monitor, and govern the agent’s ability to act.

Why Narrow Agents Are Usually Better Than Broad Agents

The public imagination often focuses on highly autonomous agents that can handle broad objectives. In enterprise environments, however, the most useful agents are likely to be narrow, specific, and bounded.

A narrow agent is easier to test. It has fewer tools. It has clearer success criteria. It has a more predictable data boundary. It is easier to monitor. It is easier to explain to users. It is easier to govern.

A broad agent may appear more powerful, but it can also be harder to evaluate. It may interact with more systems, face more edge cases, require broader permissions, and create more ambiguous accountability.

This is supported by emerging research cautioning against overconfidence in agent benchmarks. The paper AI Agents That Matter argues that current agent benchmarks often focus too narrowly on accuracy, pay insufficient attention to cost, conflate the needs of model developers and downstream developers, suffer from inadequate holdout sets, and lack standardised evaluation practices.

NIST’s Generative AI Profile also warns against extrapolating system performance or capability from narrow, non-systematic, or anecdotal assessments. It recommends evaluating claims of model capabilities using empirically validated methods and reviewing sources and citations in generative AI outputs during pre-deployment and ongoing monitoring activities.

This is highly relevant to agent deployment. A successful demo does not prove that an agent is ready for production. A benchmark result does not prove that the agent is safe in a specific business context. A small pilot does not prove that the agent will behave reliably when exposed to real users, messy data, changing systems, and adversarial inputs.

For enterprise deployment, the right question is not “How autonomous can this agent be?”

The better question is “How much autonomy is actually required for this workflow?”

The Four Levels of Agent Autonomy

A practical way to govern AI agents is to define autonomy levels.

Level 1: Assist

The agent provides information or drafts an output, but it cannot take action. A human remains responsible for using the output.

Example: an agent summarises a policy, drafts a response, or prepares a research note.

Level 2: Recommend

The agent analyses a situation and recommends a next action, but the action must be performed by a human.

Example: an agent reviews a customer request and recommends whether it should be escalated.

Level 3: Act With Approval

The agent prepares an action and can execute it only after human confirmation.

Example: an agent drafts an email, fills in a CRM update, or prepares a document classification, but a user must approve the final action.

Level 4: Act Autonomously Within Limits

The agent can take predefined actions within a tightly controlled scope, with monitoring, logging, rollback, and escalation pathways.

Example: an agent automatically routes low-risk support tickets, updates non-sensitive workflow statuses, or performs routine checks under clear rules.

Most organisations should begin at Levels 1 to 3. Level 4 should be reserved for mature, low-risk, well-tested workflows where the organisation has strong controls, clear ownership, and the ability to detect and reverse errors.

This is consistent with joint cybersecurity guidance advising organisations to adopt agentic AI carefully, deploy incrementally, limit agents to low-risk tasks, enforce strict privilege controls, maintain continuous monitoring, apply strong identity management, and preserve human oversight.

The Architecture of a Governed Agent

A production-grade enterprise agent should not be treated as a prompt wrapped in software.

It should be treated as an operational system.

At a minimum, a governed AI agent needs a defined architecture across eight layers.

1. Task Definition

The organisation must define the agent’s purpose.

What task does it perform? What problem does it solve? What is outside scope? What does success look like? What is the failure mode? What should the agent refuse to do?

Without task definition, the agent becomes open-ended. Open-ended agents are harder to test, harder to govern, and harder to trust.

2. Data Boundary

The organisation must define what information the agent can access.

This includes internal documents, databases, folders, applications, APIs, customer records, policy libraries, templates, and external sources. A well-designed agent should only access the information required for its task, and only in accordance with the user’s permissions.

This aligns with zero trust principles. NIST describes zero trust as a cybersecurity approach that moves away from static network-based perimeters and focuses on users, assets, and resources, with no implicit trust granted based solely on network location or asset ownership.

For agents, this means “inside the organisation” is not enough. The agent must operate with explicit permissions.

3. Tool Boundary

The organisation must define which tools the agent can use.

Can it search documents? Can it send emails? Can it update records? Can it create files? Can it access a CRM? Can it call an API? Can it trigger an approval workflow?

OWASP recommends limiting the extensions and functions that LLM agents are allowed to call to only the minimum necessary, avoiding open-ended tools, and minimising permissions in downstream systems.

This is one of the most important design principles for agent deployment: do not give an agent tools it does not need.

4. Identity and Permissions

The organisation must decide whose authority the agent acts under.

Does the agent act as itself? Does it act on behalf of a user? Does it inherit the user’s permissions? Does it have a service account? Can its actions be attributed to a human owner?

OWASP recommends executing agent actions in the user’s context where appropriate and enforcing authorisation in downstream systems rather than relying on the LLM to decide whether an action is allowed.

This matters because agents can otherwise become a privilege escalation risk. An agent that acts through a high-permission account may expose or modify information that the user would not otherwise be authorised to access.

5. Human Review

The organisation must define where human approval is required.

High-impact actions should not be left to autonomous execution by default. This includes sending external communications, deleting or modifying important records, issuing decisions, approving financial actions, disclosing sensitive information, or taking steps that affect customers, employees, legal obligations, or operational continuity.

OWASP recommends human-in-the-loop approval for high-impact actions before they are taken.

Human review should not be vague. It should be designed into the workflow.

6. Logging and Auditability

The organisation must be able to understand what the agent did.

This includes what request was made, what information was retrieved, what tools were used, what outputs were generated, what actions were taken, which user initiated the process, and whether any human approvals occurred.

Logging is not only for compliance. It is necessary for debugging, improvement, incident response, accountability, and trust.

7. Testing and Evaluation

The organisation must evaluate the agent before and after deployment.

This should include task performance, error modes, security testing, adversarial testing, permission testing, user testing, retrieval quality, output quality, escalation behaviour, and failure recovery.

NIST’s Generative AI Profile recommends pre-deployment testing, empirically validated evaluation of model capability claims, structured monitoring, and ongoing assessment of system performance and risks.

Testing should be specific to the workflow. An agent that performs well on generic benchmarks may still fail in a particular organisational process.

8. Ownership and Governance

The organisation must decide who owns the agent.

An agent needs a business owner, a technical owner, a risk owner, and a process for change management. It needs rules for updating prompts, tools, permissions, data sources, integrations, and model versions. It also needs a process for pausing, rolling back, or retiring the system.

ISO/IEC 42001 provides a management system standard for organisations providing or using AI-based products or services, including requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system.

Agent governance should be part of the organisation’s management system, not an informal technical afterthought.

Human-Agent Teams

The future of agentic AI is not simply autonomous machines replacing organisational labour.

A more realistic and more useful framing is human-agent teams.

In a human-agent team, the agent handles defined tasks, coordination steps, retrieval functions, drafting, classification, or workflow movement. Humans remain responsible for judgement, exception handling, escalation, relationship management, accountability, and decisions where context, ethics, commercial sensitivity, or regulatory implications matter.

This is consistent with early empirical evidence on AI assistance in customer support. The Quarterly Journal of Economics study found that AI assistance improved productivity and helped less experienced workers improve both speed and quality, suggesting that AI can help disseminate effective practices across a workforce.

For organisations, the important question is not whether AI agents will replace or preserve every existing role. The more practical question is how work should be redistributed between humans, agents, and systems.

MIT Sloan’s workflow research is relevant here: AI value depends on how tasks are sequenced, grouped, and handed off between humans and machines.

Agents should therefore be designed into human workflows, not placed outside them.

The Risk of Agent Sprawl

As agent-building tools become easier to use, organisations may face a new problem: agent sprawl.

This occurs when teams build or deploy agents without central visibility, consistent permissions, governance, security review, or lifecycle management. The result can be similar to shadow IT, but with greater operational risk because agents may have access to tools, documents, memory, and downstream systems.

Agent sprawl creates several problems.

First, the organisation may not know which agents exist.

Second, it may not know what data they can access.

Third, it may not know what actions they can take.

Fourth, it may not know whether they are still performing accurately.

Fifth, it may not know who is accountable when something goes wrong.

This is why agent governance should begin before agent adoption becomes widespread. The organisation needs standards for approval, naming, ownership, permissions, logging, evaluation, deployment, and retirement.

Joint cybersecurity guidance on agentic AI recommends integrating AI security into existing cybersecurity frameworks rather than treating it as separate, and it notes that agentic systems create complexity because information continuously flows between AI and non-AI systems.

The governance challenge is therefore not only technical. It is organisational.

When an Agent Is the Wrong Solution

Not every AI use case requires an agent.

Some tasks are better handled by standard automation. Others are better handled by a search system, a workflow tool, a dashboard, a database rule, a form, a script, or a human process improvement.

Agents should be used where the workflow requires some combination of language understanding, contextual reasoning, tool use, variable inputs, and adaptive execution.

They should not be used simply because the technology is available.

An agent may be the wrong solution where the process is fully deterministic, where the cost of error is high, where the system cannot be monitored, where data access cannot be controlled, where the use case is too broad, where a simpler automation would be more reliable, or where the organisation cannot clearly define ownership.

This is one reason Gartner’s caution about cancelled agentic AI projects is important. Agentic AI may become widespread in enterprise software, but projects with unclear value, poor governance, or excessive cost may fail.

The discipline is in knowing when not to deploy an agent.

A Practical Deployment Pathway

A serious agent deployment should move through a deliberate pathway.

1. Identify the Workflow

Begin with a real process, not an abstract desire to “use agents”. The workflow should be frequent, valuable, and sufficiently structured to map.

2. Map the Human Process

Document the current process: inputs, systems, decisions, handoffs, approvals, documents, exceptions, and outputs.

3. Identify the Agent Role

Decide what the agent should do. Is it assisting, recommending, acting with approval, or acting autonomously within limits?

4. Define Boundaries

Set data boundaries, tool boundaries, permission boundaries, review requirements, escalation rules, and failure conditions.

5. Build in a Controlled Environment

Develop the agent in a sandbox or controlled environment before exposing it to live data or production systems.

6. Test Against Realistic Scenarios

Test normal cases, edge cases, adversarial prompts, incorrect data, missing data, ambiguous instructions, permission limits, and failure recovery.

7. Pilot With Human Oversight

Deploy to a small group, monitor usage, review outputs, collect feedback, and adjust the workflow.

8. Scale Gradually

Expand only when performance, security, governance, and user adoption are understood.

9. Monitor Continuously

Track accuracy, exceptions, user overrides, tool usage, access patterns, cost, latency, satisfaction, and incidents.

10. Govern the Lifecycle

Review the agent over time. Update it, restrict it, expand it, or retire it as the organisation changes.

This pathway reflects a broader principle from secure AI system development guidance: security should be addressed across secure design, secure development, secure deployment, and secure operation and maintenance, not added after release.

The ADVA Labs View

AI agents may become one of the most important layers of organisational execution.

Their value will not come from autonomy alone. It will come from the disciplined design of systems that allow agents to support real workflows within clear boundaries.

The organisations that benefit from agents will not simply be those that deploy the most agents. They will be those that understand where agents belong, what they should be permitted to do, how they should interact with humans, which systems they can access, and how their behaviour will be governed.

This aligns closely with the broader ADVA Labs view of applied AI. The next phase of AI will be defined not by access to models, but by the ability to convert AI into operational capability.

Agents are part of that transition.

They can help organisations move work through systems more intelligently. They can support teams with classification, retrieval, drafting, coordination, escalation, reporting, and process automation. They can reduce friction in workflows that are currently slow, fragmented, or manually intensive.

But they must be implemented carefully.

An agent without boundaries is a risk. An agent without governance is a liability. An agent without workflow design is a demo. An agent without ownership is an operational gap.

The future of agentic AI belongs to organisations that treat agents not as digital workers operating in isolation, but as controlled components of a broader operating model.

The next layer of enterprise intelligence will not be built by giving AI unlimited autonomy.

It will be built by designing the right relationship between humans, agents, systems, and governance.