The platformOne running app, not a stack of services.Most apps are assembled from frontends, APIs, workers, queues and separate services. On IKON, people, AI agents and devices work inside the same running app, sharing its state in real time, and the app keeps working when nobody is connected.
Microinstance architectureOne microinstance per session.A microinstance is a small server of its own for each running session of an IKON app. It holds the app's state, logic, AI agents and media in one place. It starts when someone arrives, keeps running while there is work to do, and stops when there isn't. People, devices, scheduled jobs and incoming requests can all start one. Conventional architectures split an app across separate API, real-time, worker and AI services. IKON keeps each session together and runs the infrastructure for you.
Isolated by defaultMicroinstances run in isolated containers that are never shared with another organisation. A compromised browser reaches its own session and nothing else.
Up in about a secondA microinstance starts from a warm pool the moment someone arrives, and stops on its own when its work is done. A scheduled job or an incoming request starts one too.
Failures stay smallA crash ends one microinstance. The others keep running, and the next visitor gets a new one.
Paid for while it runsA microinstance is billed for the time it runs. An app nobody is using costs nothing to run.
Thousands per machineMicroinstances are light, so thousands run on one machine and every user can have a server of their own.
No API to protectThe browser draws what the session sends over one encrypted connection. There is no data endpoint behind it and no credential in the client.
What you writeOnly the part that is yours.Each of these can be built on a conventional stack. The middle column is how much infrastructure that takes before you get to the product itself.
The app doesAssembled on a conventional stackWhat you write on IKONPeople in a call with an AI agent that listens, transcribes and speaks
Conventional stackWebRTC signalling, a media server, TURN, codecs and reconnection; a bridge to the app; speech vendors; a long-running process for the agent; call state kept in step with app state
On IKONWho is in the room, what the agent listens for and what it says.
State that people and an AI agent change togetherConventional stackA WebSocket layer, a presence service, sync and conflict handling, and a worker that calls the model and writes back
On IKONDeclare the state. The agent is a participant that reads and writes it.
Work that continues after everyone leavesConventional stackA queue, workers, a scheduler, idempotency and failure recovery, each deployed and monitored on its own
On IKONAn ordinary method on the app.
Devices, people and AI agents in one appConventional stackA device protocol, a gateway, a second client stack, and plumbing between the device and user paths
On IKONThe device joins the session through an SDK, on the same protocol and state.
Approvals and an audit trail inside an automated workflowConventional stackA policy engine, approval screens and routing, an audit log, and retries around the human step
On IKON[RequireApproval] on the function. The runtime adds the approval step, its routing and the audit trail.
What apps can doBuilt in from the start.
VoiceVoice you can interrupt.The app hears and speaks. Audio and video arrive at your app on the server, not at a separate video service, so the app can transcribe a meeting, watch the camera and answer aloud. When someone talks over it, it stops mid-sentence.
MultiplayerRooms that keep running.People and AI agents share live state in the same session, with no extra code. Close the app and come back later, and you'll find the room kept running while you were away.
Always onAgents that keep working.The app keeps running after you close the browser tab. An agent can sort the weekend's inbox while nobody is in the office. When it reaches something it isn't allowed to do, it stops instead of guessing.
DevicesDevices join the app directly.With 6 SDKs, sensors, phones and native apps join the same app as participants, instead of calling it through an API. If a sensor is unplugged mid-shift, the line keeps running in a reduced mode instead of stopping.
ConnectionsReachable on your terms.Your app runs as a live process, and you decide how it can be reached.
Model Context ProtocolMark a function [Mcp] and it becomes an MCP endpoint. Claude, or any other MCP client, can then call your running app, and your app decides what each caller is allowed to do.
Endpoints when you want themYour app has HTTP, WebSocket, TCP and UDP endpoints only when you declare them. No API is generated for you and left open with only a check in the browser to protect it.
Connectors in app codeGitHub, Slack and WhatsApp are libraries your app uses directly. Ask for one, for example "make it post to Slack", and the agent writes the integration into the app.
Git, both waysConnect an external repository and it is mirrored each time you open the app, or whenever you ask. You can work locally with your own tools and keep building in Studio, and both share one history.
Six SDKs, one sessionC#, TypeScript, Dart/Flutter, Rust and C++ all join the same IKON app as equals, so a browser, a phone, a native app and a device can share one session.
Webhooks and paymentsInbound webhooks are ordinary endpoints. Charging end users is built in, so taking money is app code rather than another integration.