Key Takeaways
- OpenAI Presence is a deployment, not a signup. OpenAI announced it on July 22, 2026 as a product for eligible enterprise customers, delivered through a limited general availability program led by OpenAI Forward Deployed Engineers and select global systems integrators. OpenAI states it is not yet available as a self-serve product.
- It is built around one job at a time. Each Presence deployment starts with a specific workflow such as resolving billing issues, supporting insurance claims, or handling employee IT service requests, and the agent gets only the knowledge and system access that job needs.
- Viktor is the other shape of the same idea. You add him to your Slack or Microsoft Teams workspace, @mention him, and he does work across your existing tools with no deployment project in front of it.
- Presence wins on high-volume customer conversations. Real-time voice, simulations and graders, guardrails, and a Codex-powered improvement loop are a serious answer to a support queue that never stops. Viktor has no voice channel.
- Viktor wins on the wide, changing internal work. The Monday revenue pull, the client onboarding handoff, the ad account check, the deck nobody wants to build. Different job every day, same teammate, 3,200+ integrations behind him.
- The deciding question is not which is smarter. It is whether the work is one repeatable conversation at scale or fifty different requests a week from a team of ten.
Presence and Viktor use almost the same vocabulary on their product pages: agent, policies, approved actions, escalate to a person. That overlap is why the comparison keeps coming up, and it is misleading. One is a deployed system that OpenAI's engineers build with you for a specific customer-facing job. The other is a teammate you add to a channel this afternoon. Picking the wrong shape costs a quarter, so here is the split without the marketing.
What is OpenAI Presence?
OpenAI Presence is an enterprise product for putting AI agents to work across customer and internal workflows, announced on OpenAI's site on July 22, 2026. Per that announcement, Presence agents answer questions, resolve issues, use company systems, take approved actions, and escalate to people when needed, with the company setting what the agent can do and when a human takes over.
The parts OpenAI lists in the product are worth reading closely, because they tell you who it is for:
- Policies and standard operating procedures
- Guardrails and approved actions
- Simulations and evaluation tools
- A Codex-powered improvement process that investigates production signals and proposes updates teams test and approve
Availability matters as much as capability here. OpenAI says Presence is available to eligible enterprise customers through a limited general availability program, that deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators, and that it is not yet self-serve. Today it covers real-time voice and chat: customer support, outbound sales, and higher-risk internal workflows.
OpenAI also runs it on itself. According to the same announcement, Presence powers OpenAI's English-language phone support line and now resolves 75% of inbound issues without human assistance, and its Codex-powered improvement loop cut human handoffs by 15 percentage points in 10 days. BBVA, SoftBank, and IAG are named as enterprises exploring or testing it for voice banking in Mexico, Japanese-language conversations, and support during high-demand events.
Read that list again and notice what all of it points at: a queue of similar conversations, in volume, where a wrong answer is expensive.
What is Viktor?
Viktor is an AI employee that lives in your Slack workspace or Microsoft Teams. There is no console to open and no deployment to schedule. You add him, @mention him in a channel, and he goes and does the thing across the tools your team already pays for.
@Viktor pull last week's Stripe revenue, compare it to the four weeks before,
and post the numbers with anything that looks off in #financeHe reads the request, pulls from Stripe, does the comparison in his own sandbox, and replies in the thread where the question was asked. Next request that day might be a Meta Ads check, a rewrite of an investor update, or a spreadsheet of every closed-won deal with no onboarding kickoff.
That is the real difference. Presence is engineered to do one job extremely well for a long time. Viktor is hired to do whatever this week needs, review-first by default, so a person approves before anything leaves the building.

Viktor vs OpenAI Presence: the comparison that matters
| Workflow | OpenAI Presence | Viktor |
| Answer 4,000 inbound support calls a week in two languages | Built for it: real-time voice, guardrails, escalation rules | No voice channel |
| Verify a caller, look up their account, apply refund policy, take the approved action | Core use case, tested with simulations and graders before launch | Can draft the response and update the record, but not on a live call |
| Pull Monday revenue from Stripe and post it in a channel with commentary | Not the shape of the product | @mention in the channel, output lands in the thread |
| Turn a signed contract into onboarding tasks in Linear, Notion, and Gmail | Would need to be scoped as a deployment | Ask once, then set it as a recurring job |
| Check yesterday's Google Ads and Meta Ads spend and flag what broke | Not the shape of the product | Reads both accounts, replies with the numbers |
| Build a dashboard your ops lead can open in a browser | Not the shape of the product | Ships it as an app with a live URL |
| Start today without a project plan | Deployment led by OpenAI FDEs and integrators, limited GA, not self-serve | Add to the workspace and message him |
| Prove policy compliance on high-risk conversations before go-live | Simulations, graders, guardrails, controlled rollouts | Review-first approvals, and you read the draft |
Every row in that table is a capability statement, and I would rather be blunt about the ones that go against us than sell you something that does not fit.
Where Presence genuinely beats Viktor
Three places, and none of them are close.
Live voice. Viktor does not answer phones. If your problem is 4,000 calls a week and average handle time, Presence is designed for exactly that and Viktor is not in the conversation.
One workflow at industrial scale. When the same interaction repeats thousands of times, the value moves from "can it do this" to "does it do this the same way every time under policy". Simulations, graders, and a proposal loop that investigates production escalations are the correct machinery for that, and OpenAI built it because they ran their own support line on it.
Deployment help as part of the product. For a regulated enterprise with a security committee and a set of legacy systems nobody wants to touch, forward deployed engineers who connect the systems and write the evaluations with you are a real advantage. That is a service, and services are hard to replace with a signup flow.
If your first AI project is a customer-facing queue with a compliance exposure, take the enterprise path. Nothing in this post argues otherwise.
Where Viktor is the better answer
Now the other side, because most of the teams I talk to do not have a 4,000-call queue. They have twelve people, forty tools, and a hundred small jobs a week that nobody has time for.
For that shape, the deployment model works against you. Scoping a workflow, connecting the systems, writing the evaluations, and running a controlled rollout is the right amount of ceremony for a bank's refund policy and far too much for "someone please keep the CRM clean". By the time the project is scoped, your team has changed what it needs.
Viktor takes the opposite bet: no scoping phase, because the interface is a message. Three things follow from that.
He works where the work already is. The request happens in the channel where your team is already arguing about it, and the answer lands in the same thread, in front of everyone who needs it. We wrote about why that matters in why your AI employee should live where you work.
He is wide instead of deep. 3,200+ integrations with real read and write access means the answer to "can he touch our billing tool" is usually yes without a scoping call. If it is not on the list, there is a path for that too.
He is reviewable by the person who asked. Review-first is not a governance layer bolted on top, it is the default: he drafts, you approve, then he acts. For a ten-person company that has no evaluation team, the human reading the draft is the evaluation, and that is a workable answer at that size. Our guide to keeping a human in the loop covers how teams tune that as trust grows.

How to decide in one afternoon
Skip the feature grids. Answer four questions about the work, not about the vendors.
- Is the work one conversation repeated, or many different requests? One conversation at volume points to Presence. Many different requests point to an AI employee.
- Is a customer on the other end, or your own team? Customer-facing and regulated pushes you toward a deployed, evaluated agent. Internal work rewards breadth and speed.
- Is voice required? If yes, that decides it.
- Who owns it after launch? If you have an ops or support engineering function that will own evaluations and rollouts, you can run a deployment. If the owner is your chief of staff between two other jobs, pick the thing that needs no owner beyond the person asking.
A useful test for question one: write down the five tasks you would hand over first. If they are five variations of the same task, you want a deployed agent. If they touch five different tools and three different departments, you want a teammate. Our list of the first five workflows to automate is a decent starting point if the page stays blank.
And these are not mutually exclusive. A company can run an engineered voice agent on its support line and still have an AI employee in Slack doing the reporting, onboarding, and research work behind it. The mistake is not picking the wrong one, it is assuming one product covers both jobs.
What this launch tells you about the market
Presence is evidence for something we have been saying for a year: the interesting question stopped being model quality. OpenAI's own framing says the challenge is no longer proving agents can work, it is making them reliable in production. Everybody now agrees the constraint is operational, not intellectual.
Where the industry splits is on how you get reliability. One path is engineering it upfront: scope the job, write the policies, simulate, grade, roll out under control. The other path is putting the work in front of a human every time, in the place they already work, so approval is a normal part of the day rather than a review board.
Both paths are legitimate. The first buys you consistency at volume. The second buys you coverage across work that changes weekly. Pick the one that matches how your company actually breaks.
Frequently Asked Questions
Is OpenAI Presence available to any company?
No. OpenAI states that Presence is available to eligible enterprise customers through a limited general availability program, with deployments led by OpenAI Forward Deployed Engineers and select global systems integrators, and that it is not yet available as a self-serve product. Viktor is self-serve: you add him to a Slack or Microsoft Teams workspace and start without a credit card.
Can Viktor handle customer support?
He can draft replies, look up account context across your tools, update records, and escalate a thread to a human, all inside Slack or Teams. What he does not do is answer live phone calls or sit in a real-time voice channel. If your support model is voice-first and high volume, an engineered voice agent is the better fit.
Does Viktor run on OpenAI models?
Viktor runs on frontier models from multiple providers and upgrades as new ones ship, so the model is not the thing you are choosing. What you are choosing is the surface the work happens on and how much setup stands between you and the first useful output.
What about security and access control?
Viktor is hosted by default, maintains SOC 2 Type I, and access is scoped per connected tool so he only reaches what you connect him to. If a security review is coming, our walkthrough of security due diligence on an AI employee lists the documents and questions to expect.
Could we use both?
Yes, and for larger companies that is the likely end state: a deployed agent on the customer-facing queue, an AI employee in the internal channels. They solve different problems and do not compete for the same work.
How long until Viktor produces something useful?
Same day, usually within the first hour. You connect two or three tools, ask for something you would otherwise do manually, and read the draft he comes back with. Start with three integrations rather than thirty.
Does an AI employee need an owner inside the company?
Someone should be the person who corrects him and decides what he owns next, but that is a habit rather than a role. It usually takes minutes a week, not a headcount. We wrote about who should manage your AI employee if you want the practical version.