A Creospan perspective on the new app layer inside ChatGPT and what it means for how software gets built in the AI era.
For nearly two decades, software distribution followed a familiar playbook. You built a website, launched a mobile application, optimized for search, and eventually published to an app store. Users discovered your product, downloaded it, and learned how to use it.
That model is beginning to change.
With more than 800 million weekly active users, ChatGPT is no longer just an interface for interacting with AI. The introduction of the Plugin Directory has transformed it into an application platform where specialized AI apps can be surfaced, discovered, and invoked as part of a conversation. Instead of simply answering questions, ChatGPT can now orchestrate real workflows: from booking travel and comparing insurance to editing designs and retrieving enterprise knowledge – all by calling the right application at the right moment.
This represents more than another AI feature. It introduces a new software distribution channel where applications are surfaced not through app stores or search results, but through conversations.
For software companies and technology consultancies alike, the question is no longer simply:
“How do we add AI to our product?”
It’s rapidly becoming:
“How does our product become something AI can understand, discover, and use?”
That distinction changes almost everything about how AI-native software should be designed.
The Next Platform Shift
The transition from desktop software to mobile apps forced organizations to rethink interfaces, distribution, and user experience. The transition to AI applications is forcing us to rethink something even more fundamental: who the first user actually is.
Traditionally, software was designed exclusively for humans. Users discovered an application, decided whether it solved their problem, and interacted with its interface directly. AI applications introduce another decision maker. Before a person ever sees your interface, an AI model may already have decided:
- whether your application should be invoked,
- what information should be passed to it, and
- whether another application is better suited for the task.
In other words, your application is no longer designed solely for people. It’s also designed for another AI. That single shift has profound implications for application architecture.
Before a human ever interacts with an application, an AI model evaluates its tool names, descriptions, schemas, and metadata to determine whether it should be invoked. In effect, the model becomes another consumer of your software: one that relies on clear semantics rather than visual interfaces. That changes the role of metadata entirely.
Tool descriptions are no longer just documentation; they become part of the application’s interface. Schema design is no longer simply an implementation detail; it directly influences whether the model can understand when and how to use a capability. Even seemingly small decisions, such as naming a tool or describing its purpose, can affect how reliably it is discovered during a conversation. In many ways, designing an AI application begins long before a user sees a button or a screen.
Why Narrow Wins
One of the first instincts when building an AI application is to expose everything. If an organization has dozens of APIs, hundreds of business functions, and years of accumulated domain knowledge, why not make all of it available through a single intelligent assistant? It’s an intuitive idea, but one that quickly breaks down in practice. The challenge isn’t simply building the application. It’s helping the model decide when to use it.
Unlike traditional software, AI applications aren’t always launched explicitly by users. Increasingly, they’re surfaced by the model itself as it determines which capability is most appropriate for a particular conversation. That decision depends on how clearly an application’s purpose can be understood. An application responsible for one well-defined outcome presents an obvious choice. An application that claims to handle quoting, claims, billing, customer support, policy management, document search, recommendations, and account administration presents a much harder decision, not only for the user, but for the model attempting to orchestrate the workflow.
OpenAI’s own developer guidance reinforces this idea, recommending that applications be “tightly scoped, intuitive in chat, and deliver clear value.” While that advice may sound like a UX recommendation, it’s really an architectural one. This doesn’t mean organizations should build smaller businesses or abandon integrated platforms. Enterprise systems will continue to span dozens of products, services, and business functions. The difference is that those capabilities no longer need to be exposed through a single AI application. Instead, AI-native experiences benefit from being organized around customer journeys rather than organizational structures. A customer looking to compare insurance options doesn’t need access to every policy management capability. A traveler booking a rental car doesn’t need the entire fleet management system. The goal isn’t to replicate an organization’s internal architecture inside an AI assistant; it’s to expose the smallest set of capabilities required to complete a specific task.
Thinking this way naturally leads to another important shift. Rather than building one monolithic assistant that attempts to answer every question and execute every workflow, organizations should think in terms of composable capabilities: small, focused applications that do one job well and can be orchestrated together when broader workflows are required.
That philosophy extends beyond user experience. It simplifies development, improves maintainability, reduces the likelihood of unintended model behavior, and makes individual capabilities easier for AI systems to discover and invoke reliably.
Architecting Beyond a Single Platform
If conversational interfaces are becoming a new distribution channel, another question naturally follows:
How do you avoid rebuilding the same application for every AI platform?
One of the more significant developments in this ecosystem is that OpenAI’s Apps SDK is built on the Model Context Protocol (MCP), an open standard rather than a proprietary integration framework. That distinction allows application logic to be separated from platform-specific integrations.
Instead of embedding business logic inside ChatGPT-specific code, organizations can build reusable MCP services while keeping platform adapters, such as authentication, widgets, or interface components, etc. at the edge. Supporting another MCP-enabled platform then becomes an incremental integration effort rather than a complete rewrite.
As more AI assistants adopt MCP and similar interoperability standards, this approach becomes increasingly valuable. Rather than building for one platform at a time, organizations can build reusable AI capabilities that travel across an expanding ecosystem.
Building Software for an AI-First Future
The emergence of AI application platforms marks a shift that extends well beyond another interface trend. As AI increasingly becomes the first consumer of software, organizations must rethink how capabilities are designed, described, and exposed. Success will depend not only on building intelligent features, but on creating applications that AI systems can reliably understand, discover, and orchestrate.
For technology leaders, this represents an opportunity to move beyond simply embedding AI into existing products. It is a chance to architect software for a future where conversational interfaces become a primary distribution channel and interoperable standards enable capabilities to reach users across an expanding ecosystem of AI platforms. The organizations that embrace this shift early, building focused, composable, and AI-native experiences will be better positioned to deliver value wherever intelligent assistants become the next point of interaction.
Article Written by Vishal Shrivastava