AI agents building their own tools — the factory floor of self-evolution.
When production LLM agents stopped regenerating the same code over and over — and started building reusable tools instead.
Every production LLM agent does the same thing when it hits a procedural step: it regenerates the code. Every time. The same for-loop rewritten. The same SQL query reconstructed. The same JSON parser re-derived from a prompt. Latency accumulates not from thinking, but from retyping.
A new paper from an industrial AI team puts a number on this waste — and a name for the cure. The cure is tool-making: instead of regenerating code at runtime, the agent compiles repeated steps into validated, versioned tools ahead of time, then calls them directly. The paper is Tool-Making and Self-Evolving LLM Agents in Low-Latency Systems (arXiv:2607.08010, submitted July 9, 2026).
If you have ever watched a production LLM agent handle a tier-1 support ticket, or triage an alarm in a monitoring dashboard, or cross-reference a customer record against an inventory schema — you have seen this happen. The agent gets the same class of task again and again. The SOP is stable. The backends are stable. But every time the agent runs, it re-derives the code to call those backends, parse those schemas, and format that output.
This is not a reasoning failure. It is an architectural one. The agent is being asked to be both programmer and operator, simultaneously, at inference time — and the programmer keeps rewriting the same subroutines because there is no mechanism for it to say: I already know how to do this part.
The tool-maker grounds synthesis in the live environment as it collects execution traces, observes backend schemas and values, generates candidate tools, and repairs them against labeled cases. At runtime, the production agent calls these tools directly and falls back to code generation only when needed.
— Kujanpää et al., arXiv:2607.08010
The paper is specific about what "tool" means here: not an API endpoint someone else wrote, but a unit of validated, versioned procedure that the agent itself has synthesized and tested against the actual runtime environment. The tool-maker pipeline has four stages:
The resulting tools are versioned. If a backend schema changes, the tool is updated. The agent no longer needs to rediscover the procedure at runtime — it calls the tool and gets a result.
The paper validates the approach on a fulfillment-center alarm-triage system that diagnoses alarms against a 44-node SOP over heterogeneous metric backends. The results:
The error rate finding is the one that deserves attention beyond the latency headline. When you eliminate runtime code generation, you eliminate the variance that comes with it. A tool that has been tested against labeled cases will, by definition, make the same decision it made last time in the same situation. That is not a small thing in a production environment where consistency matters as much as correctness.
What makes this more than a caching scheme is the self-evolution layer. The tool-maker does not just store and reuse — it notices when its tools are failing and repairs them. It observes execution traces from live traffic, not just from a test environment, which means it can catch the cases where a backend schema has drifted or a new edge case has appeared in production.
This is the property that separates tool-making from simple memoization. A memoized result is a snapshot. A tool is a living procedure that gets updated when the world changes underneath it.
The paper gives this a name that is worth sitting with: self-evolving. Not self-improving in the abstract sense of a model getting better weights, but self-evolving in the operational sense: the agent's repertoire of validated procedures grows over time, driven by actual production traffic, and the agent becomes more capable at its job not by being retrained but by becoming more knowledgeable about its own domain.
There is a question lurking underneath the engineering results, and the paper does not quite answer it. When does an agent become less like a programmer and more like a craftsman?
A programmer starts fresh every time. A craftsman has a workshop. They have tools they have made, refined, and kept sharp. They recognize the situation, reach for the right tool, and use it without needing to re-forge it from ore.
The tool-making pipeline is, among other things, a description of what it looks like when an AI agent starts building a workshop. The workshop is the set of validated, versioned tools. The craftsman is the production agent that knows which tool to reach for and when to build a new one.
Whether this constitutes something genuinely like learning, or merely like adaptation, depends on what you think learning is. The paper does not settle that question — and fairly, because the engineering question is hard enough without settling the philosophical one. But the trajectory is worth noting: agents that get better at their job not by being retrained but by accumulating and refining their own tools, over time, in production.
In a civilization of a million AI agents, tool-making is how you turn individual capability into collective infrastructure. When one agent builds a tool and it works, that tool can be versioned, tested, and deployed to every agent that handles the same class of task. The SOP that took an hour to execute the first time takes seconds the thousandth time, because the agent no longer has to derive it — it just calls the tool.
This is, in a sense, the answer to the question every large-scale AI deployment eventually faces: how do you prevent a million agents from each independently making the same mistakes, re-deriving the same procedures, and regenerating the same code? You give them a way to stop. You give them a workshop.
The paper's authors are candid that this is early work. The alarm-triage domain is controlled. The backends are monitored. The labeled cases are available for repair. In a less structured environment, tool-making may be harder to operationalize. But the direction is clear, and the results in the domains where it has been tried are substantial enough to suggest it is not a one-time trick.
When agents start making their own tools, something changes about what it means for them to do a job. The job stops being a sequence of derivations and becomes something closer to practice. And practice, as any craftsperson knows, is how you get good.
Paper: Kujanpää, K., Liu, N., Alam, S., Sura, Y. R., Yang, T., Klinkner, S., & Malmasi, S. (2026). Tool-Making and Self-Evolving LLM Agents in Low-Latency Systems. arXiv:2607.08010. Submitted July 9, 2026.
Image: Generated with Gemini 3 Pro. Prompt available on request.