OpenAI Presence Arrived—But Is Your Workflow Ready for an Agent?

By Greg Nowak. Last updated 2026-07-22.

OpenAI Presence comes with a straightforward proposition: help enterprises move voice and chat agents out of the demo environment and into production. For most businesses, though, the immediate question is not whether an agent can do useful work. It is whether a particular workflow is ready to give one access, authority, and responsibility.

That is a much harder test. A chatbot answers a question. An agent might retrieve company data, interpret a policy, update a system, contact a customer, or start another process. Once software can act, every weak point in the workflow becomes a product risk: unclear ownership, inconsistent records, permissions that are too broad, undocumented exceptions, or a crucial handoff that only an experienced employee knows how to manage.

Presence puts the workflow before the agent

OpenAI describes Presence as a managed product for deploying voice and chat agents across customer-facing and internal workflows. Each deployment starts with a defined job. The agent is given the knowledge and system access needed for that assignment, while the organisation decides what it may do, which actions need approval, and when a person must take over.

That is a practical definition of production readiness. The model is only one part of the service. Policies, approved actions, system connections, guardrails, simulations, evaluations, escalation rules, and controlled improvements must work as a whole. Presence is currently offered through a limited general-availability programme for eligible enterprise customers. OpenAI engineers and selected systems integrators lead deployments; it is not a self-service product.

Microsoft’s Work IQ APIs approach the same problem from within Microsoft 365. They are designed to give agents business context from organisational data and applications, along with tools for taking action and controls that keep those actions auditable. Microsoft also points to an easily overlooked operational issue: an agent uses software differently from an employee. It can carry out multi-step work more continuously and systematically.

Anthropic’s guidance for financial-services workflows follows a similar line. Start with a representative process, using the documents, data, and tools that the real work requires. Give the agent a specific role, connect only the necessary resources, and decide in advance where responsibility returns to a person.

The vendors differ in product and approach, but the operational lesson is consistent: choose and design the process before choosing the model.

A useful test for workflow readiness

A first project needs to be narrow enough to inspect properly and valuable enough to warrant integration, testing, and oversight. “Help with customer service” is not a workable scope. “Resolve a defined category of billing enquiries using approved account data and documented escalation rules” is much closer.

Evidence to gather before an agent is trusted with a workflow
Readiness area	A good sign	A warning sign	What to document
Job and outcome	One recognisable task has a measurable result	The scope spans several teams and loosely related needs	Start and end conditions, owner, and success criteria
Process and exceptions	The normal route and common variations can be explained	Correct handling relies on undocumented judgement	A workflow map with exception routes
Systems and data	Required records have known sources and owners	Employees routinely reconcile conflicting information by hand	A data inventory and system-access map
Authority	Allowed actions and approval thresholds are explicit	The agent needs broad access “just in case”	A permission matrix and approved-action list
Human handoff	A person receives the case with enough context to continue	Escalation means starting the interaction again	Handoff triggers, destination, and context package
Evaluation	Representative cases have expected outcomes	Quality is judged by whether the demo looks convincing	A test set covering normal, unusual, and higher-risk cases
Monitoring	Someone owns production signals and subsequent changes	Launch is treated as the end of the project	Metrics, alerts, review rhythm, and change controls

Readiness should be demonstrated with operational evidence, not a row of unchecked assumptions.

Map the job people actually do

A readiness review should follow the work from the event that starts it to the final recorded outcome. Where does the information arrive? Which systems does an employee consult? What decisions are made, what actions follow, and how does the business know the job is complete?

The awkward cases often tell you more than the standard route. A record is missing. Two systems disagree. A customer makes an unusual request. The policy is ambiguous, a tool is unavailable, or the requested action exceeds the agent’s authority. These situations determine whether the agent may continue, should ask for clarification, must wait for approval, or needs to transfer responsibility.

The resulting process description should be concrete enough to build from. For each important step, it should name the context required, the tool available, the policy that applies, the action permitted, the output expected, and the fallback route. With that in hand, a client can compare a managed product with a custom API-backed implementation on the requirements of the job rather than on a polished demonstration.

Give the agent the access its job requires

Presence starts with the knowledge and system access required for a specific assignment. The principle holds regardless of vendor: permissions should come from the approved workflow, not accumulate as developers encounter new obstacles.

Reading and acting should be treated separately. An agent might retrieve an account status but need approval before changing it. It could prepare a response while a person remains responsible for sending it. Actions with greater consequences may call for tighter thresholds, stronger verification, or mandatory escalation.

Microsoft’s focus on tenant controls, auditable actions, and workspaces for intermediate state shows why the surrounding architecture matters. During multi-step work, the agent needs a controlled place to hold context and progress. The organisation must also be able to establish which identity acted, what information informed the decision, what changed, and whether the action stayed within policy.

Use the prototype to test what might fail

A small API-backed prototype earns its keep by testing the uncertain parts of the workflow. Can it retrieve the necessary records reliably? Can access be kept within the intended boundaries? Does a human receive enough context when the case is handed over? Can an action be stopped or reversed? What happens when a tool is unavailable or two sources conflict?

Evaluation should use representative inputs from the real process, with appropriate handling of sensitive information. Include routine cases, important variations, ambiguous requests, edge cases, and higher-risk scenarios. Answer quality is only part of the assessment. The agent must also select the right tool, follow policy, seek approval at the right point, take the correct action, and escalate in time.

This work turns the vendor decision into something more concrete. Presence may fit an eligible enterprise that wants a supported production route for an applicable voice or chat workflow. A custom OpenAI API implementation may provide more control when the job, channels, integrations, or delivery model demand it. Sometimes the honest conclusion is that the workflow is not ready until its data, rules, or ownership improve.

Monitoring belongs in the operating model

NIST explains why testing before launch cannot settle the matter. Controlled evaluations cannot fully reproduce changing real-world conditions. Once deployed, an AI system needs monitoring to confirm that it remains reliable and to detect unforeseen outputs or consequences. NIST also notes that monitoring practices and terminology are still developing, so a generic dashboard is not an operating model by itself.

The useful signals are the ones connected to decisions. Are success or escalation rates changing? Are unfamiliar request types appearing? Are tool failures becoming more frequent? Has a policy or product change made part of the evaluation set obsolete? Production sessions and escalations will reveal gaps, but only if someone reviews them and has the authority to decide what happens next.

Changes deserve the same discipline as the first release. Investigate the signal, propose an adjustment, test it against representative cases, obtain the necessary approval, release it in a controlled way, and check the result. Uncontrolled adaptation is not a sign of operational maturity.

Make readiness the first deliverable

A vendor-neutral readiness engagement gives a client something more useful than an early commitment to buy or build. Greg can map the process and its exceptions, identify the systems and data involved, define permissions and human handoffs, build a focused API-backed prototype, create evaluation cases, and set out a production-monitoring plan.

The outcome is evidence for a decision: use a managed agent product, commission a custom implementation, improve the process first, or hold off. That keeps the technology choice tied to operational value and gives any later build a much firmer base.