Having recently begun an evaluation of CrewAI for orchestrating autonomous agents, my primary focus is on deploying such a system within a strictly controlled, air-gapped environment for processing sensitive data streams. This necessitates a purely local execution model, without any dependency on external API calls (e.g., to OpenAI, Anthropic, etc.).
My understanding from scanning the documentation is that CrewAI is architected to be LLM-agnostic, delegating the actual LLM calls to its underlying framework, LangChain. Therefore, the core question isn't specifically about CrewAI itself, but about configuring its LLM layer to operate locally.
I have successfully run a simple test crew using a local LLM via the `Ollama` integration. The configuration appears to hinge entirely on the `llm` parameter passed to the `Agent` and `Crew` objects. Here is a minimal, functional example that bypasses any external APIs:
```python
from crewai import Agent, Task, Crew, Process
from langchain_community.llms import Ollama
# Initialize the local LLM via Ollama, pointing to a model pulled locally
local_llm = Ollama(model="llama3.1")
# Define an agent using the local LLM
researcher = Agent(
role='Senior Research Analyst',
goal='Uncover groundbreaking technologies in distributed systems',
backstory="""A seasoned analyst with a keen eye for emergent patterns in stream processing.""",
verbose=True,
allow_delegation=False,
llm=local_llm # The critical local configuration
)
# Create a simple task
task = Task(
description="""Analyze the current trends in open-source stream processing frameworks post-2023.
Focus on performance characteristics under backpressure.""",
agent=researcher,
expected_output="A concise bulleted list of key insights."
)
# Assemble the crew
crew = Crew(
agents=[researcher],
tasks=[task],
process=Process.sequential,
verbose=2
)
# Execute locally
result = crew.kickoff()
print(result)
```
This leads me to a more nuanced set of questions for the community, based on my initial tinkering:
* **Tool Usage:** Many built-in tools (e.g., `SerperDevTool`, `ScrapeWebsiteTool`) are inherently API-dependent. Has anyone compiled a reliable set of truly local tools? For instance, using local HTTP clients for internal endpoints, or file system readers for local knowledge bases?
* **Embedding Models:** For tasks involving `RAG`-like behavior within a crew, the embedding model also needs to run locally. Are there established patterns for integrating, say, `sentence-transformers` models via `LangChain` into CrewAI agents?
* **Performance & Resource Monitoring:** When running multiple agents with substantial local LLMs, system resource contention becomes a real concern. What strategies or monitoring setups have you found effective for profiling crew execution in a local-only context?
* **Persistence:** Is the experience entirely ephemeral, or are there recommended approaches for persisting agent state, conversation history, or task outputs to a local database without cloud leakage?
I am particularly interested in the intersection of a locally-hosted CrewAI setup and event-driven architectures, where crews are triggered by messages from a local Kafka or RabbitMQ instance, process them using local models and tools, and emit results back to another local queue. Any shared experiences or pitfalls regarding such integrations would be invaluable.
testing all the things
throughput first
That's a great example and matches my own testing closely. I found that while the Ollama integration works for basic setups, you need to pay close attention to the model's context window when running longer, multi-step crew processes locally. The default settings in some local models can cause tasks to truncate unexpectedly if the chain of thought gets too long.
I'm also curious about the tooling aspect. Have you tried integrating local embedding models for any agent tasks that require semantic search or retrieval from private documents? I've been experimenting with the `llama3.1` embeddings via Ollama but haven't yet found a clean way to plug that into a CrewAI agent's toolkit without it wanting to fall back to an OpenAI call.