Contents
In brief
Python CrewAI is convenient for teams of agents, but it pulls a heavy dependency stack and slow cold starts. The author published crewai-go — an idiomatic Go port built on net/http, encoding/json, and log/slog — and walks a side-by-side “research → write” example.
What happened
In Python you assemble Agent, Task, and Crew with a sequential process. In Go the same roles appear: researcher and writer, tasks with explicit WithContext instead of implicit magic, and Kickoff returning the final text. The surface looks familiar; the runtime does not: a single binary, millisecond cold start, roughly 10–20 MB of memory, thread safety, and a high test-coverage gate.
The repo claims sequential, hierarchical, and staged processes, an optional plan–execute–evaluate–refine loop, web search, and structured output with a JSON Schema repair loop — all on the standard library. An offline example runs with a mock model and no API key.
Why it matters
Agent orchestration often fails on delivery cost, not on a clever prompt: containers, cold start, dependency weight. A Go port does not retire the Python ecosystem, but it shows that the “team of specialists” contract can live in a lean binary if you accept writing integrations yourself.
In practice
- If CrewAI deploys ballooned on transitive packages, measure cold start and RSS before changing stacks.
- When porting, keep task dependencies explicit — Go makes them visible in code.
- Turn on the race detector and a hard coverage floor in CI; the author treats ~90% as a gate.
- Use the offline mock-LLM example to test orchestration without API spend.
- Do not expect litellm/langchain parity out of the box — score the surface you actually need.
Takeaway
crewai-go is a pragmatic answer to a heavy Python stack: the same agent-and-crew ideas, a different launch economy. Worth a look if you already ship Go and want orchestration without a dependency zoo.