Clawith: A Multi-Agent Platform That Gives Every Agent a Desk, a Memory, and a Schedule
Your First AI Agents Company
At a glance
- What is it?
- Clawith is an open-source multi-agent collaboration platform that treats agents as persistent employees with identity, memory, and self-managed triggers. This review covers its architecture, setup, control features, and the trade-offs you should check before adoption.
- Who is it for?
- Adopt Clawith if you need agents that act autonomously over long horizons, with persistent memory and organizational controls like RBAC and approval workflows, and you can accept external LLM dependencies and a heavier stack (Python 3.12, Node 20, PostgreSQL). Avoid it if you want local inference, a lightweight single-agent tool, or a production system without a clear upgrade path from SQLite.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Clawith Actually Solves
Clawith addresses a specific gap: most agent frameworks are single-agent and stateless. You chat, get an answer, and the context vanishes. Clawith instead builds a persistent organizational layer where each agent has a soul.md, a memory.md, and a private file system. That means an agent can track a task across days, remember past decisions, and act on a schedule without a human prompting each step. The target user is a team that wants to deploy 'digital employees' rather than chatbots: agents that understand the org chart, message each other, and request human approval before risky actions. The README positions it as 'OpenClaw for Teams', suggesting a multi-user, multi-agent deployment rather than a personal assistant.
The Aware System: Focus Items and Trigger Binding
The core mechanism is called Aware. Instead of agents passively waiting for commands, they maintain a structured working memory of Focus Items. Each item has a status marker: `[ ]` pending, `[/]` in progress, `[x]` completed. The critical rule is focus-trigger binding: every task-related trigger must reference a Focus item via `focus_ref`. The agent creates the focus first, then binds triggers to it. When the focus completes, the agent cancels its triggers. This design prevents orphaned schedules that fire long after the task is done. Triggers come in six types: `cron`, `once`, `interval`, `poll` for HTTP endpoints, `on_message` for replies from specific agents or humans, and `webhook` for external POST events like GitHub or Grafana. The self-adaptive part is that agents can create, adjust, and remove triggers as the task evolves, so the human assigns the goal and the agent manages the schedule. This is a meaningful departure from static cron jobs.
Persistent Identity and Workspace: More Than a Prompt
Each agent has persistent files: soul.md for personality, memory.md for long-term memory, and a full private file system with sandboxed code execution. These persist across conversations, which is what makes an agent 'genuinely unique and consistent over time', according to the README. This is not just a system prompt appended to each request. The file system allows an agent to store artifacts, read past outputs, and build on previous work. The sandboxed execution is a key safety feature, but the README does not detail the sandboxing mechanism, so you cannot assume it is a full container isolation. You should verify what 'sandboxed' means in practice, especially if you plan to let agents run arbitrary code.
Organization-Grade Controls: RBAC, Quotas, and Approvals
Clawith includes multi-tenant RBAC with organization-based isolation. Each agent can have its own Slack, Discord, or Feishu/Lark bot identity, which is useful for teams that already live in those tools. Usage quotas limit per-user messages, LLM calls, and agent TTL, giving administrators a way to cap costs. Approval workflows flag dangerous operations for human review before execution, which is a critical feature for autonomous agents. Audit logs provide traceability. The README also mentions a Knowledge Base that injects shared enterprise context automatically. These controls suggest the platform is designed for production use, not just demos. However, the README does not explain how approval workflows are configured or which operations are flagged, so you will need to inspect the source or documentation to understand the granularity.
Getting It Running: Commands and Configuration
The quick start requires Python 3.12+, Node.js 20+, and PostgreSQL 15+ (or SQLite for testing). The minimum hardware is 2 cores, 4 GB RAM, and 30 GB disk. The setup is a one-command script: clone the repo, run `bash setup.sh` for production or `bash setup.sh --dev` for development (which adds pytest). The script creates `.env` from `.env.example`, sets up PostgreSQL (using an existing instance or downloading a local one), installs backend and frontend dependencies, and seeds initial data like default company and templates. If you prefer your own PostgreSQL, set `DATABASE_URL` in `.env` before running setup, for example `postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable`. After setup, start with `bash restart.sh`. The frontend runs at `http://localhost` (the README is truncated). Note that Clawith does not run any AI models locally; all LLM inference is via external APIs like OpenAI or Anthropic. The local deployment is a standard web app with Docker orchestration.
Where It Could Be the Wrong Tool
The most obvious limitation is that Clawith is not self-contained. It requires external LLM API endpoints, so if you need on-premise inference for data privacy or air-gapped environments, this platform will not work. The README states this plainly: 'Clawith does not run any AI models locally'. Another limitation is the operational footprint. Even a personal trial recommends 1 core and 2 GB RAM, and the full experience needs 4 GB RAM and a PostgreSQL database. That is heavy for a simple chatbot replacement. The setup also expects a Unix-like environment with bash scripts; Windows users will need WSL or a container. The README mentions SQLite for quick testing, but the production table suggests PostgreSQL for multi-tenant scenarios, so you need to decide early which path to take. The 'runtime tool discovery' from Smithery and ModelScope is a powerful feature but also a security risk: allowing agents to install new tools at runtime could introduce untrusted code. The README does not describe any vetting process for those tools.
Alternatives: Single-Agent Tools vs. Custom Orchestration
The most direct alternative is to use a single-agent framework like LangChain or LlamaIndex, which give you fine-grained control over one agent's memory and tools, but you would have to build the scheduling, focus-trigger binding, and multi-agent messaging yourself. Another alternative is a workflow orchestrator like Temporal or Prefect, which handle durable execution and retries but are not agent-aware; they do not provide persistent identity or self-modifying triggers. Clawith sits between these: it offers agent-specific abstractions (Focus Items, soul.md) on top of a web application with a database. If you only need a single autonomous agent that can call tools on a schedule, a simpler setup like a cron job plus a script might be sufficient and far lighter. The difference in approach is that Clawith assumes you want a whole crew of agents with organizational memory, not just one scripted bot.
Maintenance and Upgrade Considerations
The repository shows recent activity with releases like v1.11.4 and a hotfix v1.11.4-fix.1, indicating active maintenance. The license is Apache-2.0, which is permissive for commercial use, but you should review the license text for any patent or trademark clauses. The setup script handles initial database creation and seeding, but you will need to manage upgrades yourself: pulling new releases, running migrations (not documented in the README), and testing compatibility with your existing agent data. The use of a `restart.sh` suggests a restart-based deployment, but there is no mention of zero-downtime rolling updates. The dependency on external LLM APIs means your operational cost and reliability depend on those providers, not just on Clawith. Before adoption, check the changelog for any breaking changes in the trigger system or RBAC, since those are central to the platform's value.
Editorial conclusion
Adopt Clawith if you need agents that act autonomously over long horizons, with persistent memory and organizational controls like RBAC and approval workflows, and you can accept external LLM dependencies and a heavier stack (Python 3.12, Node 20, PostgreSQL). Avoid it if you want local inference, a lightweight single-agent tool, or a production system without a clear upgrade path from SQLite. Before committing, verify the actual behavior of focus-trigger binding in a pilot, test the approval workflow with your dangerous operations, and confirm that the runtime skill installation (Smithery and ModelScope) meets your security policy.
Community notes