How to Install CrewAI Locally With Ollama

Tool overview

CrewAI is a Python framework for building teams of AI agents. Instead of one assistant doing everything, you define agents with roles, goals, backstories, tools, and tasks, then run them together as a crew.

It is useful for workflows such as research, planning, extraction, content operations, QA, and multi-step analysis where separate specialist agents make the structure easier to reason about.

Step-by-step setup

python --version

ollama pull llama3.2
curl http://localhost:11434/v1/models

Step 1: Install CrewAI

Install uv:

curl -LsSf https://astral.sh/uv/install.sh | sh

On Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Install the CrewAI CLI:

uv tool install crewai

If your shell warns that the tool path is not available, run:

uv tool update-shell

Then restart the terminal and check:

uv tool list

Step 2: Create a CrewAI project

Generate a new project:

crewai create crew local_research_crew
cd local_research_crew

Install the project dependencies:

crewai install

The generated project gives you a structured layout with files for agents, tasks, tools, and the main execution flow. This is better than starting with one loose script because agent projects become messy quickly.

Step 3: Connect CrewAI to Ollama

Make sure Ollama is running:

ollama list
curl http://localhost:11434/v1/models

Then configure CrewAI with an OpenAI-compatible local endpoint:

from crewai import LLM

local_llm = LLM(
    model="openai/llama3.2",
    base_url="http://localhost:11434/v1",
    api_key="ollama",
    temperature=0.2,
    timeout=120,
)

The openai/ prefix tells CrewAI to use OpenAI-compatible mode. Ollama provides the local endpoint at /v1, and the API key can be a placeholder because Ollama does not require a real key by default.

Step 4: Define agents with roles, goals, and backstories

A basic local crew might have a researcher and a writer:

from crewai import Agent, Task, Crew, Process, LLM

local_llm = LLM(
    model="openai/llama3.2",
    base_url="http://localhost:11434/v1",
    api_key="ollama",
    temperature=0.2,
)

researcher = Agent(
    role="Research Analyst",
    goal="Find the most relevant practical points for the assigned topic.",
    backstory="You are careful, concise, and skeptical of weak claims.",
    llm=local_llm,
    verbose=True,
)

writer = Agent(
    role="Technical Writer",
    goal="Turn research notes into a clear, useful explanation.",
    backstory="You write plain English and avoid hype.",
    llm=local_llm,
    verbose=True,
)

Good roles are specific. A vague "AI expert" agent is less useful than a "research analyst who finds setup risks" or a "QA reviewer who checks missing commands."

Step 5: Define tasks and run the crew

Add tasks:

research_task = Task(
    description="Research the local setup requirements for Open WebUI with Ollama.",
    expected_output="A concise checklist of installation steps and common errors.",
    agent=researcher,
)

writing_task = Task(
    description="Write a practical setup summary from the research checklist.",
    expected_output="A short guide with commands and troubleshooting notes.",
    agent=writer,
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff()
print(result)

Run the script from your project environment, or use the generated CrewAI project entry point:

crewai run

Step 6: Keep the first local crew small

Do not start with five agents, web browsing, tools, memory, and long documents. Local models can become slow or unstable when too many agents call the model in sequence.

Start with:

• Two agents
• Sequential process
• No tools
• Short task descriptions
• Clear expected outputs
• Low temperature

Then add tools, files, memory, and more agents after the basic loop works.

Step 7: Add tools carefully

CrewAI can use tools, but local models are more likely to produce malformed tool arguments than strong hosted models. When using local models:

• Prefer simple tools with narrow inputs.
• Use explicit expected output formats.
• Avoid deeply nested JSON schemas at first.
• Keep timeouts high enough for local inference.
• Watch logs for repeated failed tool calls.

If tool calling fails repeatedly, test the same task without tools. If the agent still fails, the model or task definition is the problem, not the tool.

Common problems

CrewAI is not found after installation

Run:

uv tool list
uv tool update-shell

Restart the terminal and try again.

Ollama connection fails

Check:

curl http://localhost:11434/v1/models

If CrewAI runs in a container or remote environment, localhost may point to that environment instead of your Ollama host. Use a reachable host address.

Agents loop or repeat themselves

Use a stronger model, reduce the number of agents, lower temperature, shorten the task, and make the expected output more concrete.

Tool calls fail with JSON errors

Use fewer tools, simpler schemas, and a model that follows structured output reliably. Local small models often fail here.

Windows dependency errors appear during install

Some Python dependencies may require build tools on Windows. Install Visual Studio Build Tools with the C++ workload if a compiled dependency fails.

Security notes

CrewAI agents can be connected to tools that read files, call APIs, or modify systems. Local does not automatically mean safe.

Use these rules:

• Keep API keys out of committed files.
• Do not give broad file access to experimental crews.
• Start with read-only tools.
• Log runs while debugging.
• Avoid connecting personal directories to untested agents.
• Review tool behavior before using automation on real projects.

Questions to ask before installing

• Do your agents need local-only behavior, or do you need cloud fallbacks?
• What files, repos, or APIs can agents read and write during phase 1?
• Are tasks deterministic enough to run with a small number of agents first?
• Do you need managed orchestration for reliability, or is local control preferred?
• What is your recovery path if an automation task edits the wrong artifact?

Approximate U.S. planning cost

• Software cost: CrewAI and Python tooling can run locally with open-source components.
• Local hardware cost: model inference, retrieval indexes, and long task chains can be resource intensive; plan for memory and disk accordingly.
• API-token spend: any external LLM or tool endpoint (OpenAI, Anthropic, Azure, etc.) adds token costs.
• Paid plans: provider plans are usage-based or subscription-based depending on endpoint. CrewAI also has managed deployment paths for teams.
• VPS/managed service option: managed CrewAI AMP or self-hosted Factory options can shift you from local operation to dedicated infrastructure.

For current pricing and platform options, check:

• OpenAI API: https://platform.openai.com/docs/pricing
• Anthropic API: https://www.anthropic.com/pricing
• CrewAI managed deployment options: https://docs.crewai.com/enterprise/introduction
• Ollama local mode (no per-call cloud cost): https://docs.ollama.com/faq

Cost breakdown

• One-time cost: local setup, model downloads, and environment bootstrap.
• Recurring cost: API calls, model usage in production, hosting if running on managed infrastructure.
• Risk cost: poor tool schemas or weak models that cause retries, loops, and failed runs.

Trust boundaries

• Task boundary: define what each agent can do and cannot do before adding tools.
• Tool boundary: only enable one tool at a time when validating a new role.
• Data boundary: lock down tool input/output paths and credentials.
• Runtime boundary: isolate local and remote execution contexts so one failing environment cannot reach another.

Workspace and file-system permissions

• Keep crew working directories explicit and versioned.
• Do not run crews directly in shared production trees without staging copies.
• Give write permissions only to expected folders.
• Keep .env and secret files outside any agent write path.

Key and secret management

• Keep provider keys in environment files loaded at runtime or a secrets manager.
• Never commit API keys or tool credentials.
• Rotate keys after role changes and after demos or experiments.
• Revoke keys that can access broad model or storage scopes.

Red flags

• A crew definition that can invoke many tools without explicit expected outputs.
• No guardrails in task definitions (clear scope, success criteria, stop conditions).
• Large n agent counts from day one.
• Reusing the same credentials across many crews and environments.
• Missing logging or no evidence of tool-call outputs.

Rollback and update guidance

Rollback:

1. Stop the running crew.
2. Remove or disable risky tool hooks.
3. Revert to the last known-good commit.
4. Re-run crewai install and uv tool update-shell only after the issue is fixed.

Update guidance:

• Update crewai CLI and project dependencies in separate steps.
• Pin versions where reproducibility matters.
• Validate each change with a small crew run before scaling back to long tasks.

Bottom line

Install CrewAI with uv, create a structured crew project, connect Ollama through http://localhost:11434/v1, and start with a two-agent sequential workflow. CrewAI is powerful locally, but local multi-agent reliability depends heavily on model quality, task clarity, and restraint.