How to make Muilt-Agent Apps with smolagents

Multi-agent apps built with smolagents work best when the system leans on tool-calling and strong hosted models—small local “code agents” tend to waste tokens and stumble, while managed tool workflows can reliably complete multi-step tasks.

The walkthrough starts with baseline agent types. A standard code agent can call a hosted Hugging Face model, but it requires a Hugging Face token in environment variables and may only be practical on paid tiers for larger models like “Llama 3.3 70b.” When the agent is asked to do simple work, it can respond quickly, but performance changes sharply once tools enter the picture. Tool-calling agents are positioned as the safer default for structured outputs (often JSON-like), because they can invoke specific tools and then use the returned observations.

Local execution via Ollama highlights the tradeoff. Running tool-calling with Ollama can work—especially with a small model like “llama 3.2 3B” or “Qwen2.5 Coder 7B”—but the system often needs multiple tool/observation steps to reach an answer. That increases token churn and can lead to “wandering” behavior. The transcript is blunt that code agents with smaller models are not consistently reliable; they may churn through elaborate intermediate text and still fail to land cleanly. The practical takeaway: small models can handle simple tool use, but code-agent-style multi-step reasoning is much more fragile unless the model is larger or fine-tuned on function-calling examples.

Switching to proprietary models changes the picture. Claude (noted as an older “3.5” variant) handles code-agent workflows more smoothly, completing search → gather information → synthesize an answer with fewer issues. Gemini Flash can manage tool-calling well, but it’s described as weaker on code-agent tasks, sometimes stumbling before producing a final decision. Across these comparisons, the pattern is consistent: tool agents are robust; code agents are model-sensitive.

The next major capability is turning agents into quick UIs with Gradio. A text-to-image tool is wrapped and launched through Gradio, with “trust_remote_code=True” required for these tools. The agent can decide when to call an image generator tool (e.g., generating “a cat riding a horse”), then return the result to the interface. This makes it straightforward to build small interactive apps where the model selects tools and the UI renders outputs.

From there, the transcript moves into multi-agent construction. Tools are treated as the building blocks, but creating custom tools is “fussy”: decorated tools require precise argument typing and exact parameter naming (e.g., using “args” rather than “parameters”). For multi-agent orchestration, a “managed agent” wraps a tool-calling agent with a name and description, and a “manager agent” (a code agent) directs which managed agents to run and how to chain their outputs.

Two multi-agent examples show the payoff. A “movie + Rotten Tomatoes score” workflow uses a web search/scrape agent to find a film released in 1955 starring James Dean, then scrapes Rotten Tomatoes to compute the final score (93%). A more advanced “blog writer” pipeline adds multiple specialized agents: a research agent (web search + scraping), a research checker (no tools, just relevance validation), a writer, and a copy editor. For a prompt like “top five products released at CES 2025 so far,” the system performs multiple scrapes, drafts the blog post, then polishes it—while still depending heavily on tool quality and model strength.

Overall, the guidance is clear: multi-agent apps become dependable when the orchestration is tool-first, the models are strong enough for planning, and custom tools are built carefully for consistent structured inputs/outputs.