AI agents at work: what to assess before delegating business processes

OpenAI describes growing use of agents such as Codex for longer and cross-functional tasks. For organizations, the issue is not adopting a new chatbot, but redesigning processes, permissions, controls and metrics.

From chat to delegated work: the operational shift

OpenAI has published an article and a paper on how AI agents, particularly Codex, are changing the use of AI at work. According to the source, the unit of interaction is moving from a single chat request to longer delegated tasks: activities that may take minutes or hours, use tools, iterate toward a goal and produce intermediate outputs.

For organizations, the most interesting point is not the percentage itself, but the change in posture. OpenAI states that, by May 2026, 80.6% of a sample of individual users had submitted at least one request estimated to represent more than 30 minutes of human work, 70.2% more than one hour, and 25.6% more than eight hours. The same source specifies that these thresholds are directional estimates, also based on model evaluations, and should not be read as exact productivity measurements.

For companies, public bodies and digital teams, the practical point is clear: an agent should not be treated as “a more powerful chat”. If it is assigned part of a process, it needs clear objectives, controlled access to data and tools, acceptance criteria, audit trails and defined human responsibilities. Otherwise, organizations risk automating disordered fragments and increasing operational complexity and debt.

Which processes to choose, and which to avoid

A pilot project with AI agents should start from real but well-bounded processes. Good candidates include repeatable activities with digital inputs, verifiable rules and controllable outputs: report preparation, document classification, data transformation, customer care support, technical draft generation, log analysis, knowledge base updates or internal automations.

Processes are more risky when they involve high-impact decisions, unsegmented sensitive data, ambiguous criteria or organizational dependencies that are not formalized. If an activity currently works only because one person knows the exceptions, shortcuts and tacit context, the agent does not solve the problem: it makes it less visible.

OpenAI also reports growing use by non-technical profiles, such as legal, finance, recruiting and business functions. This is plausible and relevant: many business bottlenecks originate from waiting for technical support for data extraction, scripts, controls, small automations or structured analysis. But direct access by non-technical roles to agents capable of operating on systems and code requires stronger guardrails, not weaker ones.

This is where adoption must be designed as a responsible enterprise AI initiative, not as the simple rollout of a new tool. The right question is not “how many people will use it?”, but “which activities can be delegated without losing control, quality and traceability?”

Prerequisites: data, permissions, integrations and security

Agents become useful when they can interact with the operational environment: repositories, CRM, ERP, documents, ticketing systems, databases, cloud tools and development pipelines. This increases potential value, but also expands the risk surface.

Before integrating them into workflows, at least four prerequisites are needed. First: organized data accessible through consistent authorization levels. An agent should not see more information than it needs for the task. Second: identities and permissions separated from personal accounts, with minimum and revocable privileges. Third: complete logging of prompts, actions, invoked tools, outputs and approvals. Fourth: test environments or sandboxes for operations that may modify data, code or configurations.

Governance must not be a document separated from technology. It must become executable policy: limits on what the agent can do alone, when human approval is required, which data it cannot use, which outputs require review, and which actions are blocked by default. In this sense, digital governance consulting and a robust cybersecurity and cloud design become part of the agent architecture, not follow-up activities.

A common mistake is measuring speed only. If an agent produces more output but generates errors that are hard to detect, excessive review requests or non-reproducible behaviors, the operational balance can become negative.

How to measure a pilot without being driven by hype

An effective pilot should last long enough to observe real usage, but remain limited in domain, users and permissions. Metrics should include estimated time saved, output quality, human correction rate, number of escalations, critical errors avoided or generated, user satisfaction, cost per completed activity and impact on the systems involved.

It is useful to distinguish three levels. The first is assistance: the agent prepares drafts or analyses, but does not act on systems. The second is controlled execution: it can use tools, but with human approval on sensitive steps. The third is partial delegation: it operates autonomously within narrow and monitored boundaries. Jumping directly to the third level is rarely a good choice.

OpenAI’s news points to a credible direction: agents are becoming more cross-functional work tools, less confined to software development. But for a mature organization, the goal is not to replicate OpenAI’s internal usage. It is to identify where agentic delegation creates measurable value, with acceptable risks and clear responsibilities.

The real transformation does not happen when an agent answers better. It happens when processes, data, permissions and controls are designed so that the organization can delegate digital work without losing governance.

Approfondimenti Dedaloop

Fonti