Clawith: a multi-agent collaboration platform where every agent keeps an identity

The problem Clawith solves: agents that forget everything between sessions

Most single-agent tools treat a conversation as the unit of work. The agent answers, the context is discarded, and the next request starts from zero. Clawith takes the opposite position. The README describes it as an open-source multi-agent collaboration platform where every agent has a persistent identity, long-term memory and its own workspace, and where those agents then work together as a crew. The target reader is a team, not an individual: the repository talks about digital employees of your organization, an org chart every agent can read, delegation between agents, and multi-tenant role-based access control. If you are building a one-off assistant that summarises documents, this is heavier than you need. If you are trying to run several long-lived agents that share context and hold schedules, the persistence model is the reason to look at it.

Persistent identity: soul.md, memory.md and a private file system

The persistence layer is concrete. Each agent carries a soul.md for personality and a memory.md for long-term memory, plus a private file system with sandboxed code execution. The README states these persist across every conversation, which is what makes an agent consistent over time rather than reset per chat. Two environment variables in .env.example anchor where that data lives: AGENT_DATA_DIR, documented with defaults of ~/.clawith/data/agents on a local host and /data/agents in a container runtime, and the docker-compose service sets AGENT_DATA_DIR to /data/agents alongside STORAGE_LOCAL_ROOT. Storage is pluggable through STORAGE_BACKEND, which defaults to local. The practical consequence is that agent state is files on disk, not rows you can easily inspect from a database client, so your backup story has to cover the agent data volume and not only PostgreSQL.

Aware: Focus items, focus_ref binding and six trigger types

The part of Clawith worth reading closely is Aware, described as the agent's autonomous awareness system. Agents keep a structured working memory of Focus items with status markers: [ ] pending, [/] in progress, [x] completed. The binding rule is the interesting design decision. Every task-related trigger must have a corresponding Focus item, so the agent creates the focus first and then sets the trigger referencing it through focus_ref; when the focus completes, the agent cancels its triggers. That is a deliberate constraint against orphaned schedules, and it means the agent, not the operator, manages its own calendar. Six trigger types are documented: cron for recurring schedules, once for a single firing at a specific time, interval for every N minutes, poll for HTTP endpoint monitoring, on_message to wake when a specific agent or human replies, and webhook for external HTTP POST events from systems such as GitHub, Grafana or CI/CD. A Reflections view exposes the agent's reasoning during trigger-fired sessions with expandable tool call details. Whether that view is enough for debugging a misfiring trigger is not something the README answers.

Installing Clawith and running the first agent

The README gives a one-command setup. Cloning the repository and running setup.sh installs runtime dependencies, which the README estimates at about one minute, while the --dev flag also pulls in pytest and test tooling and takes roughly three minutes.

git clone https://github.com/dataelement/Clawith.git
cd Clawith
bash setup.sh         # Production: installs runtime dependencies only (~1 min)
bash setup.sh --dev   # Development: also installs pytest and test tools (~3 min)

According to the README, that script creates .env from .env.example, sets up PostgreSQL (using an existing instance if one is available, or downloading and starting a local one), installs backend dependencies into a Python venv, installs frontend packages with npm, and creates the database tables with seed data including a default company, templates and skills. If you want a specific database, the README says to create .env first and set DATABASE_URL, and its own example includes ssl=disable with the note that this prevents an asyncpg SSL negotiation hang in local development.

DATABASE_URL=postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable

Starting the stack is a second script. The README shows restart.sh and says the frontend comes up on http://localhost:3000.

bash restart.sh
# → Frontend: http://localhost:3000

Prerequisites are Python 3.12+, Node.js 20+, PostgreSQL 15+ (SQLite is offered for quick testing), a 2-core CPU with 4 GB RAM and 30 GB disk at minimum, and network access to LLM API endpoints. The README is explicit that Clawith runs no models locally: all inference goes to external providers such as OpenAI or Anthropic, and the local deployment is a standard web application with Docker orchestration. There is a hosted demo at try.clawith.ai which the README labels an open-source feature preview on a shared environment, not guaranteed stable, and a separate hosted service at cloud.clawith.ai. For a container-based path, docker-compose.yml defines postgres on postgres:15-alpine with user, password and database all set to clawith, redis on redis:7-alpine, and a backend built from ./backend that runs /app/entrypoint.sh.

Where Clawith will frustrate you: model IDs, secrets and sandbox timeouts

The .env.example carries a warning that is easy to skim past. Both multi-agent model IDs, MULTI_AGENT_PLANNING_MODEL_ID and MULTI_AGENT_COMPACT_MODEL_ID, must reference enabled platform models where llm_models.tenant_id IS NULL, and the comment states they never fall back to a business Agent model. If you configure only tenant-scoped models, the multi-agent runtime has nothing valid to point at. The same file ships SECRET_KEY and JWT_SECRET_KEY as change-me-in-production and change-me-jwt-secret, and docker-compose.yml repeats those as defaults, so an unedited deployment is running with published secrets. Sandboxed execution is bounded by SANDBOX_DEFAULT_TIMEOUT, defaulting to 180 seconds, and SANDBOX_MAX_TIMEOUT, defaulting to 300, which means a long build or data job inside an agent workspace will be cut off rather than allowed to finish. Concurrency is also capped: AGENT_RUNTIME_COMMAND_CONCURRENCY defaults to 10. The README does not document a rollback procedure for a bad agent action, and the approval workflow it mentions for flagging dangerous operations is described only at a feature level, so treat the safety net as something you will have to test against your own workloads.

Clawith compared with wiring agents together yourself

The obvious alternative is assembling the same behaviour from a general agent framework plus your own storage, scheduler and access control. Clawith's own README positions it against single-agent tools rather than naming a specific rival, and the difference is where the state lives. In a hand-rolled setup you choose the memory store, write the scheduler, and decide how agents authenticate to each other. Clawith ships those as product surfaces: Focus items with focus_ref binding, the six trigger types, the Plaza feed where agents post updates and comment on each other's work, per-agent Slack, Discord or Feishu/Lark bot identities, usage quotas with per-user message limits and LLM call caps, approval workflows, and audit logs with a knowledge base injected into context. The trade-off is the reverse of the usual one. A hand-rolled stack lets you swap any component; Clawith asks you to accept its org model, its database schema and its runtime. Self-evolving capability is part of that package: agents can discover and install new tools at runtime through Smithery and ModelScope, and create new skills for themselves or colleagues. That is convenient and also the feature most likely to need the approval workflow turned on.

Licence, maintenance and the cost of upgrading

Clawith is Apache-2.0, which permits commercial use and modification, but the README and LICENSE file are where you should confirm obligations such as attribution and notice retention rather than relying on a summary. Maintenance signals are mixed in a useful way. The repository is not archived, and the last push was on 2026-08-27. Releases are frequent and small: v1.11.4 and v1.11.4-fix.1 both landed on 2026-08-24, with v1.11.3 on 2026-07-28. The v1.11.4-fix.1 tag is labelled a runtime onboarding and verification hotfix, which tells you the maintainers patch the setup path quickly, and also that the onboarding path has needed patching. Upgrade cost concentrates in three places: database migrations run by the application against PostgreSQL, the .env surface, where a growing list of AGENT_RUNTIME_* keys controls session compaction, channel delivery retries and async tool polling, and the agent runtime itself, which is gated by AGENT_RUNTIME_V2_ENABLED, set to "true" in the compose file with AGENT_RUNTIME_V2_AGENT_IDS empty. Pinning to a release tag rather than tracking main is the lower-risk path given the cadence.

Editorial conclusion

Adopt Clawith if you want agents with durable identity, a shared org chart and human approval gates, and you accept that a full run needs PostgreSQL, Redis and Docker. Skip it if you only need a single scripted assistant, since the trigger, Plaza and RBAC layers add real operational weight. Before committing, verify three things yourself: that MULTI_AGENT_PLANNING_MODEL_ID and MULTI_AGENT_COMPACT_MODEL_ID point at platform models where llm_models.tenant_id IS NULL, that your SECRET_KEY and JWT_SECRET_KEY are no longer the change-me defaults, and that the sandbox timeout caps in SANDBOX_MAX_TIMEOUT match the longest command your agents are expected to run.

Frequently asked questions

Official sources

1. dataelement/Clawith on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases