OpenAI Presence Is Here. Is Your Workflow Ready for an Agent?
By Greg Nowak. Updated 25 August 2026.
OpenAI Presence promises something more substantial than another chatbot: managed voice and chat agents that can use company systems, take approved actions and hand work to people when necessary. It is available through limited general availability for eligible enterprise customers, with deployments led by OpenAI engineers and selected systems integrators—not through a self-service subscription.
That makes Presence interesting, but it does not make every process ready for an agent. Before comparing models or booking demonstrations, a business needs to answer a more useful question: is this workflow clear, controlled and valuable enough to automate safely?
Presence changes the conversation from answers to actions
A conventional chatbot mainly returns information. An agent can retrieve a customer record, interpret a policy, update a system, send a message or begin another process. Once software can act, operational weaknesses become delivery risks.
Those weaknesses are rarely exotic. The correct account status may differ between two systems. An experienced employee may know an exception that never reached the procedure manual. Nobody may own the final approval. A transfer to customer service may lose the context already collected.
OpenAI describes Presence as a combination of models, policies, guardrails, approved actions, simulations, evaluations, escalation rules and controlled improvements after launch. The practical implication is important: buying the platform does not remove the work of defining the job. It makes that work visible.
Start with one job, not an ambition
“Improve customer service with AI” is not a workable first scope. “Handle delivery-status enquiries using approved order data, escalating damaged or disputed orders to a named team” is much closer.
A useful first workflow has a recognisable trigger, a defined finish and an accountable owner. It happens often enough to matter, but remains narrow enough for the team to inspect its normal route and important exceptions. If the work is already deterministic and well served by conventional automation, adding an agent may only create unnecessary complexity.
OpenAI’s own agent guidance recommends agents for work involving contextual decisions, unstructured information or rules that have become difficult to maintain. That is a better filter than choosing whichever process currently consumes the most staff time.
| Readiness question | Ready to test | Fix this first |
|---|---|---|
| Is the job bounded? | Trigger, outcome and owner are explicit | The brief covers several teams or unrelated outcomes |
| Can the process be explained? | Normal steps and common exceptions are documented | Success depends on unwritten staff knowledge |
| Is the data dependable? | Sources, freshness and ownership are known | People routinely reconcile conflicting records |
| Is authority controlled? | Read, write and approval rights are separated | Broad access is requested “just in case” |
| Does handoff preserve context? | A person receives the history and next required action | The customer or employee must start again |
| Can performance be evaluated? | Representative cases have expected outcomes | Approval depends on an impressive demonstration |
Map the work people actually perform
Follow the workflow from the event that starts it to the final recorded outcome. Note what information arrives, which systems an employee checks, what decisions they make, what actions follow and how the organisation knows the work is complete.
Then examine the awkward cases. What happens when required information is missing, systems disagree, a tool is unavailable or the request falls outside policy? For every important step, document:
- the context and source data required;
- the applicable policy or operating procedure;
- the tools the agent may use;
- the action it may take independently;
- the point at which approval or human ownership is required; and
- the information transferred during a handoff.
This exercise often uncovers process problems worth fixing regardless of the technology selected.
Treat permissions as workflow design
An agent should receive the access required for its defined job, not an expanding collection of permissions added whenever development encounters friction. Separate reading from acting: an agent might inspect an account and draft a resolution while a person remains responsible for changing the record or contacting the customer.
Classify actions by consequence. Read-only lookups may run automatically. Reversible updates might require logging and thresholds. Payments, cancellations, sensitive communications and other consequential actions may require explicit approval or remain entirely outside the agent’s authority.
This is not unique to Presence. Microsoft’s Work IQ documentation similarly emphasises permission-aware access, policy enforcement and logging of tool calls. Whichever platform is chosen, the business should be able to establish which identity acted, what information informed the action and whether it stayed within policy.
Use a prototype to investigate failure
A focused prototype should test the uncertain parts of the workflow, not imitate the happiest path in a sales demonstration. Can the agent retrieve the right record? Does it select the correct tool? Will it stop when information conflicts? Can it transfer the case with enough context? Can a proposed action be prevented or reversed?
Create an evaluation set from representative, appropriately handled business cases. Include routine requests, incomplete information, ambiguous instructions, unusual variations, attempted policy bypasses and tool failures. Score the complete behaviour: interpretation, source use, tool selection, policy compliance, action and escalation—not just whether the final answer sounds convincing.
Plan production ownership before launch
Pre-launch evaluation cannot reproduce every production condition. NIST’s 2026 monitoring report highlights the need to observe functionality, operations, human interaction, security, compliance and wider impacts after deployment.
Decide who will review failures and escalations, which signals trigger investigation and who may approve changes. Useful measures might include successful completion, human handoff, incorrect tool use, approval requests, tool failures and emerging request types. Each change should return through representative tests before controlled release.
Choose the delivery route after the readiness review
Presence may suit an eligible enterprise with a repeatable, high-volume voice or chat workflow and a preference for a managed deployment. A custom OpenAI API implementation may make more sense when the business needs greater control over channels, architecture, integrations or delivery. In other cases, the correct decision is to improve the data, procedure or ownership before building anything.
Greg can help map the process, define permissions and handoffs, build a focused prototype, create evaluation cases and turn the findings into a practical buy, build or wait decision. If an agent project is moving faster than its operating model, start with a workflow-readiness conversation.
Related on GrN.dk
- A Voice Agent Is Only Ready When the Human Handoff Works
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
- Your AI Workflow Needs an Acceptance Test Before It Meets Customers
Need help with this kind of work?
Assess your agent workflow with Greg Get in touch with Greg.