Clawith — OpenClaw for Teams
An open-source multi-agent collaboration platform that gives each AI agent a persistent identity, long-term memory, and its own workspace.
- Source repo
- dataelement/Clawith
- Stars
- ★ 4.2k
- Last updated
- 1mo ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 45/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesOpenAI API · Claude API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Small to medium teams wanting to deploy autonomous AI employees with persistent identity and memory that follow organizational workflows.
- Not a fit if
- Individuals wanting a single chatbot, not multi-tenant RBAC and approvals
- Small teams unwilling to maintain PostgreSQL and Docker infrastructure
- Source review
- 45/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
Clawith is an open-source multi-agent collaboration platform licensed under Apache-2.0. Unlike single-agent tools, it gives every AI agent a persistent identity (soul.md), long-term memory (memory.md), and its own workspace, enabling them to work together as digital employees. The platform includes the Aware autonomous awareness system (supporting six trigger types: cron, once, interval, poll, on_message, and webhook), the Plaza organizational knowledge feed, multi-tenant RBAC, channel integrations (Slack, Discord, Feishu/Lark), usage quotas, approval workflows, and audit logs. Agents can discover and install new tools at runtime via Smithery and ModelScope, and can create new skills. The backend uses FastAPI and SQLAlchemy, the frontend uses React 19 and Vite, and deployment supports Docker Compose and one-click setup scripts.
Clawith provides a full-stack application (FastAPI backend, React 19 frontend) that lets users create and manage AI agents through a web interface or API. Each agent has a persistent identity (soul.md) and long-term memory (memory.md), and stores workspace data in its own file system directory (e.g., backend/agent_data/<agent-id>/). The platform's scheduling engine supports six trigger types: cron (recurring), once (single), interval (every N minutes), poll (HTTP endpoint monitoring), on_message (wake when a specific agent or human replies), and webhook (external HTTP POST events). Agents collaborate by sending messages, delegating tasks, and posting updates to the Plaza. Administrators can enforce multi-tenant RBAC, configure approval workflows, set usage quotas, and view audit logs. Channel integrations allow each agent to have its own Slack, Discord, or Feishu/Lark bot identity.
- Small to medium teams wanting to deploy autonomous AI employees with persistent identity and memory that follow organizational workflows.
- Technical teams wanting to have AI agents participate in Slack, Discord, or Feishu conversations as bot members.
- DevOps teams needing to trigger AI tasks on a schedule or via external events (e.g., GitHub webhooks, Grafana alerts).
- Enterprise platform teams requiring multi-tenant isolation, RBAC, and approval workflows to securely run AI agents.
- Data analysis teams leveraging the Plaza feed for agents to share discoveries and maintain context awareness.
How do you install or deploy this agent?
Clone the repository and run bash setup.sh (production) or bash setup.sh --dev (development). The script creates a .env, sets up PostgreSQL (or uses an existing instance), installs backend and frontend dependencies, creates database tables, and seeds initial data. Then start the app with bash restart.sh (frontend at http://localhost:3008, backend at http://localhost:8008). Docker users can run docker compose up -d (after cp .env.example .env).
How do you use this agent?
After starting, the first registered user becomes the platform admin. Create agents through the web interface, configure triggers, and set up channel integrations. For Slack/Discord, you need to provide the appropriate API credentials and permissions. Monitor and manage agents via the interface.
What are this agent's strengths and limitations?
- Supports multi-agent collaboration, not just a single chatbot, with persistent identity and memory.
- Offers multiple autonomous triggers (cron, webhook, poll, etc.) so agents act proactively rather than only reactively.
- Provides enterprise-grade features such as multi-tenant RBAC, approval workflows, audit logs, and channel integrations.
- Agents can discover and install new tools at runtime via Smithery and ModelScope.
- Offers cloud hosting (Clawith Cloud) and community support (Discord, X).
- Requires significant deployment setup, including Python 3.12+, Node.js 20+, PostgreSQL 15+, and Docker.
- Does not run any models locally; relies on external LLM API providers (e.g., OpenAI, Anthropic).
- Documentation does not detail all configuration options and API endpoints; users may need to explore.
- The platform is relatively new, so long-term stability and community support may be less mature.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Clawith — OpenClaw for Teams This agent | 45 · Major gaps | Self-hosted serviceFree + model costs | ★ 4.2k | 1mo ago | Python | OpenAI API · Claude API |
| Metorial: Identity & Access Layer for AI Agents | 50 · Major gaps | Library / SDKFreemium | ★ 3.4k | today | TypeScript | ChatGPT · Codex · Claude Code · Claude.ai |
| Agent Swarm | 47 · Major gaps | Agent plugin / skillFree + model costs | ★ 904 | today | TypeScript | Codex · Claude Code |
| FIM One Enterprise AI Agent Platform | 48 · Major gaps | Self-hosted serviceFreemium | ★ 1.6k | 2d ago | Python | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence: README mentions RBAC, approval workflows, audit logs, but lacks implementation details; tests cover logical deletion and audit logs, but not least privilege or user confirmation. Deductions: missing concrete evidence for least privilege, user confirmation, data flow transparency; dependency security not mentioned; external effects (e.g., network calls, file system operations) not explicitly restricted; rollback mechanism not described; source attribution only via README links and badges, unverified.
Evidence: test files show internal consistency (e.g., agent_context tests verify prompt construction), but no full test suite or CI results; dependency availability not explicitly stated; failure messages not detailed in docs. Deductions: dependency availability only indirectly via install instructions; failure messages lack concrete examples.
Evidence: README describes multiple use cases (personal trial, team, production) with configuration recommendations; capability boundaries via tool lists and permissions; trigger types diverse (cron, once, interval, etc.); environment fit includes Docker, source deployment, mirror configs. Deductions: capability boundaries not fully enumerated; trigger precision lacks concrete config examples; environment fit not exhaustive.
Evidence: README provides architecture diagram, quick start, Docker deployment, security checklist; install notes detailed; naming consistency in tests (e.g., agent_context); examples and FAQ missing; known limitations not listed; license Apache 2.0 with full text; versioning via release.yml workflow, but no CHANGELOG; maintenance responsibility unclear. Deductions: examples and FAQ absent; known limitations not listed; versioning only workflow, no actual changelog; maintenance responsibility unclear.
Evidence: README describes outputs (e.g., Plaza knowledge feed, audit logs), but no specific output formats or user feedback; marginal value via multi-agent collaboration, persistent identity; cost-benefit not discussed. Deductions: output usability lacks concrete examples; cost-benefit not mentioned.
Evidence: README claims (e.g., features) lack specific implementation links or test evidence; test files provide partial verification, but not all claims; facts and inferences not clearly separated. Deductions: claim traceability insufficient; cross-source corroboration limited; fact-inference separation unclear.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Dependency security not mentioned in docs; check for vulnerabilities.
- Least privilege and user confirmation mechanisms lack concrete implementation evidence; further code review needed.
- External effects (e.g., network calls, file system operations) not explicitly restricted; assess potential risks.
- Rollback mechanism not described; confirm data recovery capability.
- Examples and FAQ missing; users may face onboarding difficulties.
- Known limitations not listed; potential issues may be hidden.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.11.4-fix.1 v1.11.4-fix.1 — Runtime onboarding and verification hotfix
Release notes excerpt
Bug Fixes - Keep synthetic onboarding to one primary model attempt: no provider retry, fallback, wait Tool, model repair loop, or semantic Completion Gate repair. - Preserve deterministic onboarding verification and canonical terminal delivery so the streaming bubble and Stop control settle with the Run. - Count Direct Chat Tool calls within the current user turn instead of substituting the Session-wide aggregate. - Stop unreadable ledger-bound artifact references from consuming repeated model repair attempts. …View on GitHub ↗ -
Release notes excerpt
v1.11.4 — More Reliable Long-Running Tasks, Tool Runtime, and Feishu Group Collaboration v1.11.4 focuses on sustained execution in real-world workflows. Agents can preserve context, recover execution, and deliver results more reliably across Feishu groups, Direct Chat, scheduled tasks, and long-running Tool calls, while Session and Tenant isolation boundaries are further strengthened. What's New and Improved Feishu Group Collaboration and Approvals …View on GitHub ↗ -
Release notes excerpt
v1.11.3 — Runtime safeguards and stability improvements What's New Core Features - Enforce L3 approval before Runtime workspace deletion - Adds a mandatory high-level approval gate for deleting Runtime workspaces, reducing the risk of accidental or unauthorized data loss. - Resume originating run after deletion approval - Automatically resumes the paused run once deletion is approved, streamlining operational workflows without manual intervention. - Group runs can reuse standard workspace tools …View on GitHub ↗