AutoGen code execution vs function calling explained

When building multi-agent systems with Microsoft’s AutoGen, the choice between autogen code execution vs function calling shapes your agent’s blast radius, latency profile, and debugging story. Both patterns let an LLM drive external actions, but they differ fundamentally in how the model expresses intent and how the framework executes it. This article compares them across concrete engineering dimensions so you can pick the right primitive.

How AutoGen runs code

AutoGen’s UserProxyAgent acts as the execution boundary. The LLM (typically an AssistantAgent) proposes either a block of Python or a structured tool call, and the proxy decides whether to run it.

The code execution path

With code_execution_config set, the assistant can emit a ```python block. The proxy executes it in a local process or Docker container, captures stdout, and feeds it back into the conversation.

from autogen import AssistantAgent, UserProxyAgent

assistant = AssistantAgent("assistant", llm_config={"model": "gpt-4o"})
user_proxy = UserProxyAgent(
    "user_proxy",
    code_execution_config={"work_dir": "coding", "use_docker": True},
)
user_proxy.initiate_chat(assistant, message="Compute the factorial of 10 and print it.")

The model can import libraries, write files, and chain computations across turns. If the code raises an exception, the traceback returns to the model, which can self-correct.

The function calling path

Function calling registers typed tools with the assistant’s llm_config. The model returns a JSON payload conforming to the schema; the proxy invokes the mapped Python function.

from autogen import AssistantAgent, UserProxyAgent

def get_weather(city: str) -> str:
    return f"Sunny in {city}"

assistant = AssistantAgent(
    "assistant",
    llm_config={
        "model": "gpt-4o",
        "functions": [
            {
                "name": "get_weather",
                "description": "Get weather for a city",
                "parameters": {
                    "type": "object",
                    "properties": {"city": {"type": "string"}},
                    "required": ["city"],
                },
            }
        ],
    },
)
user_proxy = UserProxyAgent(
    "user_proxy",
    code_execution_config=False,
    function_map={"get_weather": get_weather},
    human_input_mode="NEVER",
)

The framework serializes arguments, calls get_weather, and returns the result. No arbitrary code runs.

Capabilities: arbitrary compute vs constrained tools

Code execution gives the model a general-purpose Python runtime. It can pivot from pandas wrangling to matplotlib plotting to calling an undocumented internal API via requests. That flexibility is unmatched for open-ended data tasks.

Function calling restricts the agent to a fixed surface. You expose exactly get_weather, query_db, or send_slack. The model cannot invent new operations. For integrations with side effects (billing, email), that constraint is a feature.

The autogen code execution vs function calling debate often reduces to this: do you need the model to discover the algorithm at runtime, or do you need guaranteed invocation of vetted code?

Cost model: tokens, retries, and local compute

LLM cost is per-token. Code execution typically consumes more tokens because the model writes code, reads errors, and rewrites. A single analytical task can span 5–10 round trips. Local CPU for execution is essentially free but adds operational overhead if you sandbox with Docker.

Function calling usually resolves in one or two rounds. The schema adds a few hundred tokens of context per call, but the response is compact JSON. If you route AutoGen’s LLM traffic through a gateway such as n4n.ai, you get per-token metering across 240+ models and automatic fallback when a provider is rate-limited, which makes the multi-round code-execution cost visible and bounded.

Neither pattern charges for the execution itself beyond your infrastructure. The difference is purely how many times you hit the model.

Latency and throughput

Code execution latency = model generation + sandbox startup + run time + possible retry loops. Cold Docker starts can add 200–500ms; complex scripts can run seconds. Throughput suffers when many agents execute code concurrently on one host.

Function calling latency is dominated by a single model call plus your function’s runtime. There is no sandbox spin-up unless you build one inside the function. For high-QPS agents, function calling is the only sane default.

Ergonomics and developer experience

Code execution feels magical in a notebook. You don’t write schemas; you just prompt. Debugging is straightforward: the printed traceback shows exactly what broke. But you sacrifice type safety and static analysis. Tests are hard because the model generates the code.

Function calling demands upfront schema design. You must map JSON to Python types and handle validation. Tools like Pydantic help. The payoff is IDE autocomplete, unit tests on each tool, and predictable behavior. In a team setting, function calling scales; code execution does not without heavy guardrails.

Ecosystem and interoperability

Function calling aligns with the OpenAI tool-use spec, which Anthropic, Mistral, and others have adopted. AutoGen’s function schema is portable; you can reuse the same definition in a Rust service or a TypeScript lambda.

Code execution is AutoGen-centric. The IPython executor and Docker wrapper are framework features. If you later migrate to LangGraph or Semantic Kernel, your “agent that writes Python” must be reimplemented, whereas registered functions travel with you.

Limits and security boundaries

Code execution is the bigger risk. Even with Docker, a determined prompt injection can attempt network exfiltration or resource exhaustion. You must cap memory, disable network, or use gVisor. Non-determinism makes audits painful.

Function calling limits are syntactic: the model can only call what you registered. It cannot read arbitrary files or loop forever unless you wrote a tool that does. The attack surface is your function code, which you control.

Head-to-head summary

Which to choose

The autogen code execution vs function calling decision should follow your deployment context, not ideology.

Prototyping data pipelines

Use code execution. When you’re exploring a CSV or proving a concept, letting the model write pandas code saves hours. Restrict use_docker=True and work_dir to a temp volume.

Production API integrations

Use function calling. Payment, CRM, or internal RPC calls must be deterministic and observable. Register narrow tools with strict Pydantic models.

Untrusted or multi-tenant inputs

Function calling only. Never expose a code interpreter to end-user prompts without a fortified sandbox. Even then, prefer vetted tools.

Hybrid approach

Many production AutoGen systems use both: function calling for safe external actions, code execution for local post-processing inside a locked container. Define a run_analysis function that itself triggers a code executor with predefined scripts, keeping the model’s free-form output inside a boundary.

Pick the primitive that matches the trust level of your input and the rigidity your system needs. The framework supports both; your architecture should not pretend they are interchangeable.