Community Apps: From Install to Auto-Integrated in the Agent OS
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:
| Tool | What It Does |
|---|---|
list_community_apps | Browse the catalog with category, status, or search filters |
install_community_app | Git clone + venv + pip install — full install lifecycle |
launch_community_app | Start the app, get back the URL where it's running |
stop_community_app | Stop a running app |
get_community_app_status | Check install state, port, PID |
refresh_community_catalog | Re-scan configured GitHub sources for new apps |
So when a user says "I need a travel agent that can book flights", the agent can:
- Call
list_community_appswithquery: "travel" - Find the AI Travel Agent in the catalog
- Call
install_community_appif it's not installed yet - Call
launch_community_appand 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.