On July 22, 2026, OpenAI launched OpenAI Presence, a product targeting enterprise voice and chat agents. It doesn’t stop at the general-purpose Q&A chat mode — it starts directly from specific roles, such as customer service, outbound sales, or high-risk internal workflows. When deploying, enterprises need to explicitly define which operations the agent can perform, which high-risk actions must be pre-approved, and when to trigger a human handoff.
In a concrete customer service scenario, a user submits a refund request that involves rare coupon stacking logic. The agent reads the order and discount rules but fails to calculate the correct amount. The task gets stuck, and the ticket is automatically handed off to a human agent. In a traditional tool flow, the human agent issues the refund, the transaction is marked as completed in the CRM, and that’s where the story ends.
What Presence tries to absorb into the product is precisely the second half of the work — the part that happens after failure. When a ticket is handed off to a human, the system automatically saves a failure record with the full execution context. The team can then reproduce this anomaly in a simulation environment, patch the rules for handling multiple discounts, run regression tests against historical test sets for verification, and use Codex to modify code and distribution logic — ensuring that the next time the same refund request comes in, the agent can handle it independently.
Making an agent smarter through post-launch fixes and testing is packaged here as a product feature independent of model capability. The object of system improvement is no longer confined to the parameters of a single LLM model — it directly covers the complete agentic system, including rules, test sets, code, and human judgment. This closed loop of converting field failures into system tests and rules is, in effect, putting the most valuable part of traditional FDE on-site experience feedback into the product workflow.
In traditional IT and consulting services, the real value of on-site FDE lies in channeling the errors, business rules, and effective practices exposed at the customer site back into the product and engineering system. Presence essentially establishes an FDE experience feedback chain within the standard product interface: capture field failures, record human handoff traces, distill them into test cases and rules, and perform controlled updates to code and logic.
From an enterprise architecture perspective, this is precisely the commercial practice of context infrastructure within workflows. The agent’s improvement does not depend on retraining or waiting for a more powerful model upgrade — it primarily relies on the system continuously capturing, distilling, loading on demand, and reusing past experiences that have already been paid for. Experiences are captured during execution, refined by human correction into tests and guardrails, and then fed back into the agentic system as context.
When a refund occurs, the enterprise is left with two things. One is the traditional business record, stored in the CRM or ticketing system. In that refund ticket, the CRM holds the order number, customer identity, payment amount, and whether the refund was completed. It records what happened this time — the ledger of business operations. The other is the improvement experience accumulated while the agent was running the task: failure records, human intervention traces, modified rules, regression test cases, and adjusted distribution logic. It is precisely this body of experience about “how to avoid the same mistake next time” that determines whether the system can correctly process an exception the next time it encounters one.
Viewing these failure records and rules as critical assets stems from a structural analysis of the industry — it does not imply that they have been hosted or restricted by OpenAI. Public information shows that Presence simply integrates simulation, regression testing, human handoff, and the Codex improvement process into the product workflow. The Register’s report notes that Presence is currently in limited GA, adopting a non-self-serve model, deployed on a case-by-case basis by specialized teams, with specific costs and implementation plans customized based on scenarios and delivery requirements. OpenAI has not publicly disclosed hosting specifics, data residency policies, retention periods for these rules, regression tests, or failure records, nor whether cross-vendor export and migration are supported.
When the improvement loop is built into the product, a concern naturally arises in the industry: will platform vendors turning experience feedback into a standard feature squeeze out vertical software vendors the way it has before?
In software history, cloud vendors or platform giants replacing vertical software has typically relied on default distribution entry points, a position close to data and workloads, and standardized delivery with low-cost replication. As demonstrated in the AWS Redshift paper, cloud vendors can combine managed services, data proximity, and cost advantages into a complete substitution offering.
Looking at Presence through these lenses, it doesn’t yet fit those conditions. Presence is still at limited GA — it is not an out-of-the-box self-serve product. The Register’s report shows that every deployment requires heavy involvement from FDE engineering teams or partners. It still needs to connect to the enterprise’s existing CRM and other external systems — it has neither captured the default procurement entry point nor achieved centralized data hosting.
Looking back at competition between infrastructure and the application layer, stronger underlying capabilities do not mean vertical vendors lose their space overnight. AWS launched OpenSearch but didn’t stop Elastic from continuing to grow in FY2026; after OpenAI released Deep Research, the finance-focused AlphaSense still announced in October 2025 that its ARR surpassed $500M, serving over 6,500 customers — though this is vendor-reported data, it still reflects the resilience of deep business workflows and proprietary content. Conversely, platform extensions launched by general-purpose providers don’t always naturally cover the market — for example, when the OpenAI GPT Store promised revenue sharing for developers, WIRED’s reporting showed that most developers failed to build a sustainable business model through it.
As long as vertical applications hold onto cross-cloud product interfaces, proprietary data accumulation, and deep business workflows, upgrades to general-purpose models do not automatically equal the demise of vertical software. Since the business records in CRM remain in the enterprise’s own hands, when FDE’s experience feedback is absorbed into the product, what should mature vertical agent vendors and enterprise buyers really focus on protecting?
Looking at mature vertical agent vendors, their defensive focus is not on locking into a single model. For instance, Sierra states on its tech blog that its agent calls upon over 15 frontier models, open-source models, and proprietary models depending on the task; Decagon publicly confirms that it simultaneously interfaces with OpenAI and Anthropic models, and connects to CRM, help desk, and CPaaS communication infrastructure; Intercom Fin executes actions by connecting to Shopify, Stripe, Salesforce, and other systems, while operating across chat, email, voice, SMS, WhatsApp, and other channels. Additionally, ServiceNow AI Control Tower emphasizes horizontal governance of any agent, model, and workflow, whereas Presence is positioned to run agents in specific roles — a clear distinction in governance levels.
Looking back at that refund ticket, enterprises control three things in actual operations: first, the ledger of orders and customer states recorded in CRM; second, the communication and execution channels covering phone, email, and WhatsApp; third, the failure records, human handoff traces, regression test sets, and rules accumulated after processing thousands of tickets — this is precisely the enterprise’s core context infrastructure.
What truly determines the agent’s next behavior is these production improvement materials. If the enterprise can take these mistake lessons and test sets to different models to retest and migrate, then regardless of which underlying model changes, the purchasing power remains with the enterprise. Conversely, if these improvement experiences and test sets cannot be exported, the customer falls into a new form of vendor lock-in. The enterprise can carry away the business ledger in the CRM, but cannot take with it the mistake lessons paid for at great cost.
Whether accumulated tests and rules can be exported directly determines whether customers can freely switch vendors in the future. More importantly, teams can start now turning every human handoff into an explicit requirement for the next outcome.
The approach showcased by Presence doesn’t require waiting until a complete platform is procured to begin practicing. For builders, start by picking one task that recurs repeatedly and genuinely does go wrong — refunds, quotes, or customer information updates, for example. Each time a task is handed to a human, ask a question more important than “how to fix it this time”: once this type of task is handed to an agent, what outcome counts as correct? Whether the refund amount is right is only one part; whether it should have been handed off to a human, whether it touched an order it shouldn’t have, whether the user received a clear explanation — these should also be written into the answer.
This is the starting point of Evaluation-First. The input left by the human handoff, the actions taken by the agent, and the human corrections are not just failure logs. The team must select cases that will recur, and together with acceptance criteria, compile them into an evaluation set. After any change to rules, prompts, tool calls, or code, rerun this set of real cases first; if results don’t meet the bar, the change cannot be pushed back to production.
The point here is not to lock down every step of the agent. The paths of an open-ended task cannot be pre-written exhaustively; the agent still needs to look up information, choose tools, and adjust its strategy on its own. What the team truly needs to pin down is the boundary of the outcome: was the refund correctly completed, did high-risk actions stop, did the user receive proper handling. The shift from process certainty to result certainty is exactly about this transformation. The evaluation set turns the abstract notion of “the result must be right” into a set of cases that can be run repeatedly and that grow continuously with real failures.
This set of materials should be visible to the enterprise, modifiable, and portable. Models can be swapped, tools can be reconnected, and the people doing the implementation will leave; but as long as the team continuously turns human handoffs into new evaluation cases and acceptance criteria, the agent won’t keep paying the same tuition over and over. The value of Presence lies precisely in placing this path into the enterprise product — while the truly transferable capability still comes from whether the team can continuously define, verify, and accumulate the outcomes they want.