By Greg Nowak. Updated 25 October 2026.
OpenAI Presence brings voice and chat agents into business workflows: finding information, using company systems, taking approved actions and passing work to people. The useful question for an owner or operations lead is what happens when the agent reaches an exception your team normally resolves through experience.
Before commissioning a deployment, define the job, its boundaries and the person responsible when something goes wrong. That preparation gives you a firmer basis for choosing a supplier, estimating effort and deciding whether an agent is worthwhile.
What OpenAI Presence offers today
As of 25 October 2026, Presence is available to eligible enterprise customers through limited general availability. Deployments involve OpenAI Forward Deployed Engineers, selected partners or both. Access depends on workflow fit, implementation readiness and delivery capacity; channels, integrations, pricing and service commitments are agreed for each deployment. OpenAI’s Presence overview explains those boundaries.
The product combines policies, permissions, approved actions, testing and production improvement. OpenAI’s launch announcement describes a process where proposed changes are tested and approved. Your organisation still has to decide which outcomes are acceptable and who can authorise a change.
Choose one job with a visible finish
“Improve customer service” leaves too much open. A better starting brief is: “Answer delivery-status enquiries from the order system, record the outcome, and transfer damaged or disputed orders to fulfilment.” You can inspect whether that job was completed correctly.
Write down the trigger, information required, permitted actions, completion condition and accountable owner. Then follow an actual case with the employee who handles it. Ask where they check another system, make an exception or contact a colleague.
If every input and decision follows a fixed rule, assess conventional automation first. An agent becomes a stronger candidate when interpreting varied requests or unstructured information is a substantial part of the work.
| Readiness check | Evidence to bring | Resolve before launch |
|---|---|---|
| Scope | One trigger, outcome and owner | Several unrelated jobs bundled together |
| Policy | Current procedure and documented exceptions | Decisions depend on unwritten staff knowledge |
| Data | Authoritative source for each required field | Conflicting records with no agreed resolution |
| Authority | Separate read, draft, write and approval permissions | Broad credentials granted for convenience |
| Handoff | Receiving team, context and fallback route | Nobody owns rejected or unanswered transfers |
| Acceptance | Representative cases and expected outcomes | Sign-off depends on a smooth demonstration |
Give the agent authority in stages
Start by separating what the agent can read, propose and change. For a delivery workflow, retrieving tracking information may be appropriate for automatic execution. Changing an address after dispatch needs a different decision. Refunds or cancellations may require approval or remain with staff.
Enforce those boundaries in the connected systems and tools. Give the agent only the access its job needs, validate proposed changes and record who or what performed each action. A prompt telling the agent to behave carefully cannot replace access control.
Also decide what happens after a timeout. If an update may have succeeded, the integration should check the recorded outcome before retrying. Repeating a message is inconvenient; repeating a consequential transaction can create real cleanup work.
Make the handoff part of the workflow
“Escalate to a human” needs an operational definition. Name the receiving queue, confirm when it is staffed and specify the fallback if nobody accepts the work.
The receiving person should get the request, verified identity where relevant, records consulted, actions attempted and reason for escalation. The customer should know what happens next. For voice, test interruptions, failed transfers and callers who ask for a person early.
Agency teams should settle ownership with the client before implementation: who maintains policy, who approves access and who handles an incident after the delivery team leaves?
Test the awkward cases, then keep watching
Build a small acceptance pack before the prototype wins everyone over. Include ordinary requests alongside missing information, conflicting records, unavailable tools, requests outside policy and attempts to override instructions. Protect personal data used in testing.
For each case, record the expected answer or action, required approval and escalation condition. Inspect the whole run, including tool calls and resulting system changes. Agree which failures block release, then rerun the pack whenever prompts, policies, tools or models change.
If an agency proposes OpenAI’s legacy Evals platform for a custom build, check the schedule: existing evals become read-only on 31 October 2026, and its dashboard and API are scheduled to close on 30 November 2026. The official deprecation notice matters when choosing test infrastructure. Keep cases and acceptance criteria portable.
Production needs an owner too. NIST’s work on deployed AI monitoring highlights the gap between controlled tests and real operating conditions. Track correct completion, rework, failed actions and handoff quality. Assign someone to review failures and give them a clear route to pause automation.
Choose the delivery route after scoping
Presence is worth exploring when your enterprise workflow fits a managed deployment. For custom applications, OpenAI’s agent documentation distinguishes the Agents API for a managed Codex runtime, the Agents SDK for an agent loop in your application, and the Responses API for direct model integration. The choice depends on execution, state and integration requirements.
Before requesting proposals, assemble the workflow map, permission boundaries, handoff agreement, test cases and operating owner. These give suppliers something concrete to estimate and give you something concrete to accept.
Greg can help turn that preparation into a practical scope and a build, buy or wait decision. Bring one workflow you are considering to a workflow-readiness conversation with Greg.
Related on GrN.dk
- A Voice Agent Is Only Ready When the Human Handoff Works
- Who Can Read That Answer? Permissions for Internal AI Search
- Before an OpenAI Agent Touches Your CRM, Map the Boring Boundaries
Need help with this kind of work?
Assess your agent workflow with Greg Get in touch with Greg.
