The Architecture of AI Work Agents: Execution, Permissions and Deliverables

A quarterly business review is rarely produced inside one application. It requires information to be retrieved from several systems, reconciled, interpreted, checked and assembled into a coherent deliverable. The software may be connected, but the work still depends on people to move it forward.

That coordination burden is beginning to change. A user can increasingly describe an intended outcome and delegate a sequence of activities to an agent that can retrieve information, use tools, work with files, interact with applications and prepare an output for review.

The important development is not simply that a model can perform more actions. It is that a new kind of working environment is forming around delegated outcomes. These environments combine intelligence with context, connectivity, orchestration, execution and control. Their architecture determines what an agent can do, what it is allowed to do and how a person can establish whether the work is complete.

This is the emerging agent workspace: an operational environment in which people assign objectives to intelligent systems, supervise their progress and review the work they produce.

From conversational assistance to operational systems

A conversational assistant is primarily organised around an exchange. A user asks a question or provides material, and the system returns an answer, explanation, draft or recommendation. It may use tools, but the interaction is usually centred on the response.

An agent is organised around an objective. It interprets a goal, determines a sequence of activities, uses available tools, observes intermediate results and adjusts its approach when necessary. An agent workspace provides the surrounding environment in which that work can be initiated, executed, monitored and governed.

The distinction is architectural rather than cosmetic. A longer chat does not automatically become an agent workflow. The system must manage task state, connect to operational resources, execute actions, handle exceptions and expose enough information for a person to supervise the result.

Agent workspace

An environment that enables people to delegate multi-step objectives to intelligent software systems, provides the context and tools required for execution, and makes progress, permissions and deliverables available for human oversight.

The term describes an emerging product category rather than a universally standardised architecture. Products combine these capabilities in different ways. Some operate primarily in managed cloud environments, others extend into local files and desktop applications, while enterprise platforms focus on identity, governance and integration across organisational systems.

The architecture behind an agent workspace

An agent workspace can be understood through a set of cooperating responsibilities. These are conceptual layers, not a claim that every vendor implements the same internal components or sequence.

Intent and context

The process begins with an objective, its constraints and the information needed to interpret it. Context may include user instructions, documents, organisational policies, task history, structured records and information retrieved from connected systems.

Context management is more than storing conversation history. The workspace must select relevant information, respect access boundaries, distinguish current material from outdated material and provide the model with enough context to act without overwhelming it with unrelated data.

Planning and orchestration

Planning translates an objective into activities, dependencies and completion conditions. Orchestration manages the work over time: sequencing tasks, assigning tools or specialised agents, tracking state, handling interruptions and deciding when a result needs another pass or human input.

Multi-agent coordination can help divide complex work, but adding agents does not automatically improve the result. Delegation introduces communication overhead, duplicated effort, inconsistent intermediate outputs and more complicated failure diagnosis. The architecture needs clear task boundaries and a way to reconcile work before it becomes a final deliverable.

Tools and execution

Models do not directly operate every external system. They rely on tools and execution environments that expose particular capabilities. These may include APIs, application connectors, browser interfaces, file operations, code execution, controlled desktops or cloud-hosted computers.

The execution environment is consequential. A browser agent working in an isolated cloud session has a different access model from an agent operating on a user's desktop. A self-hosted gateway has different operational responsibilities from a managed workspace. The location of execution, the resources exposed to it and the network paths it can reach all affect the system's risk profile.

Control and governance

Identity, permissions, approvals, monitoring and auditability define the authority under which an agent operates. These controls should be designed into the system from the beginning. They determine which resources an agent can discover, read or change, which actions require confirmation and how an organisation can reconstruct what happened.

Governance is not a final security layer added after an agent has been built. It shapes context retrieval, connector design, execution and recovery. The same task may be acceptable when the agent can read a report but unacceptable when it can alter the underlying financial records.

Verification and recovery

Execution produces intermediate states and outputs. Verification checks whether they satisfy the task requirements, whether the information is supported and whether the intended changes actually occurred. Recovery addresses unavailable tools, incomplete information, failed operations and unexpected application behaviour.

A completed action is not necessarily a completed task. A document may have been generated but contain unsupported claims. A form may have been submitted with an incorrect value. A workflow may have run without satisfying the original objective. The workspace must distinguish activity from verified completion.

The deliverable

The final output may be a report, spreadsheet, presentation, code change, research brief, updated record or completed process. Its value depends on whether it meets the requested purpose, preserves evidence and assumptions, and can be reviewed by the person accountable for the outcome.

Planning is not the same as execution

Agent demonstrations can make planning and execution appear like one continuous capability. In practice, they involve different technical requirements.

A model may correctly interpret a request and produce a sensible sequence of steps. That does not establish that the tools required by those steps are available, that credentials are valid, that the target application is behaving as expected or that the operation is authorised.

Execution introduces external state. Files may change, APIs may fail, sessions may expire, websites may present unexpected interfaces and connected systems may return incomplete or contradictory information. The agent must observe these conditions rather than assume that an intended action succeeded.

For this reason, tool invocation should be treated as a controlled transaction wherever possible: identify the action, check its authority, execute it, inspect the result and record the outcome. Actions that are difficult to reverse or have material consequences should have stronger approval requirements.

Tool protocols such as the Model Context Protocol can standardise how applications expose context and capabilities to models. They do not, by themselves, guarantee that access is appropriately authorised or that an agent will use a tool safely. Authentication, authorisation, consent, scope and policy enforcement remain separate design responsibilities.

The execution environment determines what an agent can actually do

The term computer use can describe several different arrangements. Treating them as interchangeable obscures important differences in data access, persistence and security.

Managed cloud workspaces provide a hosted environment in which tasks can run independently of the user's active desktop session. The provider manages much of the execution infrastructure, while the user or organisation configures access to connected services and data. The key questions concern isolation, retention, network access, identity and the controls available to the customer.

Local desktop execution places the agent closer to the user's files and applications. This can make existing workflows accessible without moving every resource into a separate cloud environment. It also means that permissions, local credentials, application state and the security of the host device become central considerations.

Sandboxed execution limits the resources available to a task through a controlled runtime. A sandbox can reduce exposure, but its effectiveness depends on configuration, isolation boundaries, mounted files, network policy and the privileges of the process running it. The word sandbox should not be treated as a universal guarantee of containment.

Self-hosted gateways allow an organisation or individual to operate the agent gateway and choose model providers, channels, plugins and execution tools. This offers flexibility and control over deployment, but also transfers responsibility for secrets, updates, network exposure, plugin trust, logging and incident response to the operator.

Persistent cloud computers retain files, applications and task state between sessions. They are different from temporary task sandboxes that are created for a specific run and discarded afterwards. Persistence enables continuity, but it also creates a longer-lived environment that needs lifecycle management, access controls and data-retention policies.

Six approaches to agentic work

The current market contains products with different origins and operating assumptions. The following examples are not a ranking. They illustrate how companies are assembling the capabilities of an agent workspace and where their approaches differ.

Perplexity Computer: delegated work across a managed cloud environment

Perplexity Computer extends the company's research-oriented experience into a broader environment for delegating multi-step work. Its product positioning combines task orchestration, access to connected tools and the use of specialised agents to work across research, analysis, writing and other knowledge tasks.

The architectural distinction is the managed cloud workspace. Work can proceed beyond a single conversational response, with the system coordinating intermediate activities and returning an output for the user. Perplexity's descriptions of model choice and agent delegation should be understood as product capabilities and vendor statements, not as independently audited details of every internal routing decision.

For users, the central questions are which data sources and tools can be connected, how task execution is isolated, what actions require confirmation and how the resulting work can be checked. The cloud model reduces the need to run the workflow on a personal computer, but it makes the provider's execution, retention and access controls especially important.

OpenClaw: a configurable, self-hosted agent gateway

OpenClaw takes a different approach. Rather than presenting only a managed workspace, it provides an agent gateway that an operator can host and configure with model providers, messaging channels, plugins and tools. Its flexibility makes it possible to connect agents to a broad range of environments, including local devices and software interfaces.

The advantage is control over deployment choices and integration. The trade-off is that self-hosting does not remove security responsibilities. The operator must manage gateway exposure, credentials, plugin provenance, tool permissions, shell and browser access, updates and monitoring. A locally hosted gateway may still send prompts or data to external model providers and connected services.

OpenClaw is therefore best understood as configurable agent infrastructure rather than a turnkey enterprise control plane. Its security posture depends heavily on how it is deployed and operated. In particular, sandboxing and tool restrictions must be inspected in the actual configuration rather than assumed from the fact that the gateway is self-hosted.

ChatGPT Work: supervised execution across files and applications

ChatGPT Work represents the move from conversational assistance towards a workspace for longer tasks and finished business deliverables. Its product direction combines task planning, connected applications, file handling, research and the creation of documents, spreadsheets and presentations.

Its execution model should not be described as one undifferentiated computer environment. Cloud-based work, the cloud browser and permission-based access through the desktop app are distinct paths. A cloud browser session does not simply inherit the user's local browser session, and local access depends on the permissions granted through the relevant desktop workflow.

This separation matters for enterprise deployment. Administrators and users need to understand where a task runs, which connected resources it can access, whether local files are involved and what approval or review is required before consequential actions are taken.

Claude Cowork: work across documents, tools and task contexts

Claude Cowork developed around document-intensive and multi-step knowledge work. Its capabilities bring Claude closer to selected files, folders and connected tools, allowing tasks to involve more than material manually pasted into a conversation. Anthropic has also been bringing Cowork capabilities into a more unified Claude experience.

Its architecture needs to be understood in terms of the session and access mode being used. Cloud sessions and local desktop access are not identical execution arrangements. When local resources are made available, the scope of folder and application permissions becomes part of the trust boundary. When work is processed in the cloud, the relevant data-handling and session controls must also be considered.

The practical question is not simply whether Cowork can work with files. It is how access is granted, how the user can inspect the actions being taken and what protections apply to destructive or externally visible operations.

Google Gemini: productivity integration and enterprise agent infrastructure

Google approaches agentic work from two related directions. Gemini capabilities are integrated into Google's productivity and information environment, while the enterprise agent platform provides infrastructure for building, deploying and governing agents.

These should not be conflated. Gemini features inside Workspace applications operate within the context of those products and their permissions. The enterprise platform addresses a broader lifecycle that can include agent development, deployment, identity, policy enforcement and operational management.

Capabilities such as Agent Identity and Agent Gateway address distinct governance concerns. Identity helps establish which agent is acting. Gateway controls can mediate access to resources and network destinations. Their presence does not mean every custom agent or third-party integration is automatically governed correctly; policies and connector scopes still need to be designed and maintained.

Google's strategic advantage is the combination of productivity applications, enterprise identity and cloud infrastructure. The important architectural question is how consistently governance can be applied when agents move beyond Google's own environment into third-party systems.

Manus: general-purpose task execution and persistent cloud computing

Manus is positioned as a general-purpose agent for research, creation and multi-step digital tasks. Its approach combines planning with a cloud execution environment in which work can involve browsing, files, applications and the production of deliverables.

A useful distinction is between a temporary task environment and a persistent Cloud Computer. A task sandbox may exist to execute a particular workflow. A persistent computer retains its environment and state between tasks, making it possible to continue working with files, applications and processes over time.

Persistence changes the operational questions. The environment needs clear ownership, access boundaries, retention rules and lifecycle controls. It should be possible to understand what remains in the environment after a task ends and who can access it later.

Comparing the operating models

The products differ less by the abstract idea of an agent than by where they place execution, how they connect to systems and who carries responsibility for control.

Identity and permissions define an agent's authority

When an agent can access business applications, its permissions become part of the organisation's control structure. The relevant question is not only which tools it can call, but which identity it uses, what authority that identity carries and how the authority is constrained.

Where supported, agents should have identifiable, purpose-specific identities rather than relying on an employee's unrestricted personal credentials. Access should follow least privilege: provide only the resources and operations required for the assigned task, for only as long as they are needed.

Permissions should also distinguish reading from changing. An agent preparing a performance report may need read access to sales and finance records and permission to create a draft presentation. It does not necessarily need the authority to alter source records, send the presentation externally or approve a financial transaction.

Approval requirements should reflect consequence and reversibility. Low-impact retrieval may proceed with limited intervention. Sending messages, purchasing goods, deleting files, deploying code or changing important records should generally require explicit policy controls and, where appropriate, human confirmation.

Protocols and connectors are only part of this design. A standardised tool interface does not replace authentication, authorisation, consent, credential management or audit logging. These controls must be enforced by the application, gateway and execution environment.

Reliability must be designed into the workflow

Agent workflows introduce several points at which work can diverge from the original objective. Instructions may be ambiguous, retrieved context may be incomplete, a tool may fail, an application may change or an intermediate result may be accepted without adequate checking.

Reliability therefore depends on the entire workflow rather than the quality of one model response. The system needs explicit completion conditions, observable tool calls, error handling, bounded retries and a way to escalate unresolved uncertainty.

Verification should be appropriate to the deliverable. A research report needs traceable sources and support for its claims. A spreadsheet needs checks on formulas, units and data transformations. A software change needs tests and review. A completed business process needs evidence that the intended state was reached in the target system.

Recovery is equally important. If an operation fails halfway through, the workspace should establish which actions succeeded, which did not and whether repeating the task could create duplicate or harmful effects. Idempotent operations, transaction boundaries and explicit state tracking can reduce these risks where the underlying systems support them.

Human oversight is useful only when it is informed. A person should be able to see what the agent intends to do, which information it relied on, what has already happened and what decision is being requested. An approval prompt without adequate context transfers responsibility without providing meaningful control.

When an agent can be manipulated

Agent security differs from the security of a text-only assistant because the system can act on information it reads. A malicious instruction embedded in a web page, email, document or other retrieved content may attempt to influence the agent's behaviour. This is commonly discussed as prompt injection.

The risk becomes more consequential when the agent has access to sensitive information and tools that can modify external systems. A manipulated agent might disclose information, follow an unintended link, misuse a connector or perform an action outside the user's original purpose.

Prompt injection should not be treated as a problem that can be solved solely by asking the model to ignore malicious instructions. Defences need to be layered: limit tool authority, separate untrusted content from trusted instructions, restrict network destinations, validate actions at the point of execution, require approval for sensitive operations and log activity for investigation.

OWASP's guidance for agentic applications identifies risks involving excessive agency, tool misuse, identity and privilege abuse, and related failures in agent design. The practical lesson is that the system's authority must remain bounded even when the model's interpretation is wrong or manipulated.

What enterprises need before delegating work

Enterprise adoption requires more than enabling an agent feature. Organisations need to decide which workflows are suitable for delegation, what information can be accessed, which actions are permitted and who remains accountable for the outcome.

A practical deployment begins with a bounded workflow and a clear baseline. The organisation should document the existing process, expected output, quality criteria, sensitive data involved and actions that must remain under human control. The agent can then be introduced with limited connectors and narrowly scoped permissions.

Operational readiness also requires a way to observe usage and cost. Teams need to understand model consumption, tool calls, execution time, exceptions, retries and human review effort. Without this information, a workflow may appear efficient while shifting cost into supervision, correction or infrastructure.

Governance should cover the full lifecycle: who can create or configure agents, how they receive identities and credentials, how connectors are approved, how changes are reviewed, how logs are retained and how an agent is disabled or retired. The controls should apply to custom-built agents as well as packaged products.

Most importantly, accountability cannot be delegated to the agent itself. The organisation remains responsible for the business process, the data it exposes and the consequences of actions performed through its systems.

The emerging architecture of work

The agent workspace introduces an operational layer between people and the applications they use. It does not eliminate databases, communication platforms, business systems or specialist software. It creates a way to coordinate activity across them around an intended outcome.

That position could become strategically important. The workspace that manages context, access, execution and review may influence how users interact with enterprise software and how organisations distribute work between employees and agents. But the outcome is not determined by the conversational interface or the model alone.

Each platform makes different choices about managed infrastructure, local access, persistence, integration and governance. Those choices shape the practical boundary between what an agent can attempt and what an organisation can responsibly delegate.

The strongest systems will not necessarily be those that promise the greatest autonomy. They will be those that make authority understandable, execution observable, failures recoverable and deliverables verifiable.

As software becomes more capable of acting across applications, the design of the workspace becomes as important as the intelligence of the model operating within it. Execution, permissions and verification are not supporting details. They are the foundations on which delegated work depends.