Developers keep adding AI agents to their apps. The CRM gets one. So does the design tool. Behind each assistant is a team choosing models, writing prompts and building a tool-calling loop. Then come memory, recovery and usage limits.
Why this approach is a problem
After all that work, the result can still be a mediocre agent with a narrow view of the user's problem. It knows one app. The user supplies the missing context and works around its mistakes.
Even a capable agent starts as an unfamiliar implementation. For example, I work closely with Codex. I know what to expect from it. I trust it. Given the choice, I would rather let Codex use an app's capabilities than learn to trust another built-in agent.
I suspect many users feel the same. An equally capable model does not give a new agent that accumulated trust. The user has to learn how this particular implementation behaves before relying on it.
A small agent can make sense for a small job. But multi-step planning means maintaining a general agent system alongside the product. The app needs to know who can issue a refund and whether it happened. Managing a model's conversation is a separate commitment.
Where the industry is converging
On September 10, OpenAI introduced its Agents API with a managed Codex harness. OpenAI handles sessions, orchestration, context compaction and recovery. The application supplies tools and chooses the execution environment.
Codex app-server lets a product embed the Codex agent with authentication, conversation history, approvals and streamed events already handled.
Product teams can reuse this machinery or expose their capabilities to an agent the customer already uses. Where providers support it, customers may also bring an existing subscription. I think products will increasingly own the capabilities and state while reusing the generic agent infrastructure.
Users can already reach product capabilities from general agents such as ChatGPT, Claude, Copilot and Codex. The question for developers is which parts the product must own regardless of where the intelligence comes from.
Four ways to connect intelligence to a product
These paths can coexist, but they create different experiences and bills.
| Connection | Where the agent runs | Who pays for the model |
|---|---|---|
| The app's built-in agent | Inside the app | The product team |
| Their own agent through MCP | In ChatGPT, Claude, Codex, or another client | The user, through that client |
| Their existing subscription | Inside the app | The user, where the provider supports it |
| Their API key | Inside the app | The user, through API usage |
API keys are a terrible welcome screen for ordinary users. Most people want to use the product before opening a developer account and learning token billing. A built-in agent gets them started immediately. But I doubt they want a different agent and AI bill for every app.
Bringing an agent and bringing a subscription are different. With MCP, users stay in their preferred agent and call the app's tools. With a subscription connection, an embedded harness runs inside the app using access they already pay for.
Subscription support is uneven. GitHub documents OAuth and multi-user flows for the Copilot SDK. Codex app-server supports ChatGPT sign-in. I would confirm commercial terms before building a general SaaS around consumer subscription access. The hosted Agents API uses API billing, not a ChatGPT subscription.
MCP exposes capabilities, not a complete agent
MCP gives AI clients a standard way to discover and call tools such as create_invoice, book_shipment and update_project. One implementation can serve several clients.
It does not choose the model or settle the inference bill. The app still needs permissions, durable jobs and an interface for reviewing changes. MCP supplies neither that interface nor the agent loop. The product enforces its business rules whichever supported client calls it. Connecting an agent does not transfer that responsibility.
One harness, several model paths
The model decides what to do next. The harness runs the steps between the model and the tools. I want to test one harness with several model-access paths:
Your application
|
One harness
|
+------------+------------+
| | |
App-paid model API key User subscriptionCodex app-server is one candidate. I also want to try Codex Router so another model can power the app without changing its capability code. This remains a prototype idea, not a setup I have validated for production. The router is a small community project. API compatibility does not guarantee equal tool use, approval handling or recovery.
One related prediction: I think model providers will eventually open-source their agent harnesses. Their value is in the model, not the loop around it. Keeping the harness proprietary just forces every developer to rebuild the same thing.
Codex app-server's remote WebSocket transport is experimental and unsupported for production workloads. The hosted Agents API removes more infrastructure work but ties the product to OpenAI's harness and API pricing.
Changing models may change how well the agent understands a request. Completing an approved action should still call the same product code.
The app still executes and records the action
Suppose an agent prepares a refund. The app checks the user's authority and the order's eligibility. It sends the refund to the payment provider and records the result.
The built-in agent and an external MCP client should call the same refund code with the same permissions. Both should receive the same recorded result. The payment outcome belongs to the order record rather than one conversation. Once approved, the request should contain enough information to finish without keeping the conversation open.
The interface still matters. Reviewing a ledger or editing a design through chat can be painful. Let the agent prepare the change. I still want to inspect and correct it in the app before approval.
The app must handle failed requests and spending limits
If the payment provider accepts a refund but the connection drops before confirmation, retrying could issue a second refund. The app needs to check whether the first request succeeded. An unconfirmed result should remain pending and be shown as unknown.
The approved request and its progress must survive a restart. A user should also be able to change agents without moving data or losing work.
If the user's AI subscription reaches its limit, switching to the company's API key changes who pays. The user should know whether the app will pause or continue under an agreed budget. A fallback needs an explicit billing rule. Each user's agent needs separate access to tools and data. Changing models must preserve those permissions and spending limits.
Developers can let users keep an agent they trust by exposing the actions their apps already perform. Executing those actions correctly remains the product's job.