# IntentKit: A Self-Hosted Cloud Agent Cluster for Collaborative AI Automation

> IntentKit is an open-source, MIT-licensed Python 3.13 platform that deploys a cloud-native team of AI agents as a persistent web service, with FastAPI, LangChain, PostgreSQL, and Redis as its core infrastructure. The last push was on 2026-09-16, and the latest release is v2.6.3 from 2026-06-14.

**crestalnetwork/intentkit** — IntentKit is an open-source, self-hosted cloud agent cluster that manages a collaborative team of AI agents for you.

- Repository: https://github.com/crestalnetwork/intentkit
- Website: https://intentcat.com/docs
- Stars: 6,514 · Forks: 712
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/crestalnetwork-intentkit

## The cloud-native versus local-first split in AI agents

IntentKit frames itself against two patterns of AI agent deployment. The README contrasts cloud-native agents with local-first tools, noting that local-first agents often require expensive hardware and extensive local permissions. Cloud-native agents, by contrast, run in a hosted environment, consume minimal resources on the user's machine, and remain available regardless of whether any client application is running.

IntentKit implements the cloud-native path. Once deployed, agents live as persistent processes on a server. They respond to API calls, webhook events from social platforms, and messages from other agents in the cluster. The operator's machine is not involved in agent execution after deployment. This architecture makes it practical to run agents continuously without leaving a laptop or workstation powered on and connected.

The platform is designed for self-hosting. The README calls it a cloud agent cluster that the operator manages, rather than a managed SaaS offering. This means the reliability of the agents is the operator's responsibility, including the availability of the PostgreSQL database, the Redis cache, and the rustfs object storage that the stack depends on.

## Multi-agent collaboration: how agents call each other

The README lists collaborative AI as a core feature, describing it as "multiple agents that can call and interact with each other." This is the defining structural difference from single-agent setups. An orchestrator agent can delegate subtasks to specialist agents, and each specialist can call further agents or external APIs.

All inter-agent communication goes through the API layer rather than through direct function calls. This means agents run independently and can be updated, scaled, or replaced without affecting the agents that call them, as long as the API contract is preserved. The architecture is similar to a microservice model applied to AI agent logic.

The .env.example file includes configuration for multiple LLM providers: OPENROUTER_API_KEY, OPENAI_API_KEY, DEEPSEEK_API_KEY, XAI_API_KEY, GOOGLE_API_KEY, MINIMAX_PLAN_API_KEY, and MIMO_PLAN_API_KEY. Different agents in the same cluster can use different provider keys and models, which allows mixing a fast and cheap model for routine dispatch tasks with a more capable model for reasoning-intensive work. Google Vertex AI support is configured separately with GOOGLE_GENAI_USE_VERTEXAI and GOOGLE_CLOUD_PROJECT. Both OpenAI-compatible and Anthropic-compatible provider endpoints are also configurable.

## Deploying IntentKit with Docker Compose

The standard deployment path uses the included docker-compose.yml. Starting the stack brings up four services:

```bash
docker compose up -d
```

The database service uses `postgres:18.1-trixie`. The object storage service uses `rustfs/rustfs:latest`, which exposes an S3-compatible API on port 9000 and a console on port 9001 with default credentials `minioadmin/minioadmin`. The cache service uses `redis:8.4-bookworm`. The API service is built from the included Dockerfile and starts with uvicorn on port 80.

Database schema migrations run automatically at startup. The .env.example includes `DB_AUTO_MIGRATE=true`, which triggers Alembic to apply any pending migrations before the API begins accepting requests. This removes a manual migration step from the deployment process but means the database schema changes every time a new version is deployed.

The .env.example documents all required configuration. Critical fields include the LLM provider API keys, the APP_DOMAIN for a production deployment, and TLS_EMAIL for Let's Encrypt certificate provisioning. The file also shows optional BASIC_AUTH_USER and BASIC_AUTH_PASSWORD for protecting the web UI with HTTP basic authentication. For a local development environment, most fields can remain empty; only at least one LLM provider key is required.

## The Python 3.13 requirement and what it means for deployment

The pyproject.toml declares `requires-python = '==3.13.*'`. This is an equality constraint: Python 3.12 or 3.14 will not satisfy it. The Dockerfile confirms the version: `FROM python:3.13-slim AS builder`. The dependency lockfile uv.lock is pinned to this version as well.

This constraint is stricter than most Python projects, which use >= bounds. Operators running IntentKit on shared infrastructure need to confirm that Python 3.13 is available. The build stage uses uv for dependency installation, copying `pyproject.toml` and `uv.lock` before the source code to take advantage of Docker layer caching. uv is pulled from the `ghcr.io/astral-sh/uv:latest` image in the Dockerfile.

The key dependencies include FastAPI 0.115.8 or later, LangChain 1.3, LangChain-OpenAI 1.2, SQLAlchemy 2.0 with asyncio, Alembic 1.14, psycopg 3.2.9 for PostgreSQL, redis 8.0.1, and httpx 0.28.1. Both httpx and httpx2 are present because the MCP client library and certain provider SDKs use the newer HTTP stack while the main application code stays on the original.

## The skill system, social integrations, and Web3 support

IntentKit uses an extensible skill system to add capabilities to agents. Skills are described in the README as something that can be added incrementally. Social media integration is listed as a built-in capability, and the .env.example confirms webhook endpoint paths for Slack and Lark: the API base URL is appended with `/slack/events` and `/lark/events` for those services. WeChat integration is also present with an optional WECHAT_BASE_URL environment variable.

Web3 and blockchain integrations are listed as optional. The README describes them as "crypto-friendly" but does not mandate their use. Operators who do not need blockchain functionality can ignore those configuration options.

Beyond operating the deployed service, the README documents two additional usage modes. The platform can be imported as a Python library, allowing developers to add agent cluster capabilities to existing applications without running a full deployment. It can also be accessed through its REST API from any external application, regardless of how it was deployed.

## Security model: agent isolation from operator secrets

The README states that agents are "fundamentally unable to access any of your secret keys." This is framed as a design guarantee rather than a configuration option. The agent execution environment is isolated from the API keys and credentials that the operator stores in the .env file.

This matters for use cases where agents interact with third parties on behalf of users. An agent that can compose and send messages via Slack or Lark cannot read the API keys used to authenticate those requests; only the IntentKit platform itself has access to those credentials. The practical limitation is that this guarantee is only as strong as the operator's deployment security: if the host running the Docker containers is compromised, the secrets in the .env file are accessible.

The project does not currently accept pull requests to the codebase. The README states this explicitly, attributing it to the rapid pace of AI development. Feature requests and bug reports submitted through GitHub Issues are described as the best way to contribute. This policy has a direct implication for teams planning to extend IntentKit: customizations must be maintained as a fork, because the main repository will not merge them.

## CrewAI as a code-first alternative for agent orchestration

CrewAI is a Python framework for defining and running multi-agent AI workflows in code. It represents a different architectural approach from IntentKit. CrewAI applications run as Python processes triggered by the developer or by a scheduler; there is no persistent deployed service in the default setup. Agents and their tasks are defined in code, which means the full agent logic lives in version control and runs wherever Python runs.

IntentKit is a persistent service. Agents run continuously on a server, respond to webhooks, and call each other through the API layer. The deployment model requires operating a multi-container Docker stack. CrewAI requires only a Python environment and provider API keys.

The practical tradeoff is operational simplicity versus deployment independence. A team building agents that need to respond to real-time social media events or run at unpredictable times will find IntentKit's always-on architecture more suitable. A team building agents that run on a known schedule or in response to developer-triggered actions will find CrewAI's code-first model lower in operational overhead.

## Conclusion

IntentKit is the right choice for teams that need persistent, cloud-hosted AI agents that can interact with social platforms, optional Web3 integrations, and external APIs, and who are prepared to run PostgreSQL, Redis, and rustfs as part of their infrastructure. The Python 3.13 requirement is strict: the pyproject.toml specifies `requires-python = '==3.13.*'`, so environments running a different Python major or minor version will fail at setup. Teams that prefer to develop agent logic in code rather than operate a deployed service should evaluate a library-first framework. Any team relying on community contributions to the IntentKit codebase should note that the project does not currently accept pull requests; changes must be proposed through GitHub Issues.

## FAQ

### What Python version does IntentKit require?

IntentKit requires Python 3.13 exactly. The pyproject.toml declares requires-python = '==3.13.*', and the Docker build uses python:3.13-slim. Python 3.12 and 3.14 will not satisfy the constraint.

### Can IntentKit be used without running the full Docker Compose stack?

Yes. The README documents two alternatives to the full deployment: importing IntentKit as a Python library to add agent cluster capabilities to an existing application, or accessing a deployed instance through its REST API from an external application.

### Does IntentKit accept code contributions from the community?

Not currently through pull requests. The README states that code contributions via pull requests are not accepted at this time due to the rapid pace of AI development. The recommended way to contribute is by submitting feature requests and bug reports through GitHub Issues.

## Sources

- [crestalnetwork/intentkit on GitHub](https://github.com/crestalnetwork/intentkit)
- [License: MIT](https://github.com/crestalnetwork/intentkit/blob/main/LICENSE)
- [Project website](https://intentcat.com/docs)
- [README](https://github.com/crestalnetwork/intentkit/blob/main/README.md)
- [Releases](https://github.com/crestalnetwork/intentkit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crestalnetwork-intentkit