CrewAI vs Microsoft Semantic Kernel: a hands-on comparison

CrewAI vs Semantic Kernel is the comparison most teams land on when they need structured multi-agent workflows without building their own orchestration loop. Both wrap LLM calls, tools, and memory, but they diverge sharply in execution model, language support, and operational assumptions.

Capabilities and execution model

CrewAI models the problem as a crew of role-playing agents that pass tasks along a defined topology. Semantic Kernel treats LLM calls as invocable functions inside a kernel, with optional planner-driven composition. That single philosophical split dictates everything else.

CrewAI’s agent-first model

You declare agents with roles, goals, and backstories. Tasks bind to agents, and the crew runs them sequentially or hierarchically.

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Researcher",
    goal="Extract key facts from docs",
    backstory="Senior analyst",
    llm="gpt-4o-mini",
    verbose=True
)
writer = Agent(
    role="Writer",
    goal="Draft summary",
    backstory="Tech writer",
    llm="gpt-4o-mini"
)
task1 = Task(description="Read the file and pull metrics", agent=researcher)
task2 = Task(description="Write report from metrics", agent=writer)
crew = Crew(agents=[researcher, writer], tasks=[task1, task2])
result = crew.kickoff()

CrewAI ships with short-term and long-term memory, task output artifacts, and a delegation mechanism where an agent can ask another agent to act. The mental model is theatrical: each agent stays in character.

Semantic Kernel’s function-first model

You register plugins (native classes or prompt templates), then invoke them directly or let a planner sequence them.

import asyncio
from semantic_kernel import Kernel
from semantic_kernel.functions import kernel_function

class DocPlugin:
    @kernel_function(name="extract", description="Extract facts from text")
    def extract(self, text: str) -> str:
        return text[:200]  # stub implementation

kernel = Kernel()
kernel.add_plugin(DocPlugin(), plugin_name="docs")

async def run():
    res = await kernel.invoke_async(
        kernel.plugins["docs"]["extract"], text="long technical document"
    )
    print(res)

asyncio.run(run())

SK’s newer ChatCompletionAgent adds stateful conversation, but the core remains function orchestration. The FunctionCallingStepwisePlanner can generate a multi-step plan at runtime—powerful, but non-deterministic. CrewAI prescribes topology; SK gives you primitives.

Cost model and metering

Both frameworks are MIT-licensed open source. There is no seat fee. Your only direct cost is LLM tokens.

CrewAI’s higher-level loops can silently multiply token usage: each agent re-sends its constructed system prompt and relevant memory on every task. If you do not trim memory, a five-agent crew processing 10 tasks can easily issue 50+ completions. Semantic Kernel’s explicit function calls keep payloads tighter, but planner invocations add an extra planning completion plus per-step re-planning tokens.

If you route either framework at an OpenAI-compatible gateway such as n4n.ai, you get per-token usage metering and automatic fallback when a provider is rate-limited, without changing framework code. That matters when a crew burns through a single provider’s quota mid-run.

Latency and throughput

CrewAI’s default sequential crew executes one task per agent at a time. A three-agent linear crew with 2k-token prompts and 1k-token completions typically adds 3–5 seconds per step on a fast model; framework overhead is sub-100ms. Parallel crews exist via process="parallel", but state isolation is on you.

Semantic Kernel’s direct function invocation adds minimal latency beyond the model call. Enabling a stepwise planner pays for an initial planning completion (often 500–1k tokens) and re-planning each step. Throughput is bounded by your LLM tier, not the SDK.

In practice: CrewAI feels slower when many agents handshake; SK feels slower when the planner overthinks a trivial task.

Ergonomics and developer experience

CrewAI reads like a screenplay. You declare roles, kick off, and inspect the returned string. Debugging is easy until agents delegate—then you need verbose=True and log tracing.

Semantic Kernel demands scaffolding: kernel construction, plugin registration, argument serialization. C# users get strong typing and DI integration; Python users get a leaner but still verbose API. The trade-off is control. You pin exact function signatures and avoid prompt drift.

For a Python-only startup, CrewAI reaches a demo in an hour. For a .NET backend team, Semantic Kernel slots into existing services with familiar patterns.

Ecosystem and integrations

CrewAI has crewai_tools, LangChain-compatible adapters, and a hosted observability platform. It is Python-centric; non-Python shops must wrap it in a microservice.

Semantic Kernel is backed by Microsoft. It ships connectors for Azure OpenAI, Microsoft Graph, Bing, and Cosmos DB. Official C#, Python, and Java SDKs exist. If your stack is Azure-native, SK removes integration glue.

Limits and sharp edges

CrewAI’s abstraction hides the exact prompt sent to the model. Override system_template if you need compliance auditing. Its memory can leak context across tasks if not explicitly cleared. Hierarchical crews add a manager agent that occasionally loops on ambiguous goals.

Semantic Kernel’s agent APIs are younger and version churn is real between minor releases. The planner may emit calls to unregistered functions if plugin names drift. Kernel invocation errors are sometimes wrapped generically, obscuring the root cause.

Comparison table

Which to choose

Choose CrewAI if: you are building a Python service that needs several specialized agents collaborating on unstructured tasks—research synthesis, content pipelines, mock interviews. You want minimal code and can tolerate prompt opacity.

Choose Semantic Kernel if: your team lives in .NET or Java, you need Azure-native connectors, or you require explicit function signatures and typed inputs. Use it when the workflow is better expressed as composable functions than as role-play.

Choose neither (build raw) if: you need sub-100ms loops or full control over every token. Both add overhead you may not need for a single-shot classifier.

If you must support many models and avoid vendor lock-in, point either framework at a single OpenAI-compatible endpoint that fronts 240+ models and honors cache-control hints; the framework code stays identical while your routing gains resilience.