Early Access Preview
Back to blog
engineeringarchitectureagentsapps

Community Apps: From Install to Auto-Integrated in the Agent OS

March 5, 20268 min readAitherium
Share

The AitherOS Community App Package Manager lets you browse apps from the Aitherium awesome-llm-apps catalog, install them with one click, and launch Streamlit, Gradio, or FastAPI apps into isolated Python venvs. Users love it. But once an app was installed, it lived in a vacuum — the rest of the system didn't know it existed. Agents couldn't discover it, couldn't launch it, and couldn't delegate tasks to it.

We just closed that gap. Installed community apps are now automatically integrated into three layers of the AitherOS agent ecosystem.

The Three Integration Layers

1. Tool Registration — Agents Can Manage Apps

Every agentic conversation in AitherOS — whether it's Genesis orchestrating a request or a specialized agent like Demiurge or Atlas — now has six new tools:

ToolWhat It Does
list_community_appsBrowse the catalog with category, status, or search filters
install_community_appGit clone + venv + pip install — full install lifecycle
launch_community_appStart the app, get back the URL where it's running
stop_community_appStop a running app
get_community_app_statusCheck install state, port, PID
refresh_community_catalogRe-scan configured GitHub sources for new apps

So when a user says "I need a travel agent that can book flights", the agent can:

  1. Call list_community_apps with query: "travel"
  2. Find the AI Travel Agent in the catalog
  3. Call install_community_app if it's not installed yet
  4. Call launch_community_app and return the URL

The user gets a working app. The agent did the work.

2. Capability Registration — The LLM Knows What's Available

The LLM's context window includes a [CAPABILITIES] block — a token-efficient summary of what the system can do. We now register every installed community app there.

On AitherAppStore startup, and after every install/uninstall, we call register_community_app_capabilities(), which:

  • Registers an aggregate capability: "N third-party AI apps installed and ready to launch"
  • Registers each app individually with its display name, framework, and tags

So the model sees community apps before it decides to use a tool. It knows what's installed, what's running, and what it can recommend. No blind tool calls.

3. A2A Registration — FastAPI Apps Become Agent Peers

The AitherOS A2A Gateway is where agents discover and delegate to each other. When you launch a FastAPI- or Flask-based community app, we now automatically register it with the gateway.

  • On launch: The app gets an agent card with its URL, description, and a skill mapping its main capability
  • On stop: We unregister it so the gateway stops routing requests to a dead process

Streamlit and Gradio apps are UI-only — they don't expose APIs — so we skip A2A for those. But any app that does expose an HTTP API can now participate in the agent mesh. Other agents can discover it via GET /skills or GET /agents and delegate tasks directly.

The Architecture

User installs app via UI or chat
  → AppInstaller: clone + venv + pip install
  → CapabilityRegistry: "I now have X installed" (LLM sees it)

User (or agent) launches app
  → AppRunner: starts process on auto-assigned port
  → A2A Gateway: registered (if FastAPI/Flask)
  → Other agents can discover + delegate to it

Agent in conversation needs an AI capability
  → LLM sees community apps in [CAPABILITIES]
  → Uses launch_community_app tool
  → Opens URL for user or delegates via A2A

The integration is a thin layer that wires the app catalog, the capability registry, and the A2A Gateway together. The chat system registers community app tools alongside web tools, agent dispatch tools, and the rest. The app store triggers capability refresh on install/uninstall and A2A registration on launch/stop.

What's Next

  • App-level aither-app.yaml: Today we infer framework and entry points from README + requirements. A proper manifest per app will let us declare A2A skills explicitly and support more advanced runtimes.
  • Cross-agent delegation: Agents could spawn a community app, delegate a subtask via A2A, and stream results back into the main conversation. The plumbing is there; we need agent prompts to learn when to reach for it.
  • Skill discovery from running apps: If an app exposes /.well-known/agent-card.json, we could auto-ingest its skills instead of synthesizing a generic card. That would make community apps first-class A2A citizens.

For now, the path from install to usable by agents is closed. Community apps are no longer orphaned. They're part of the OS.

Enjoyed this post?
Share