The Good Tech Companies - What I've learned building an agent for Renovate config (as a cautious skeptic of AI)

Episode Date: January 23, 2026

This story was originally published on HackerNoon at: https://hackernoon.com/what-ive-learned-building-an-agent-for-renovate-config-as-a-cautious-skeptic-of-ai. As an opportunity to "kick the tyres" of what agents are and how they work, I set aside a couple of hours to see build one - and it blew me away. Check more stories related to machine-learning at: https://hackernoon.com/c/machine-learning. You can also check exclusive content about #artificial-intelligence, #building-an-ai-agent, #renovate, #ai-agent-for-renovate, #good-company, #mend, #llm, #mend-renovate, and more. This story was written by: @mend. Learn more about this writer by checking @mend's about page, and for more stories, please visit hackernoon.com. For those who aren't aware, Mend Renovate (aka Renovate CLI aka Renovate) is an Open Source project for automating dependency updates across dozens of package managers and package ecosystems, 9 different platforms (GitHub, GitLab, Azure DevOps and more), and boasts support for tuning its behaviour to fit how you want dependency updates.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. What I've learned building an agent for Renovate Config, as a cautious skeptic of AI by MEND. EO, it's fairly likely that you've heard the term, AI agent, or agentic, used in the last few months, and for a number of folks, it's possible that you've used sedan AI agent before. But do you know how they work, and how straightforward IT can be to implement a fairly basic version? I'm a self-declared, cautious skeptic about AI and large language models, LLMs, and so I've not delved too far into the tools and workflows as some of my colleagues have. Late last year, Thomas Patacek wrote you should write an agent, which piqued my interest

into digging into how they work. Earlier in 2025, I read Thorsten Balls How to Build an Agent. And although I hadn't gone and implemented it following Thorsten's steps, I was a little surprised at how straightforward it seemed. As an opportunity to kick the tires of what agents are and how they work, I set aside a couple of hours to see build one, and it blew me away. I thought it was a good idea to share this with y'all and reiterate how you can get something working quickly. What's Renovate? For those who aren't aware, Mend Renovate, AKA Renovate C-L-I-A-K-A-A-A-Renovate is an open-source project for automating dependency updates across

dozens of package managers and package ecosystems, nine different platforms, GitHub, GitLab, Azure DevOps and more, and boast support for tuning its behavior to fit how you want dependency updates. Men's cloud-hosted Renovate is used by 1, 3M-plus repositories, and the Renovate CLEs used by millions of repositories in a self-hosted fashion, too. What's an agent? Despite the buzzword hype around what agents actually are, I've found Simon Willison's definition to be nice and digestible. Greater than an LLM agent runs tools in a loop to achieve a goal. This takes our LLM and gives it the ability to call tools, aka tool calling, which are provided to it directly, as we'll implement ourselves, or through the model context protocol, MCP, standard. As the state of

the art models are now trained on tool calling, it means that way can provide the model a tool, and it'll understand how to call it. What do we want to build? I thought that a good way of exploring this would be to teach an LLM a bit more about how to craft Renovate configuration. Because Renovate boasts support for many ecosystems and has a number of configurations to tune the behavior to exactly what you want, there are a lot of different possibilities for configuration you could add to your repository. LLMs already have a good understanding of Renovate configuration based on their training data, and if they have the ability to search the web, our current documentation, but they may not have the exact documentation for the version of Renovate we're using. We have a

vibrant community and because of the fast-paced nature of contributions into the project, it can be hard to keep up with the letest changes. Even for me as one of the maintainers, with this in mind, I decided on the following features I wanted out of my agent. One, the ability to tune the agent to a specific renovate version. Two, the understanding of functionality available in that version. Three, the ability to propose configuration changes. Four, the knowledge of what is a valid configuration, using, which is shipped as part of the Renovate NPM package. 5. The ability to check what the configuration changes would mean by running and confirm that the expected changes occurred, using the same workflow I would take. Building the agent,

creating the basic input loop to start with, I very closely followed Thorsten's post and Jeffrey Huntley's workshop, based on the blog post, to get a basic shell of my agent up and running. To save myself from needing to create a separate anthropic subscription, I'm a day a couple of tweaks to use our AWS bedrock setup, and was up and running, Thorsten's post is excellent, and the step-by-step nature, combined with a writing style to be jealous of, gives a really good primer on the basics. Teaching the agent what, valid, config looks like once I had a basic loop running with a minimal read underscore file tool, I started having conversations to get a baseline of what the model already knew about Renovate configuration. I'd noticed that some of the configurations being suggested would be

using deprecated features, which I know as a power user of Renovate, but not everyone would do until they run Renovate. As a quick aside, due to Renovate's continuous development, we sometimes rename or refactor existing options. Instead of making this a breaking change, we ProVed an automated, config migration, configuration tie. Use the new name of the configuration field. This is both applied when Renovate is running to not force users to immediately make config file changes, but I also suggested to be committed to the repository. Renovate has a tool, which can both report when using invalid configuration.

Bujan also highlight when using something deprecated that needs a config migration. My first Renovate Y tool I said about adding to the agent was to teach the LL mode to make sure it's only providing valid, migrated configuration. After implementing the tool and providing it to the LLM, I saw the LLM reliably USE the tool, but it didn't seem to listen to the warnings about config migration. To nudge the agent to follow this more clearly, I made sure that my system prompt included, greater than. You should make sure that any configuration you present is then greater than validated by the tool, and that any config migration suggested in the response greater than is adapted. Do not leave users with configuration that needs migration. Unsurprisingly, the agent got

a lot better at it and started to return the config in the migrated form party popper with this functionality in place. The agent was already significantly more helpful, as it now couldn't hallucinate a configuration field and return it to the user, as it would run it through, realize it had returned invalid config, and try again until we had a valid config. Polishing the text rendering. At this point, we had an agent that could start to answer some reasonable questions from me and provide valid configuration, and I was able to start using it a little. LLM's largely replied to questions with markdown, and although it's second nature at O-Red, I'd prefer for it to be rendered markdown, especially as we have many libraries to do that.

At this point, I integrated in charm bracelets glamour library to render the markdown, resulting in a change from, to the more pretty version. Packaging the T-O-O-L-S-I wanted to be a little bit more explicit about the versions of Renovate, its tooling and documentation, but couldn't as easily do that when I had a few versions of Renovate installed on my machine. To simplify the packaging, I ended up creating a lightweight Docker image that would allow my agent to, have a specific version of and installed. Know what version of Renovate were running, and tell the agent. Have a copy of the docs for that version downloaded. Now there's an explicit version of Renovate, I amended my system prompt to tell the agent that, reading DOCS the next logical step

would be to have the LLM able to use the documentation fourth given Renovate version appropriately, and be able to query usage examples for different configurations to tune its responses. I implemented a tool which would return all the docs, approximately 66K lines of markdown, which unsurprisingly didn't work, because LLMs have a limited set of context, aka their, context window and throwing that much data would cost a lot of money, as well as reducing the context available to process the rest of the conversation. Even looking at the documentation for all repository config settings, which would likely be the most helpful page of docs, that was currently approximately 13k lines of markdown, and so I needed to consider a way to split this file in a way

that Anlam would be able to digest it more easily. This is one I've not yet finished off solving, but it has been interesting to consider how to break down large files into smaller sizes that will work better for LLMs and possibly also humans. I've started by introducing a tool which can list all files in the directory downloaded from the GitHub release for Renovate, and then we can use to read each individual file, albeit we can still hit context length issues with Sumdocs files. Actually running Renovate the final feature I wanted to implement would give the ability to run Renovate in a dry run mode and validate whether the changes that the agent was proposing would actually work. To do this as a human, I would run Renovate in its mode, and then check the logstow see if the relevant change was made.

Fortunately, the agent could be told to do exactly the same with a tool call, which would execute the Renovate CLI against a local copy of a repository, based in the configuration that the agent is suggesting. Once the command completes, the agent receives a special log line, which provides information around the files renovate has parsed and any updates detected and is hugely useful when debugging. As we're finding, each incremental tool being provided to the agent makes it more powerful, and I started to see it more reasonably able to confirm if I, e, adding a reg X to parse the version from a would actually detect the current version and pending version updates. I've not yet

finished tuning the system prompt to teach it exactly what I'd be looking for when looking through the log lines, but it's interesting how much IT can already do. Lessons learned. Through this process, I've learned a lot more about agents and LLMs, and it's dot me that there isn't as much magic as it sometimes seems, and that IT can be straightforward to do something interesting. Surprisingly, STR-A-I-G-T-F-O-R-W-A-R-D-I was surprised to see how straightforward it was to get to a minimal agent loop, based on Thorsten's post, and then how it was only a couple of hundred extra lines of go to get to the final result, totaling approximately 700 lines of

code. I realize that a lot of the work is being done by the LLM under the hood, but it's still impressive. Incremental building was Funi really enjoyed seeing how incremental changes like the addition of a new tool or a tweak to the system prompt would improve the overall viability of the agent. As I made changes, I re-ran the same prompts to get a feel for the difference, while remembering LLMs are non-deterministic. Getting the UX right is easier with a specialized agent when you have an agent that is specialized for specific features, you can more easily control what this looks like. In my case, we're largely making tweaks to a JSON file that sits within our repository, and looking at what changes the Renovate CLICs after these changes. I've not yet ended up implementing it,

but what I really want is to have a side pane on the agent's interface, which shows the current Renovate configuration we're currently talking about. So as it changes based on the LLM's feedback, IT changes on the UI. Context is hard as nudge. noted above, trying to juggle the size of our documentation with the context window and LLM has was a bit tricky. Add this on to the fact that some of Renovates log lines can be particularly long, especially in a large repository, and we then have additional places to consider how to limit the token usage at a given point. I've also found that although my system prompt nudges the LLM towards a specific action based on wording, I. E. In the JSON schema used for a

given tools definition, I sometimes have to nudge more heavily, I, e, if I'm expecting it Torin with. This could be ANMCP server those of you more familiar with LLMs, agents, and the model context protocol will have noticed that a lot of this isn't actually agent-specific, and that the tools themselves could be extracted into an MCP server. That's absolutely the plan, but for the purpose of this blog post, it made sense to show that it was simpler to implement it all within a single agent, Thanriing to also add in an MCP server that needed interacting with. I now have a lot more TO done fortunately.

I now have a lot of other things I want to do with this. I'm also looking at how this can be used to improve my own life, working as the Renovate Community Manager, answering user questions. And keep your eyes peeled, I very much want to get this open-sourced when I'd is in a better place. Conclusion, as someone who hasn't done a lot with LLMs and agents, I've found it really eye-opening to see how straightforward it can actually

be. I'll leave you with another reminder that you should build an agent. Jamie Tanna's senior developer and open source project maintainer Jamie is a maintainer of MEND renovate, where he also holds the role of community manager, so you'll probably see him around. He's been maintaining open source projects you may have heard of for the last decade. Ondaz spent the last approximately five years working heavily in the dependency management space and helping enterprises ship better software. Thank you for listening to this hackernoon story, read by Artificial Intelligence. Visit hackernoon.com to read, write, learn and publish.