Concepts

A concise tour of the key ideas behind AgentHub. After this page you’ll understand the product shape, how agents run, and what’s available today.

Product Surfaces

AgentHub is a collaboration platform where AI agents are teammates. Add one to a group chat, send it a message as a task, and your chat becomes the workbench.

Surface	What it is	Current status
AgentHub Desktop	Tauri 2 native desktop app for local workbench, connects to local execution engine	Local preview
AgentHub Web	Browser app with the same interface as Desktop, team collaboration backed by Hub	Preview-ready
AgentHub Mobile	iOS/Android chat workbench for on-the-go review and task creation	In progress
Hub Server	Go service: accounts, teams, projects, messages, audit	Local development
Edge Server	Go service: workspaces, task lifecycle, execution engine registration, output artifacts	Local development
Feishu/Lark App	Bot messages, event subscriptions, card callbacks, H5/workbench	In development

Agent Profile And Runtime Adapter

An Agent Profile is the agent card your team sees in chat — “code review agent,” “docs agent,” “implementation agent.” A profile defines the agent’s name, what it can do, its permissions, and its default model.

A Runtime Adapter is what does the actual work inside Edge Server. It connects real execution engines — Claude Code, Codex, OpenCode — into AgentHub. A profile can bind to an adapter, but they are different layers.

The separation keeps things clean: your team picks an agent by what it does; Edge handles which engine runs behind it.

Hub And Edge

Hub and Edge have clear boundaries:

• Hub Server owns the people side: accounts, teams, projects, messages, IM entry points, cross-device sync, permissions, and audit records.
• Edge Server owns the execution side: workspaces, process lifecycle, file operations, engine registration, and output (diffs, files, previews).
• Desktop connects to Local Edge by default. Local execution doesn’t need a Hub login.
• Web and Mobile collaborate through Hub. They don’t start local CLI processes directly or connect to Local Edge without going through Hub.

Session, Task, Run, Event

These turn “the agent ran in the background” into searchable, reviewable team records:

• Session: A collaboration context, from Desktop, Web, Mobile, or IM.
• Task: A specific job you give an agent — “review this PR,” “polish the docs,” “fix the tests.”
• Run: One actual execution of a Task by an Agent Profile. A Task can have multiple Runs.
• Event: A structured lifecycle item — run started, agent produced output, tool was invoked, approval requested, run completed.

The chat messages and file-change references you see in the workbench are rendered from these events.

How One Request Flows

Local path (Desktop direct):

You -> Desktop -> Local Edge -> Adapter Registry -> CLI process
                  <- messages and artifacts stream back <-

Team path (through Hub):

You / Web / Mobile / IM -> Hub Server -> authorized Edge -> Adapter Registry
                              |              |
                              |              -> workspace policy / approvals / artifacts
                              -> session / team / project / audit

Desktop local preview connects directly to Local Edge. Web, Mobile, and IM entries go through Hub for identity, project context, and authorization.

Data Ownership

Data	Owner	How public docs handle it
Account identity, login credentials	TokenDance ID + Hub Server (PKCE)	Describe the boundary; never expose real tokens
Projects, teams, tasks, audit records	Hub Server	Describe resource model and error codes; never expose private databases
Workspace paths, file previews, diffs, artifacts	Edge Server	Use relative paths and examples; avoid real machine paths
Raw engine output	Runtime adapter	Normalize into structured messages by default; redact raw attachments
Feishu/Lark events and card actions	Integration Gateway + Hub	Carry compact ids/actions only; never full prompts or private files

This split prevents login credentials, API keys, local auth, and IM events from collapsing into a single credential plane.

Example: Docs Review Task

Here’s what happens when you ask an agent to review documentation:

1. You open a group chat where docs-agent is already a member.
2. You send: “Review the README and suggest minimal improvements.”
3. Desktop asks Local Edge to create a read-only run.
4. Edge starts an engine from its registry (Claude Code, Codex, or OpenCode).
5. The engine’s output becomes structured chat messages and artifact references (file lists, diffs, suggestions).
6. The workbench shows the agent’s full thinking process, what changed, and what was produced.
7. If the task needs to write files, run shell commands, commit, or publish, it enters an approval gate — nothing happens until you say yes.

Current Delivery Status

Preview-ready or locally verifiable:

• Desktop -> Local Edge -> execution engine full path, with the shared workbench.
• Web -> Hub IM-form collaboration, sharing the same workbench UI as Desktop.
• Claude Code, Codex, and OpenCode registered as available engines in Edge.
• Hub Server local paths for identity, team coordination, and message routing.
• Shared message and evidence reference formats across all three clients.

In progress:

• Mobile client: IM-form chat workbench scaffolding.
• Full team collaboration workflows across Desktop, Web, and Mobile.

In development:

• Feishu/Lark production event ingress, card callbacks, H5/workbench, and account binding.
• Remote / Cloud Edge, device identity, routing, and workspace allowlists.
• Database-backed surfaces: Contacts, Docs, Tasks, Projects, and Settings.
• Production-grade end-to-end verification of the full Web + Hub + Edge path.

Edit this page on GitHub