You Want Your Apps in AI, Not AI in Apps

Any feature pitch that begins, “What if we put a chat box here?” deserves suspicion.

That question has put a thin layer of AI over a lot of software. A user opens the product, finds the familiar screen, then sees an input beside the controls that already do the work. Ask it to summarize the dashboard. Ask it to create a record. Ask it to search the records you were about to filter. The product has acquired a second, less reliable way to operate itself.

The more useful direction often runs the other way. Put the useful part of your app in the AI. Let the conversation call the actions and bring the app in when the job needs it. Keep the system of record, the rules, and the interface for sustained work where they belong. Put the capability where the user’s work begins.

That is a product decision, not an SDK decision.

Where the Work Begins

The decision is where the job begins: inside the application or in a conversation. What the user knows at that moment matters.

Sometimes the job begins inside the app. A payroll manager is correcting a pay run. A designer is arranging a page. An accountant is reconciling a bank feed. The application has the working state, the specialist controls, and the visual feedback. An assistant inside that application can help explain an exception, draft a note, or find a setting. The app remains the right place to work because the work is already there.

Other jobs begin as a sentence in a conversation. “What did we promise this customer?” “Find a time when these people are free.” “Turn this research into a brief and create the follow-up work.” The surrounding context may include an email, a meeting, a document, a prior decision, and three systems that do not share a navigation bar.

Forcing that job to begin by opening your app asks the user to translate their intent into a destination before they can make progress. The better move is to let the app meet them in the conversation with one or two useful actions.

OpenAI’s Apps SDK is one current example of the shift. It connects an existing backend to chat logic and an interface inside ChatGPT, using MCP for external tools and data.¹ The conversation can become the place where a user assembles context and chooses the next action.

A Copilot Can Become a Detour

An embedded assistant is easy to justify because it is visible. It makes a screenshot. It gives the roadmap a friendly verb: summarize, write, analyze, ask.

Visibility is not evidence that it owns a job.

Take a customer-support product. An AI panel that summarizes the ticket on the page may save a few seconds. A support manager planning the day can have a different problem. They have a backlog, an account manager’s note, a product incident, and a request to move the risky cases first. That work does not start on one ticket. It starts as an instruction with context spread across the company.

The product should be available to that instruction. A narrow action that finds the relevant cases, explains its filter, and creates an assignment can be useful there. The app still owns the queue, permissions, assignments, and audit trail. It has simply stopped making the user arrive through its home page.

The same distinction applies to expense tools, CRMs, calendars, analytics products, and internal systems. A chat box inside each one asks the user to enter the right building before they can tell the assistant what they need. A well-designed integration lets the assistant bring the right building into the job.

Expose Work, Not Your Database

An integration goes wrong when it exposes table-shaped operations without a complete job behind them: list contacts, get contact, update contact, list deals, get deal, update deal. The model receives an API brochure and the user receives a new source of accidental bulk edits.

Tool design starts with a complete piece of work. “Prepare the renewal brief for Acme” can gather the account record, open support issues, usage change, and contract date under a clear read boundary. “Create follow-up tasks from this meeting” can show its proposed tasks before writing them. A tool that names an outcome gives the model a clearer action to call and gives the product team a meaningful result to evaluate.

That does not mean hiding all the detail. The action needs a precise contract. Required inputs. A readable result. An explicit rule for what it is allowed to change. A good MCP server has the same obligation as a good public API: the next caller should not have to guess what a tool means or how it fails.

Write actions deserve extra friction. The model can propose the message, the tasks, or the changed status. Consequential writes should be validated against the user’s permissions and record rules, explicitly confirmed where appropriate, and recorded. MCP is useful for remote, user-authorized access because it addresses this boundary. A conversational surface does not inherit the right to act merely because it can describe the action persuasively.

The System of Record Stays in the Product

Putting an app in an AI does not mean moving its state into a transcript.

The product remains where the durable facts live. It owns the record, its history, the rules that protect it, and the ordinary interface people use when they need to spend an afternoon with it. The model gets a controlled view of that state and a controlled way to ask for changes. If the conversation disappears, the work must still be there. If the model misunderstands, the application must reject the invalid change. If a person asks who changed something, the answer belongs in the product’s audit trail, not in a scroll of generated prose.

That split also keeps the model from becoming an expensive page router. A conversation can select the relevant account, date range, or work item. The app can then render a chart, a form, or a queue for the part that needs direct manipulation. MCP Apps are useful when text would otherwise force the model to rebuild a visual, stateful interaction on every turn. They are not a reason to rebuild the whole product inside a chat window.

The boundary should be plain enough to test. The model may search these records. The model may propose these changes. Code validates these fields. Consequential actions receive confirmation when their risk warrants it. The product writes this event. That is far more useful than a policy prompt asking the model to be careful. Rules are not controls, especially when the rule governs a customer’s data.

The Work Should Choose the Surface

There is no universal answer. A design tool should not throw away its canvas because conversational interfaces are popular. A scheduling product should not force every request through a model when a calendar grid answers it faster. The native app is the better fit when a person needs to see and manipulate its specialized state.

The conversational route is the better fit when the job begins with intent that crosses products. A user has the question and the surrounding material before they have a destination. They need the system to help choose the relevant app, carry the necessary context to it, and return a result that fits into the work already underway.

That is the practical test: where is the first durable artifact of the job? If it is a canvas, a ledger, a queue, or a form already open in your product, build there. If it is a request assembled from conversation and several sources, make the useful action available in the AI.

The app does not disappear. It becomes easier to reach at the moment it can actually help.

Footnotes

1. OpenAI, “Build with the Apps SDK”. ↩