AionUi Architecture and Runtime

1. The workspace shape

Even from the public product surface, the architecture intent is clear:

Area	Why it matters
desktop workspace	Main surface where users interact with agents
agent engine integrations	Connect Claude Code, Codex, Gemini CLI, and related backends
built-in assistants	Package repeatable role-oriented workflows
remote connectors	Let users control work from tools like Telegram or enterprise messengers
automation layer	Lets agents keep running on schedule

This is not a narrow coding app. It is a desktop coordination layer for multiple AI workers.

2. The runtime mental model

At runtime, AionUi generally looks like this:

1. the user starts work from the desktop,
2. one or more agents or assistants receive the task,
3. the selected model or existing CLI integration does the reasoning,
4. artifacts are created or actions are taken,
5. optional automation or remote follow-up continues the workflow.

3. Why built-in assistants matter

The official site emphasizes 20+ built-in assistants. That is an architectural clue:

AionUi is trying to ship ready-made roles, not only raw model access.

That makes the system more approachable for non-developers and more reusable for teams.

4. Remote control changes the product shape

Because AionUi supports remote control and 24/7 operation, it is best understood as more than a desktop GUI. It is closer to:

a local AI workstation that can keep acting after the desktop window is closed

That is especially relevant for business workflows and team adoption.

5. What to read first in code

If you plan to inspect the implementation, start with:

1. the repo overview,
2. packaging and desktop shell areas,
3. agent integration layers,
4. automation and remote-control surfaces.