What do you need to configure before deploying an AI agent?

Not a model — a set of decisions written down. Before an agent can safely run real work you have to give it: the policies that govern what it may do, the specific actions it is approved to take (issue a refund, apply a credit, cancel an order), the threshold at which it has to stop and get human approval, the rule for when it hands off to a person, the knowledge sources it is allowed to answer from, and scoped permissions to each system it touches. OpenAI's Presence platform, launched 22 July 2026, asks for exactly this list. Every item is a document, and most organizations have never written any of them down. The configuration is the product. The model is the easy part.

Why isn't OpenAI Presence a self-serve product?

Because the work it requires can't be self-served. Presence deploys through OpenAI's Forward Deployed Engineers and select systems integrators who sit with the customer to map workflows before anything ships. If the hard part were the model, you could sign up and paste in a prompt. The hard part is process archaeology — reconstructing how the work actually gets done from people who do it by habit, and turning that into policies, approved actions, and escalation rules a machine can follow. That is a consulting engagement, not a checkout flow. A product that has to send engineers to your office is telling you where the difficulty lives.

What is a misconfigured AI agent, and how often do they cause problems?

A misconfigured agent is one whose permissions, actions, or boundaries were set wrong — it can touch something it shouldn't, take an action nobody approved, or act with no defined limit. DigiCert's July 2026 research, based on a Propeller Insights survey of 1,001 IT and security decision-makers in the US, UK and Australia, found that half of enterprises had a security incident tied directly to an unauthorized or misconfigured AI agent in the past six months. Configuration is where agents fail — not model quality. And configuration is only as good as the written process behind it.

Is deploying an AI agent a data-quality problem or a process problem?

Both, but they are different failures and they are fixed in different places. A data-quality failure is when the record is wrong — a stale catalog says an item is in stock when it isn't, and the agent confidently sells air. A process failure is when the record is perfectly correct but nobody ever wrote down the rule for what to do with it: the account is genuinely 90 days past due, and whether the agent should offer a payment plan, escalate, or hold depends on an unwritten norm that lives in one supervisor's head. Clean data does not save you from an undefined decision. You have to fix both, and the process one is usually the one nobody owns.

Can a vendor or systems integrator write our SOPs for us?

They can write the document. They can't decide what goes in it. An integrator can interview your staff, watch the work, and draft a clean set of procedures and escalation rules — that's genuinely useful and it's most of what Forward Deployed Engineers do. But the judgment calls the SOP encodes are yours: when to comp the shipping, when to refuse the refund, which exception is worth a human's time. If that knowledge only exists as habit, someone inside the company has to make it explicit and keep owning it after the consultants leave. Otherwise you've paid to document a process that will drift the moment it changes and nothing fails loud when it does.

Where do you start if you want to deploy an AI agent this year?

Not with a model evaluation. Start by writing down one workflow end to end — including the exceptions. Pick a real task, follow it through every branch, and capture the decisions people make without thinking: what triggers an escalation, what the approval threshold actually is, which action is off-limits and why. The parts that are hard to write are the parts the agent will get wrong. Once the process is legible on paper, configuring the agent is fast. Trying to configure it before that is how you ship a misconfigured one.

Deploying an AI agent means writing down the work nobody documented

OpenAI shipped a product on 22 July that quietly reframes what it takes to deploy an AI agent into real operations. It’s called Presence, and the interesting part isn’t what it does — voice and chat agents for support, billing, the usual list. It’s what it asks you for before it will run. Not a model. Not a clever prompt. It asks for your policies, the actions the agent is approved to take, the rules for when it escalates to a person, and scoped permissions into your systems. Read that list again. Every item on it is a document. Most companies have never written any of them down.

TL;DR: To deploy an AI agent for real work you don’t hand it a better model — you hand it your policies, approved actions, escalation rules, and scoped permissions. That’s a request for documentation most organizations never produced. Presence ships through Forward Deployed Engineers rather than self-serve because the work is process archaeology: writing down decisions that currently live only in someone’s head. DigiCert found half of enterprises already had a security incident tied to a misconfigured agent. The agent isn’t waiting on a smarter model. It’s waiting on a process nobody wrote.

The product surface is a filing cabinet you never filled

Look at what Presence makes you supply. Organizational policies and operational guardrails. The specific actions the agent is allowed to execute. Knowledge bases and system access it’s permitted to use. Scoped API credentials. Handoff and escalation protocols. Then it runs the configured agent through simulations — common requests, edge cases, higher-risk scenarios — with automated graders scoring whether it followed policy and escalated when it should have.

That is a well-designed product. It’s also a mirror. Point it at a typical enterprise and the reflection is mostly empty fields. The company knows, loosely, what its support team does. It does not have a written policy for when a refund needs a manager, because the answer is “ask whoever’s on shift.” It does not have an approved-actions list, because nobody ever had to enumerate what a human agent may and may not do — a human just knows. It does not have escalation rules, because escalation is a thing people feel their way into after six months on the floor.

None of that is a knock on the company. It’s how work actually runs. The knowledge that keeps a support desk functioning lives in the desk, distributed across the people sitting at it. It was never a document because it never had to be. An AI agent is the first coworker who can’t absorb it by osmosis. Tribal knowledge has no schema.

What the agent needs versus where it actually lives

The gap is specific, and you can lay it out field by field.

What the agent has to be told	Where it lives in most companies today
Which actions it may take (refund, credit, cancel, reschedule)	Unwritten — “use judgment, escalate if unsure”
The threshold that triggers human approval	In one manager’s head; changes with who’s on shift
When to stop and hand off to a person	Learned on the floor, never recorded
What each account or ticket status actually means	Split across systems that define it differently
Which knowledge it’s approved to answer from	Scattered across wikis, PDFs, and Slack threads
What it may and may not touch (scoped access)	Never scoped — it borrows a human’s login

Every row on the right is a decision that gets made correctly hundreds of times a day by people who couldn’t tell you the rule they’re following. That’s fine when the actor is a person. It’s a production incident when the actor is an agent running unattended, because the agent will do something on the missing rule — it just won’t do what you would have.

Misconfiguration is already the failure mode

This isn’t a forecast. It’s happening now, and the data names the cause.

DigiCert’s July 2026 research — a Propeller Insights survey of 1,001 IT and security decision-makers across the US, UK and Australia, fielded in May — found that 78% of organizations had hit an AI-related security incident or vulnerability, and that half had one tied directly to an unauthorized or misconfigured AI agent in the past six months. Same survey: 75% of these organizations had deployed four or more AI systems in that window, 90% had discussed AI governance at the leadership level, and only half had an actual governance program in place.

Sit with the word misconfigured. Not “the model hallucinated.” Not “the model wasn’t capable enough.” The agent did something it shouldn’t have because its boundaries were set wrong — or never set. Configuration is where agents break. And configuration is downstream of a written process. You cannot scope an agent’s permissions correctly if no one has decided what it’s supposed to be able to do. You cannot set an approval threshold that exists only as a shrug.

Presence’s whole design — simulate against edge cases, grade for policy adherence and escalation appropriateness — is an attempt to catch the misconfiguration before it ships. Useful. But a grader can only check the agent against the policy you gave it. If the policy is thin because the underlying process was never documented, the agent passes the test and fails the job.

Why it can’t be self-serve

The tell is in the go-to-market. Presence is not a sign-up-and-go product. It rolls out through OpenAI’s Forward Deployed Engineers and a set of chosen systems integrators who work alongside the customer to identify workflows and manage the rollout. Every major AI platform stood up an arm like this over the past year — the services layer is the industry conceding where the real work is.

If the hard part were the model, deployment would look like every other API: read the docs, paste a key, go. Instead it looks like a consulting engagement, because the actual task is reconstructing how the work gets done and writing it down in a form a machine can execute. That’s process archaeology. You interview the person who’s been doing refunds for nine years and try to extract the rule from behavior that’s become instinct. Half the time they’ll tell you “it depends,” and then you have to sit with them until it depends turns into a decision tree.

A vendor’s engineer can run that excavation. What they can’t do is make the judgment calls for you — whether a chargeback already in dispute is ever refundable, which exception is worth pulling a human off the queue. Those answers are the business. If they only exist as habit, someone inside the company has to make them explicit and keep owning them after the integrator’s invoice clears. Otherwise the documentation drifts the first time the policy changes, and nothing fails loud when it does — the agent just keeps confidently applying last quarter’s rule.

This is not the data-quality problem

Separate this from the failure it gets confused with. A data-quality failure is when the record is wrong: the catalog says in stock when the shelf is empty, and the agent turns a stale field into a promise it can’t keep. Real problem, different problem.

The process failure is quieter, because the data is fine. The account is genuinely ninety days past due — the number is correct, fresh, agreed across systems. The question the agent can’t answer is what to do about it, and that question has no home. Offer a payment plan? Escalate to collections? Hold, because this customer is on a hardship arrangement flagged in a spreadsheet the agent can’t see and no one thought to mention? A human on the desk knows the answer from three years of context. The agent has a correct number and no rule. Clean data doesn’t save you from an undefined decision.

The operator read

The instinct when a platform like Presence lands is to run a model bake-off. Wrong first move. The first move is to pick one workflow and write it down end to end, exceptions included. Follow a real task through every branch. Capture the decisions people make without noticing they’re deciding: what actually triggers an escalation, what the approval threshold really is as opposed to the one in the handbook, which action is off the table and why. Name the person who owns that written process when it changes — the document is worthless if it silently goes stale.

The parts that are hard to write are not incidental. They’re the exact parts the agent will get wrong, because they’re the parts that were never legible to anyone but the person doing them. Once the process is on paper, configuring the agent is genuinely fast — that’s the part OpenAI, or an integrator, or your own team can do in an afternoon.

Most companies are going to skip this and go straight to deployment, and most agent failures trace back to the step they skipped. The model was ready. The process was never written.