AgentSpace: a shared workspace that treats agents as staff with owners, permissions and audit trails

Agents as teammates inside an organization, not solo tools

AgentSpace, from HKUDS, is an agent-native collaborative workspace built for human and agent teams. The README's argument is that most agent frameworks assume solo use, while real work crosses people, systems and accountability boundaries. AgentSpace tries to bring the structure of a workplace to that mix: agents with defined roles, owners and responsibilities, working alongside humans in a shared space.

The intended user is a team or organization that wants to run agents at more than one-person scale and keep control while doing it. The feature list is organizational rather than technical: recruit and assign agents with defined owners, coordinate multi-agent workflows, schedule agent work, enforce permissions and approvals on sensitive actions, audit everything, and share or transfer agents across teams.

The name collides with a Google product, so it is worth being clear that this is the HKUDS open-source project under Apache-2.0, not the commercial Gemini Enterprise offering. It supports four agents by name in its badges: Claude Code, Codex, OpenClaw and Hermes.

Governance is the actual product

The distinguishing idea is that AgentSpace treats agent governance as the core, not an add-on. The README lists permissions and approvals to keep sensitive actions inside governance boundaries, and full audit visibility into agent actions, decisions and outputs. Agents can be recruited, transferred and audited across the organization.

That matters because the failure mode of running many agents is not capability, it is accountability: when an agent does something wrong, who owned it, what was it allowed to do, and where is the record. AgentSpace answers those by giving each agent an owner and a role, gating consequential actions behind approvals, and logging actions for audit. This is the workplace metaphor made concrete, an agent is a digital employee with a manager and a paper trail.

The README positions it against tools like Feishu with a pointed line: Feishu was built for humans, AgentSpace is built for both. Whether the metaphor holds up depends on the depth of the permission and audit implementation, which the README asserts more than it demonstrates in the text, so the governance claims are the first thing to verify against the running product.

Two deployment modes: hosted or self-run daemon

AgentSpace offers two ways to run, and the README frames them as a choice by team readiness. The hosted Platform mode is for teams that want to start immediately with no infrastructure, database or daemon host to manage, reachable through the project's hosted site. The self-hosted path runs the stack yourself, and the repository ships a packaged daemon, `agent-space-daemon-0.1.3.tgz`, plus a `deploy/` directory for that purpose.

For local development the README gives a single combined command:

npm run setup && npm run dev:web

That runs the setup step and starts the web app. The requirements badges call for Node.js 24 recommended and PostgreSQL 16 recommended, so a self-hosted instance needs a Postgres database behind it, and the `.env.example` in the tree is where connection and provider configuration goes. The project is a monorepo with `apps/` and `packages/`, consistent with a web app plus shared libraries and a daemon.

The hosted option lowers the barrier to trying it, but a team serious about the governance and audit story will want the self-hosted path, because that is where the sensitive data and the permission boundaries actually live under your control.

Where the workplace metaphor gets tested

The honest limitation is that AgentSpace's value depends entirely on how well the governance is enforced, and that is hard to judge from a README. Permissions, approvals and audit trails are easy to list and hard to make airtight, and an approval gate that an agent can route around is worse than none because it implies a safety that is not there. Anyone adopting this for real accountability should test the boundaries adversarially before trusting them.

The second limitation is operational surface. Running the self-hosted mode means operating a Node 24 app, a PostgreSQL 16 database and the daemon, and keeping four different agent backends configured. That is a meaningful stack for a team without infrastructure staff, which is presumably why the hosted mode exists.

There is also the maturity question. The daemon is versioned `0.1.3`, which is early, and a project defining organization-wide agent governance is taking on a large surface that will keep changing. The README's Chinese and English bilingual docs and community groups suggest active development, but early versions of governance systems are exactly where you should expect gaps.

Against a single-agent CLI or an ad-hoc script

The alternative most teams have today is running each agent on its own, a Claude Code or Codex session per person, coordinated by chat and shared docs. That is simpler and needs no platform, and for a small team it works.

What it does not give you is the thing AgentSpace is built around: a shared record of which agent did what, under whose ownership, with which permissions, and an approval gate before a sensitive action runs. Ad-hoc agent use has no audit trail and no transfer mechanism; when someone leaves or an agent misbehaves, there is nothing to inspect. AgentSpace trades the simplicity of solo agents for that structure, at the cost of running a platform. Choose solo agents when a couple of people coordinate informally and accountability is not a concern. Choose AgentSpace when you are scaling agents across a team or organization and need ownership, approvals and audit to keep that from becoming ungovernable, and you are willing to run or host the platform to get them.

Apache-2.0 and what to check first

AgentSpace is Apache-2.0, so it can be self-hosted, forked and adapted commercially with attribution, and it carries the patent grant. For a governance platform meant to hold an organization's agent operations, a permissive license and a self-hostable design are the right combination, since a team that cares about audit will also want the option to run everything on its own infrastructure.

Upgrade cost tracks the daemon and the web stack: the packaged daemon is at `0.1.3` and the app pins Node 24 and PostgreSQL 16, so keeping current means moving with those. The `deploy/` directory and the `.env.example` are the files to read before a self-hosted rollout.

The concrete first step is to decide hosted versus self-hosted based on where your agents' actions and data may live, then, before relying on the governance claims, create an agent with a restricted permission set and confirm the approval gate and the audit log actually capture and hold a sensitive action. The workplace metaphor is only as strong as that enforcement, so test it before you build a team's accountability on it.

Editorial conclusion

Adopt HKUDS AgentSpace if you are running AI agents across a team or organization and need each one to have an owner, a permission boundary, an approval gate and an audit trail: that governance layer, not raw capability, is the reason to choose it over solo agent sessions. It is the wrong fit for a single user coordinating informally, or for a team unwilling to run a Node 24 and PostgreSQL 16 stack for the self-hosted mode. Before trusting it, pick hosted or self-hosted based on where your data may live, run npm run setup && npm run dev:web locally, and create a restricted agent to confirm the approval and audit paths actually hold a sensitive action.

Frequently asked questions

Official sources

1. HKUDS/AgentSpace on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README