Hugging Face Lets Agents Write Python—Who Gets the Keys?

Python becomes the action

Hugging Face’s smolagents puts a consequential choice inside a small Python library: an AI agent can write executable code to perform its next action. Instead of asking for a function call, receiving a result and asking for another call, it can express a sequence of operations as a program. That changes what builders need to inspect before handing an agent useful work.

This is an existing tool worth understanding on November 7, 2026, rather than a launch being dressed up as breaking news. Hugging Face introduced smolagents on December 31, 2024. Its central distinction remains practical: Python can represent loops, intermediate values and combinations of tools directly. The agent is using code to act, which is different from a coding assistant that merely returns a script for someone else to run. Hugging Face’s introduction explains that design.

Consider a hypothetical supplier-research assistant. It must look up several vendors, extract delivery estimates, convert the estimates into a common unit and rank the results. A code action can represent the iteration and arithmetic together. The attraction is obvious to anyone who has spent an afternoon assembling little tool responses into something a program could have expressed in a few lines.

The uncomfortable question arrives immediately afterward: which functions, files and credentials does that generated program inherit? A compact agent loop does not make the surrounding permissions compact. The useful evaluation starts at that boundary.

A loop is a different kind of permission

Hugging Face defines agents in terms of control: the language model’s output determines the workflow. Its conceptual guide distinguishes choosing a branch, choosing a function and controlling repeated execution. That is a more useful starting point than a mascot, a chat window or a claim that software now has employees. The agent guide describes the progression.

For the supplier example, a fixed workflow might always fetch three records, normalize three fields and calculate a ranking. An agent could decide that one supplier needs another search, that a result is ambiguous or that the task is complete. Those decisions can make messy work easier. They also introduce paths the application developer did not explicitly enumerate.

Our recommendation is to write down the decisions that require judgment before adopting the loop. If the only flexible step is extracting a delivery date from prose, keep that step narrow. If the system must choose unfamiliar sources and revise its investigation based on what it finds, broader control may earn its place. Agency should solve a named failure in the existing workflow.

A useful design review therefore asks what happens after an unexpected result. Does the application stop, ask a person, repeat the operation or choose another tool? If every answer is already known, ordinary application code may be easier to maintain. The extra freedom deserves a job description.

The appeal is composition, not magic

The smolagents repository identifies CodeAgent as an agent that writes its actions in code. It also lists support for sandboxed execution using services including E2B, Modal and Blaxel, alongside Docker. The project is available under Apache 2.0. Those are concrete implementation choices, not evidence that every workflow benefits from generated Python. The official repository is the place to inspect the available components.

Composition is the interesting part. In our hypothetical supplier task, the output of a lookup can become the input to a parser, then a calculation, then a sorting operation. Developers can reason about those operations as a program. They can also ask whether a purpose-built function would express the whole job more reliably.

There is no automatic speed dividend here. Combining operations could reduce trips back to a language model, but execution time still depends on the work performed. A loop that makes unnecessary requests remains unnecessary work. Generated code can be elegant and still choose a bad research strategy.

Treat any efficiency claim as a hypothesis for your workload. Compare a fixed implementation, an agent using individual tool calls and an agent writing code. Give them the same information and judge the same output. Without that comparison, a satisfying execution trace is mostly theatre with indentation.

The execution environment is part of the product

Hugging Face’s security documentation explicitly warns that CodeAgent runs generated code in the local environment by default. It identifies accidental harmful code, malicious instructions in retrieved material and misuse of publicly accessible agents as risks. It also cautions that no proposed execution arrangement is free of risk. These are the project’s own qualifications, not an accusation of a newly discovered vulnerability. The secure execution guide sets out the tradeoffs.

For a builder, the implication is straightforward: choose the execution environment before connecting valuable data. Our recommended first prototype gets a disposable directory, synthetic inputs and narrowly scoped tools. It should have enough access to demonstrate the workflow and little else. That makes failures easier to understand and limits the consequences of a mistaken operation.

Moving execution elsewhere does not finish the design. Suppose a remote environment has no access to your laptop, but one supplied tool can export every customer record. The tool still carries that authority. Review the capabilities exposed by functions as carefully as the interpreter running the generated code.

In the supplier example, a lookup function could accept a vendor identifier and return a small record. It need not accept an arbitrary database query or return an entire procurement table. Keeping the interface specific gives the agent less room to misunderstand the task and gives the developer a clearer contract to enforce.

We would also separate research from consequential action. An assistant can prepare a proposed supplier order with supporting evidence; application code can validate it before a person approves submission. That division lets the agent handle ambiguity while the purchasing system retains explicit rules about what becomes an order.

Count the cost of an acceptable answer

Apache 2.0 is a software license, not an all-inclusive operating bill. Deploying an agent still involves inference, execution infrastructure and whatever external services its tools use. There is no single smolagents price that tells you what the supplier assistant will cost. The architecture and workload determine the bill.

The useful accounting unit is an acceptable completed task. In our example, that means a ranking whose delivery estimates match the underlying records and whose assumptions are visible. A cheap response that requires a buyer to repeat the research has shifted work onto someone else. Record that review burden alongside the machine costs.

For a pilot, we would log inference usage, tool requests, execution duration and the reason a run stopped. Set budgets before evaluating the output. Otherwise, a system allowed to keep searching indefinitely can appear more capable than one required to finish within an application’s real operating limits.

Failures deserve separate labels. A lookup might return unavailable data; the agent might misinterpret a valid record; the generated calculation might be wrong; the final explanation might overstate the evidence. Those need different fixes. Buying a more expensive language model for every failure is an unusually convenient diagnosis for the seller.

Keep the comparison honest about scope, too. If the fixed workflow handles only clean records while the agent gets ambiguous ones, aggregate success rates tell you little. Use the same cases, preserve the inputs and inspect disagreements. We are proposing an evaluation method here, not reporting a measured smolagents performance advantage.

Give the pilot a job it can fail visibly

A sensible first assignment has a checkable outcome and reversible consequences. For the supplier assistant, use saved records with known delivery estimates and include deliberately awkward cases: missing dates, conflicting units and two vendors with similar names. Ask for the ranking, the evidence behind it and an explicit statement when a comparison cannot be supported.

Decide the acceptance criteria before running the agent. It should preserve vendor identity, calculate consistently and avoid filling gaps with confident guesses. A response that admits insufficient evidence may be more useful than a complete-looking table. The product needs a way to represent that state without treating it as a crash.

Then introduce one failure at a time. Make a lookup unavailable. Return a record with an unexpected field. Include irrelevant instructions inside a supplier description and check whether they influence the workflow. These are proposed checks for your integration; they should not be confused with allegations about an incident involving the library.

Inspect the execution trace when the answer is correct as well as when it fails. A correct ranking produced after repeated duplicate requests may be too expensive for the intended use. A correct answer obtained using information outside the permitted dataset may violate the task’s rules. Output quality and execution discipline need separate judgments.

The purchase decision is whether generated Python earns its additional freedom. Keep it when composition helps the system handle cases your fixed workflow misses at an acceptable cost. Narrow it when the same few steps recur. Hugging Face has supplied a mechanism for expressing actions; the builder still owns the decision about which actions belong in the product.

Frequently asked questions

Is smolagents a language model?

No. It is a Hugging Face library for building agents that use language models and tools.

Does CodeAgent only generate scripts for review?

No. It can execute generated Python as part of the agent’s workflow, making execution permissions a design decision.

Does the software license cover operating costs?

No. Inference, execution infrastructure and external tool services can incur separate costs.