AI agents need a maintenance loop, not a launch day

Business owners are about to make the same mistake with AI agents that they made with websites.

Pay for the launch. Ignore the operating model. Come back six months later wondering why the thing is wrong, stale, off-brand, unsafe, or quietly useless.

The wrapper changes. The mistake does not.

A website is never really finished when it goes live. It needs content, analytics, conversion checks, technical care, offer changes, pricing changes, product updates, search changes, user feedback and someone who gives a toss when the contact form breaks.

An AI agent is worse.

A website mostly sits there until someone edits it. An agent acts. It answers customers. It pulls from knowledge bases. It uses tools. It can escalate, update records, trigger workflows, apply policy and, if you are brave or careless enough, touch money.

So the question is not “can we launch an agent?”

Of course you can. Plenty of people can launch an agent now. The question is whether you can keep the thing true after launch.

That is why OpenAI’s Presence announcement is worth paying attention to.

Not because enterprise voice agents are surprising. They are not. Anyone watching this space knew customer support, sales calls and internal service desks would be near the front of the queue. Repetitive questions, existing scripts, existing systems, measurable handoffs. It is the obvious battleground.

The interesting bit is buried in the operating model.

OpenAI describes Presence as a product for deploying agents that can answer questions, resolve issues, use company systems, take approved actions and escalate to people when needed. Fine. But the useful part comes after the first deployment: production sessions and escalations show where the agent is working and where it is failing. Codex investigates those signals and suggests updates. Teams test each proposed change against the production version, then approve a controlled rollout.

That is the whole game.

The agent is not treated as a finished thing. It is treated as a live system with a maintenance loop.

That sounds boring until you have a customer on the phone asking about a refund policy that changed yesterday.

A demo agent can be impressive with clean examples. A deployed agent has to survive the usual business mess: vague policies, old documents, weird customer language, missing CRM fields, edge cases, internal exceptions, products that have been renamed three times and a spreadsheet nobody wants to admit is still the source of truth.

It also has to survive time.

A model can give the right answer on Monday and the wrong answer on Friday without the model changing at all. The business changed. The price changed. The legal wording changed. The offer changed. The escalation route changed. The system integration changed. Customers found a new phrase for the same problem. Somebody uploaded a newer PDF but did not remove the old one.

This is where most AI projects will quietly rot.

Not because the model is bad. Because nobody bought the work around the model.

Google’s enterprise agent language points in the same direction. Ignore the usual platform confetti and look at the nouns: agent identity, registry, gateway, simulation, evaluation, observability, optimizer, anomaly detection, governed connectors, inboxes for human input, long-running agents in sandboxes.

That is not prompt-engineering wallpaper. That is operations.

An agent with an identity can be audited. A registry says which tools are approved. A gateway controls access. Simulations test what could happen. Evaluations score what did happen. Observability lets someone inspect the run. An optimizer suggests fixes from actual failures. An inbox gives humans somewhere to approve, correct or stop the work.

You do not need Google’s stack to learn from the shape of it.

The market is telling us what production AI really needs: memory, permissions, testing, monitoring, review, rollback and ownership.

Anthropic’s Economic Index connector is a smaller example, but it matters for the same reason. It lets people ask Claude questions about AI and work, grounded in Anthropic’s own usage dataset, with the limitation made explicit: this reflects Claude usage, not the whole labour market.

That caveat is not a footnote. It is the point.

Useful AI systems need to know what they are grounded in and what they are not. If an agent cannot show the source, the date, the scope and the limitation, it should not be treated as a decision system. It is a talking interface with confidence issues.

The same pattern has been showing up in the vault all week.

The forward-deployed engineering note had the cleanest delivery ladder: audit, evals, deployment. First, find the real workflow, not the PowerPoint version. Then build a test set from real examples. Then deploy in stages: controlled environment, shadow mode, human approval, narrow write access, monitoring, rollback. Autonomy is earned, not granted because the demo went well.

The Perpetual Traffic CRO note made the risk concrete. AI can help gather price evidence and structure useful answer content. Good. But an agentic pricing system is a different animal. If it can adjust discounts, it is touching margin, stock, brand trust and potentially compliance. That needs floors, ceilings, holdout groups, approval thresholds, logs and a kill switch.

The USV object-agent note gave the architecture version: one worker per deal, company, person or idea, with triggers and a shared context layer. That is more believable than one giant assistant pretending to know the business. But it still needs cost caps, idempotent writes, clear source records and a reason to wake up. Otherwise it becomes a token bonfire with a nicer job title.

And the dentist model gives the human version. Machines do the preparation. Senior people diagnose, prescribe, review exceptions and own the decision.

That is the part a lot of AI agency pitches skip because it is less exciting than “AI employees”.

But it is more honest.

If an agent is doing useful work, someone has to own its behaviour. Someone has to review the escalations. Someone has to decide whether the failure was caused by missing data, bad retrieval, weak policy, a tool error or the model making a confident mess. Someone has to approve the fix. Someone has to know when to pause it.

This is not optional governance theatre. It is maintenance.

Business owners should change the questions they ask before buying an AI agent.

Do not just ask: can you build it?

Ask:

• Which job is the agent actually responsible for?
• What sources is it allowed to trust?
• What can it do without approval?
• What must it escalate?
• What examples will be used to test it before launch?
• What happens when a policy changes?
• Who reviews failed or escalated runs?
• How are fixes proposed, tested and approved?
• What can we roll back?
• What metric tells us it is genuinely working?

Those questions are not glamorous. Good. Glamour is usually where the invoice gets fluffy.

For agencies and AI consultants, this is the more serious commercial opportunity.

Do not sell the agent as a finished asset. Sell the managed operating layer that keeps it alive.

That might look like a deployment sprint first: one workflow, current baseline, operating map, source audit, eval set, permission map and shadow-mode plan.

Then a managed improvement retainer: review live runs, classify failures, update source material, maintain evals, tune prompts and tools, monitor costs, check escalations, test changes and produce a simple monthly evidence pack.

That sounds less sexy than “we build AI workers”.

Fine. It is also the thing a business can trust.

The businesses that win with agents will not be the ones that launch the most of them. They will be the ones that know which agents are allowed to do what, when they are drifting, what they cost, where they fail, who approves the fix and how to stop them before they turn a small mistake into a live-system problem.

A chatbot demo can have a launch day.

A working AI agent needs a maintenance loop.

That is where the real work starts.

---

Pull quotes

• A chatbot demo can be finished. A working AI agent cannot.
• The agent that works on Monday can be wrong by Friday without the model changing at all. The business changed.
• If nobody owns the maintenance loop, your AI agent is just another abandoned automation with a better voice.
• Do not sell the agent as a finished asset. Sell the managed operating layer that keeps it alive.
• Autonomy is earned, not granted because the demo went well.

Short LinkedIn / X version

Business owners are about to make the same mistake with AI agents that they made with websites.

Pay for the launch. Ignore the operating model. Come back later wondering why the thing is wrong, stale or useless.

OpenAI Presence is interesting because of the bit after launch: production sessions, escalations, quality signals, Codex-suggested updates, tests against the live version, and controlled rollout after approval.

That is what most AI projects are missing.

An agent starts ageing the minute it touches the business.

Policies change. Products change. Customers phrase things differently. Old documents stick around. Integrations move. Monday’s correct answer can become Friday’s liability.

So do not just ask: “can you build us an agent?”

Ask:

• what sources does it trust?
• what can it do without approval?
• what must it escalate?
• who reviews failed runs?
• how are fixes tested?
• what can we roll back?

A chatbot demo can have a launch day.

A working AI agent needs a maintenance loop.

That is where the real work starts.

Notes and caveats

• OpenAI’s Presence performance claims are OpenAI-reported, not independently audited here. The post says Presence now resolves 75% of inbound issues on OpenAI’s English-language phone support channel and reduced human handoffs by 15 percentage points in 10 days through its Codex-powered improvement loop. Treat those as vendor claims unless separately verified.
• Presence is limited general availability for eligible enterprise customers, led by OpenAI FDEs and select systems integrators. It is not a self-serve product.
• Google Cloud’s detailed agent-governance list comes mostly from Cloud Next ‘26 in April, not the last 48 hours. It is used as supporting market context because it matches the same production-agent pattern and was refreshed by the July 16 conversational AI post.
• Anthropic’s Economic Index connector reflects patterns in Claude usage, not the whole labour market. That limitation is useful and should be kept if Jason uses the example.
• The Perpetual Traffic price-agent examples are early/beta and not proof of lift. Do not present them as audited case studies.
• This draft deliberately avoids promising that agents reduce headcount or costs by default. The safer claim is that agents need an operating layer before they deserve write access.
• This piece overlaps with previous themes: deployment as the product, tripwires for long-running agents, permission maps, one boring loop. The fresh angle is the maintenance loop as the ongoing operating system, not pre-launch paperwork.