---
title: The system at a glance
description: One application protocol, durable execution, and clear boundaries between presentation and authority.
---

Impo separates the user's interface from the lifetime of their work. Clients present conversations and collect permissions. The API accepts account-owned commands. Workers execute them through a managed agent runtime and persist enough state to recover.

![Clients and gadgets connect through the Impo API and gateway. Workers coordinate agent execution and owned application storage.](/assets/framework-map.svg)

## The main components

| Component | Responsibility | Source |
| --- | --- | --- |
| iOS, Android, Web | Presentation, durable sends, subscriptions and platform capabilities. | `ios/`, `android/`, `web/` |
| API | Authentication, ownership, validation and durable admission. | `server/src/http/` |
| Worker | Agent execution, tool dispatch, retries and reconciliation. | `server/src/worker/`, `server/src/rebyte/` |
| Temporal | Durable timers and background coordination. | `server/src/temporal/`, `server/src/background/` |
| Database repositories | Transactions, identity, leases and owned records. | `server/src/db/repositories/` |
| Gadget gateway | Paired device sessions, command transport and event forwarding. | `server/gadget-gateway/` |

The application backend uses Rebyte for agent execution, Composio for connected services, and server-side speech providers. Provider protocols are adapters behind the Impo API; clients do not call them directly.

## Commands and subscriptions

A command changes application state or requests work. A stream subscribes to that work. Disconnecting a stream does not cancel its run.

Every accepted send has stable identity. The client can retry an uncertain request, reconnect later and reconstruct the conversation without generating a second message. Cancellation is a separate command. See [execution and recovery](/docs/architecture/execution/).

## The three forms of execution

**Main Chat** is the user's continuing conversation. The worker maintains a main Saved Agent and rotates Sessions while preserving readable history.

**Tasks** are isolated units of delegated work with separate conversations. A scheduled task is a trigger that admits ordinary task execution, not a different model runtime.

**Background steps** inspect or consolidate context on durable schedules. Feed and Memory use this path. They have their own scope and tool restrictions.

## Where the boundaries matter

- Model-generated content comes from a Rebyte Agent. Product generation does not run inside an HTTP handler.
- Native capabilities belong to a particular registered phone, with current permission state.
- Gadget commands belong to the paired account and use only registered operations.
- Database access goes through repositories. A feature handler does not acquire an unrestricted query builder.
- Provider secrets remain server-side. Device setup credentials are distinct from provider and gateway administration credentials.

For the hardware extension model, continue to [Gadgets and the four rings](/docs/gadgets/overview/). That model describes authority and customization; the diagram here describes deployment and data flow.

## Implementation reference

The detailed [architecture reference](https://github.com/impoai/impo/blob/main/docs/architecture.md), [client protocol](https://github.com/impoai/impo/blob/main/contracts/client-protocol.md) and [runtime composition](https://github.com/impoai/impo/blob/main/server/src/runtime.ts) connect these concepts to the current implementation.