FAQ.

Common questions about Agent Manager, gathered in one place: setup, agent limits, model costs, network access, what happens when things break, and where to look next.

What is CrewMoot / Agent Manager?

CrewMoot is the product. Agent Manager is the engine that powers it — the self-hosted server you install and run. CrewMoot is the marketing site, the mobile companion, the documentation, the brand. When you actually run a crew, you run Agent Manager.

It's a self-hosted Kanban board where AI agents pick up tasks, do the work in their own branches, open pull requests for review, and stream their output. The boss agent watches the board around the clock. You sleep through the boring nights.

See Concepts for the moving parts.

Do I need my own API keys?

For self-hosted installs: yes. You bring keys to the model providers you want the crew to use. The keys live on your machine (encrypted at rest), and the crew uses them only to call the providers you configured. Nothing about your code or tasks is sent anywhere except to those providers, with those keys.

A managed cloud option will be available later for users who don't want to manage keys themselves. It's on the pricing page.

Which models and providers are supported?

Any provider that exposes an OpenAI-compatible API or a first-class SDK. That covers the major frontier labs, open-weight hosts, local inference servers (llama.cpp, Ollama, vLLM), and most niche upstarts.

You can mix providers per agent, and each agent carries its own fallback chain: the crew moves to the next model automatically when one dies or stalls. See Settings for how the chain is configured.

Is my code sent to a cloud?

Only to the model providers you configured, and only as part of the model call that needs context. There is no Agent Manager cloud, so there is no Agent Manager cloud receiving your code. The full breakdown is on Data & privacy.

If a model provider's terms matter to you, point the crew at one whose terms you trust — including a local one you run yourself.

How do agents coordinate without stepping on each other?

Every agent works in its own git worktree on its own branch. Two agents working the same repo can read and write concurrently because their working copies are physically separate. When an agent finishes, it commits and opens a pull request for review; the next agent either rebases onto the merged result or resolves conflicts as part of its own task.

The orchestrator assigns work so the same file isn't being edited by two lanes at once. When it can't avoid it, the conflict is surfaced as a task for a reviewer to resolve, not hidden. See Git & pull requests for the full branching model.

What happens when a model provider dies mid-task?

The agent's fallback chain kicks in. The provider is benched, the in-flight task resumes against the next model, and the crew keeps working. When the original provider comes back healthy, it rejoins the pool automatically — no operator action needed.

The reliability story is broader than that: heartbeats every 30 minutes, stuck tasks get reaped and restarted, and the crew only pages you for decisions that actually need a human. See Tasks for the runtime loop.

Is there a mobile app?

An Android companion app ships alongside the server, in early access alongside everything else. It mirrors the board, sends push notifications for escalations, and lets you reply to the inbox on the go.

An iOS build is on the roadmap. Until then, the iOS path is the mobile web UI in Safari.

Can it run non-coding work?

Yes. The same primitives — project, agent, task, board, inbox — apply to anything you can break into tasks. The site covers the four shapes we ship playbooks for: development, outbound sales, marketing, and customer service.

Under the hood, the difference is which integrations are connected and which tools the agents are given. The code-writing lane is just one toolset; swap it for a CRM, a content calendar, or a help-desk inbox and the crew runs that pipeline instead. See Integrations for the full list.

How much does it cost?

CrewMoot is in early access and there is a waitlist. No public pricing yet, but the rough shape is on the pricing page: three ways to run it, including a free self-hosted open-source path where you pay only for the model calls you make through your own provider keys.

During early access the team works directly with the first wave of users on shape and pricing. Joining the waitlist is the way to be in that conversation.

What are the self-hosting requirements?

The minimums the project is designed around:

• A modern Linux or macOS machine (also runs on Windows via WSL2).
• One binary plus a working directory. No database server to install — Agent Manager ships with an embedded store.
• Enough RAM and CPU to run the model providers you point it at. If you use local models, this is where the heavy lifting happens.
• Network access to the model providers you configured plus the integrations you connected. Nothing else.

Install steps ship with the public release. The default config runs comfortably on a laptop for personal use and on a small VM for a team.

Where do I go next?

• Concepts — the model in one read.
• Agents — how the team is structured and configured.
• Data & privacy — the full privacy story.