Conversational AI waits for a prompt and returns an answer. An agentic product is intended to carry work forward: it may retrieve company data, use software tools, update records, trigger processes, or prepare decisions for approval. That shift turns an interface experiment into an operating-model decision.
A TechCrunch interview with OpenAI head of product Thibault Sottiaux discusses agents through a product and user-experience lens. The important procurement implication is not that businesses should grant an agent broad autonomy. It is that operators now need to evaluate AI as a participant in workflows rather than merely as a text-generation feature. The controls surrounding an agent—what it can see, what it can change, when it must stop, and how its actions are reviewed—matter as much as answer quality.
The source provides context for this product shift. The due-diligence framework below is an operating recommendation, not a description of specific OpenAI capabilities or commitments.
Start with a bounded job, not a general-purpose promise
“An agent that helps the operations team” is not a deployable use case. It does not define the start condition, permitted actions, completion criteria, or consequences of failure. A better candidate is narrow enough to express as a workflow: collect specified information from approved systems, apply documented rules, produce a draft action, and route exceptions to a named person.
Before evaluating vendors, write a task boundary containing five elements:
- Trigger: What event starts the work?
- Inputs: Which records, documents, or messages may be used?
- Actions: What may the agent read, draft, recommend, create, or change?
- Stop conditions: Which ambiguities, risk signals, or missing data require escalation?
- Definition of done: What observable output completes the task?
Prefer an initial workflow with frequent volume, visible outcomes, reversible actions, and enough historical examples for testing. Avoid making the first deployment responsible for irreversible payments, legal commitments, employee decisions, or destructive system changes. High-value work is attractive, but recoverability is more important during early deployment.
Treat permissions as a product requirement
An impressive demonstration can conceal an unsafe permission model. Ask the supplier to map each proposed action to a system permission and explain whether access can be restricted by role, record type, workspace, field, transaction value, or environment.
Read access and write access should be assessed separately. An agent may need to inspect an order to classify an exception without needing authority to modify that order. Likewise, drafting a customer response does not require permission to send it. Apply least privilege: grant only the access required for the defined task, then expand it only after evidence justifies the change.
Due diligence should cover the agent’s identity, credential storage, authentication method, permission revocation, and separation between test and production environments. Operators should also establish what data can enter prompts or working context, how long it is retained, whether sensitive fields can be excluded, and how deletion or access requests are handled. These questions must be answered in contractual and technical terms rather than with general assurances about security.
Place human approval at the point of consequence
A human “in the loop” is not meaningful unless the loop has a defined location and purpose. Requiring approval for every intermediate step can erase the efficiency benefit. Reviewing only after execution provides little protection when actions are difficult to reverse.
Classify actions by consequence. Low-risk, reversible activity may run automatically and be sampled afterward. Material but reversible changes can require approval above a confidence, value, or exception threshold. Irreversible or regulated actions should remain blocked until an authorised person approves them.
The approval screen should show the proposed action, supporting evidence, relevant source records, uncertainty or missing information, and the expected system change. A reviewer who must reconstruct the agent’s reasoning across several applications becomes a bottleneck rather than an effective control.
Escalation also needs an owner and deadline. Specify who receives an exception, what context accompanies it, how urgent cases are prioritised, and what happens when nobody responds. The agent must fail closed where silence would otherwise produce an unauthorised action.
Demand accountability, auditability, and recovery
Accountability cannot be assigned to “the AI.” Name a business owner for outcomes, a process owner for workflow rules, a technical owner for integrations and access, and an incident owner for failures. The vendor may support the system, but the company deploying it remains responsible for deciding where it is allowed to operate.
Require an audit trail that records the initiating event, data sources consulted, tool calls made, approvals requested, approver identity, final action, timestamps, and error state. Logs should be searchable and exportable for investigations. Ask how long they remain available and whether sensitive information can be protected without making the record useless.
Testing should extend beyond ideal examples. Construct cases involving missing fields, contradictory documents, stale records, duplicate requests, unusual formatting, unavailable integrations, revoked permissions, malicious instructions embedded in retrieved content, and changes made by another user during execution. Test whether the agent stops safely, repeats an action, invents a workaround, or escalates with sufficient context.
Every permitted write action needs a recovery plan. Determine whether it can be reversed automatically, whether the previous state is preserved, who may initiate rollback, and how downstream systems are corrected. Also define a kill switch that can suspend the agent without disabling the underlying business process.
Measure the workflow, not the novelty
ROI should be established against a baseline before deployment. Record current handling time, waiting time, completion rate, rework, error frequency, escalation volume, and cost of exceptions. Select the measures that reflect the bounded job rather than collecting every available metric.
Track business outcomes alongside control metrics. Useful measures can include time to completion, accepted outputs, corrections after execution, approval rejection rates, unresolved exceptions, duplicate actions, and incidents by severity. A reduction in employee touch time is not a gain if rework moves to another team or customers experience more errors.
Include the full implementation burden: integration work, data preparation, permission administration, reviewer time, monitoring, training, incident response, and process redesign. The relevant comparison is not subscription price versus labour cost; it is the total cost and performance of the agentic workflow versus the current workflow and simpler automation alternatives.
Set the deployment contract before system access
Before production access is granted, operators should require a written deployment contract covering the task boundary, approved systems, read and write permissions, prohibited actions, approval gates, escalation owners, logging, retention, rollback, incident notification, performance reporting, and suspension rights.
Begin in a test environment, then use shadow mode where practical: the agent produces proposed actions without executing them. Compare those proposals with actual operator decisions, investigate disagreements, and refine rules. A limited production pilot should cap users, transaction types, or action values and include explicit criteria for expansion or withdrawal.
Reporting should expose both value and risk. Establish a regular review showing workload processed, outcomes achieved, human interventions, errors, near misses, access changes, integration failures, and unresolved incidents. Require notice when models, tools, workflow logic, or material system dependencies change, because previous test results may no longer represent current behaviour.
The decisive procurement question is therefore not whether an agent can complete a polished demonstration. It is whether the business can specify its authority, observe its work, interrupt it, recover from mistakes, and prove that the resulting workflow performs better. Until those conditions are documented and tested, access to company systems should remain narrow, reversible, and supervised.
