I Built an AI Agent That Can Write Its Own Tools When It Gets Stuck

Most AI agents are only as capable as the tool list they shipped with.

They can browse, click, read files, maybe run some shell commands, maybe call a few prebuilt functions. But once they hit a task their built-in actions don’t cover, they usually stall out. At that point, you either have to add the missing functionality yourself, wire in some external skill system, or accept that the agent has reached the edge of its world.

That always felt like a major limitation to me.

So I built GrimmBot, an open source AI agent that can do something I find much more interesting: when it runs into a capability gap, it can generate a new Python tool for itself, test it, and add it to its own toolkit for future use.

That’s the headline feature, but it isn’t the whole story. GrimmBot also runs in a sandboxed Debian Docker environment, uses Chromium as its default browser, has persistent memory, supports scheduling, and can watch webpages or screen regions for long periods without constantly burning API tokens. The bigger goal was to build an agent that doesn’t just act — it can wait, remember, schedule work, and adapt when its built-in tools are no longer enough.

Repo: https://github.com/grimm67123/grimmbot

Demo videos are in the repo.

The problem with static agents

A lot of current AI agents are impressive right up until the moment they need one thing they don’t already know how to do.

That could be something small and annoying, like:

• parsing a weird file format


• extracting data from a custom log structure


• handling some specific transformation step


• navigating an unusual workflow


• bridging two built-in capabilities with custom logic

The model may understand exactly what needs to happen, but if the environment doesn’t expose the right function, the agent is stuck.

That creates a strange mismatch. The “intelligence” of the system can often see the path forward, but the actual action layer is boxed in by a fixed menu of tools.

I wanted to experiment with a different approach: what if the agent could extend that menu itself?

What GrimmBot does differently

GrimmBot has a capability for autonomous tool generation.

In practical terms, that means if it encounters a task its current toolset can’t handle, it can create a new Python tool, integrate it into its available tools, and use it again later if needed.

So instead of treating the shipped toolset as a hard boundary, GrimmBot can treat it as a starting point.

That doesn’t mean the agent is rewriting itself in some dramatic sci-fi sense. The point is much more practical than that. It means the system has a path for adaptation when it hits a task-specific wall.

To me, that makes the agent feel much less brittle.

Why I think this matters

The current pattern in a lot of agent systems is:

1. define a set of built-in tools


2. let the model choose among them


3. fail when none of them fit

That works fine for predictable workflows, but the real world is full of edge cases and highly specific requirements.

If an agent is going to be genuinely useful in open-ended tasks, I think it needs some ability to adapt when the prebuilt path isn’t enough. Otherwise it’s always one missing function away from dead-ending.

That’s what interested me most about autonomous tool generation: not the “wow” factor, but the practical reduction in brittleness.

A rigid agent can be impressive in demos.

An adaptable agent is much more interesting in real use.

The broader system around it

I didn’t want this to be just a toy experiment around generated tools. I wanted the capability to exist inside a broader agent environment.

So GrimmBot runs inside a Debian Docker container and uses Chromium as its default browser. It has a virtual desktop environment, browser control, file operations, shell access, coding-related functions, memory systems, scheduling, and human-approval pauses for sensitive actions.

That matters because tool generation by itself is not very useful if the rest of the system is too narrow.

The point isn’t just “the agent can write code.” The point is that the agent lives inside a sandboxed environment where that new code can become part of a larger workflow.

For example, a useful agent might need to:

• browse to a page


• inspect data


• realize it needs a custom parser


• generate that parser as a new tool


• save the result


• remember the outcome


• schedule a follow-up


• monitor for the next change

That is much more interesting to me than just proving a model can emit Python.

Zero-token monitoring was another major design goal

While autonomous tool generation is the most conceptually interesting part of GrimmBot to me, another major problem I wanted to solve was monitoring.

A lot of AI agents burn tokens while they wait.

If you ask them to watch a webpage, wait for text to appear, keep an eye on a status page, or monitor a region of the screen for a change, many systems keep involving the LLM over and over while nothing is happening.

That feels wasteful.

Waiting is not reasoning.

So GrimmBot includes monitoring tools that can run local loops against the DOM or screen regions without continuously waking the model. The LLM decides what to watch for, invokes the right monitoring tool with the needed arguments, and then sleeps while the local loop does the boring part. It only wakes up when the trigger condition is actually met.

I consider that an important part of the same design philosophy.

An agent should not use the model for everything just because the model is available.

Persistent memory and scheduling

I also wanted GrimmBot to be useful beyond one-shot tasks.

In real workflows, agents often need to:

• remember context across sessions


• store useful facts or task state


• revisit something later


• run at intervals


• continue work after a delay

So GrimmBot includes persistent memory and scheduling features as part of the broader system.

That way the agent is not forced to behave like every task starts from zero and ends immediately. It can maintain continuity better over time.

That matters even more once you combine it with monitoring and generated tools.

An agent that can:

• remember


• wait


• schedule


• adapt

is much closer to being operationally useful than one that can only act in the moment.

Why I built it this way

The common thread across all of this is that I wanted to reduce brittleness.

Static toolsets are brittle.

Constant LLM polling is brittle and wasteful.

No memory is brittle.

No scheduling is brittle.

A sandboxed environment with browser access, persistent context, monitoring, and the ability to generate task-specific tools felt like a more interesting direction.

I’m not claiming this magically solves every problem with agents. But I do think it points toward a model of agents that is more grounded in real workflows and less dependent on “hope the built-ins are enough.”