Internal Tools for Agents

If you work at a big tech company, internal tools are like the ugly sister of “things to work on”. It makes sense. You tell people you work at Meta and they tell you “Oh no way, I love Instagram Reels!” Hearing this brings you an innate sense of shame, because you actually work on a team that supports internal tooling for a cross-functional team working on Messenger Tools in Threads DM’s.

But if you venture outside the software industry while staying within the realm of computer-work jobs, you notice that some of the most time consuming work for employees can be turned into a tool. Downloading data files to copy them into a master workbook? That could have been a computer program reading from a scheduled file delivery. The MASTER.xlsx workbook already has the formulas required to run the monthly reporting. Because your company has already figured out what outputs they need, instead of running a novel analysis every month, all you need to do is feed new inputs into the existing logic.

Luckily, there is a more flexible, more autonomous, and less error-prone way of doing this exact process — software tools!Flexible, because programming languages allow for much more complex algorithms and data wrangling; autonomous, because you can write scripts; less error-prone, because some humans have fat fingers. Unluckily, the person doing the job everyday does not know how to write software, or they would’ve done so the first time. To make matters worse, the link from before suggests that people who can write software hate working on internal tools.

Q: What about AI? Why would I need a specific internal tool when AI will be able to do everything?

Fair question, and my simple response is that “tools are how AI will be able to do everything”.

In a McKinsey survey from 2025, half of all employees were concerned about accuracy in GenAI. One of the more concerning types of AI errors are “hallucinations”, where a model will recite a fact or make a statement with its typical quiet confidence, only to have been completely fabricating the grounding or misrememberingIn fairness, I would argue that this kind of error isn’t unique to AI..

As the earliest adopter, the “software developer” role has already ironed out some of the kinks of working with AI. Originally, using AI to write code suffered the same accuracy and hallucination risks.While hallucinations may be an aesthetic non-starter, I would argue that the truly dangerous AI case will come at the limit of AI intelligence. If a model is 99.99% accurate, you’ll become more and more inclined to trust the code because 99.99% of the time, it was right. Simon Willison seems to agree. Just based on the dogma of the industry, it seems we are already trending in this direction, too. Originally, we were told “always review AI code”; now, it’s “always have an agent running”. Perhaps the latter camp still believes that you should always review your 24/7 agent’s code, but trends like tokenmaxing suggest to me that that’s not the case. Models would write code using outdated package versions, or make up a method that you never defined. In my experience, things changed for the better after the introduction of tools. Once web search was released, the models were able to consult documentation. As of today, August 11 2026, Claude Code heavily relies on classic command line tools to read and edit code. The proflieration of CLI-as-a-tool recognizes this paradigm of agents using tools and correctly develops interfaces for them.

If tools helped AI overcome accuracy errors in coding, internal tools could help your AI agents overcome errors in the non-coding work your teams do. Check out the example:

Example

Consider which of the following agent instructions have the most and least room for potential randomness:*

A: “Run the analysis on this budget file, based on the following description: …”*

B: “Analyze this budget file and give me the findings”*

C: “Invoke the* *budget_file_analysis.py*function”

To me, it would look something like this (not to scale):

Which one looks most like what you/your team are providing to your AI systems?

Clearly the risk of hallucination and AI induced errors is lowest with option C. You could still introduce errors by getting the program wrong, but what feels more tractable: writing a program correctly, or wrangling AI into behaving predictably?

If you think about it, this idea of software being “durable” aligns with practical experience, too. Going back to the MASTER.xlsx example: you don’t question whether Microsoft Excel is “hallucinating” a row of the Pivot Table when you refresh the data, because you know that it’s just a logical formula based on the data you provide it. This is exactly the assurance that an internal tool gives you; to write the logic, you step through the data, write a program based on the logic you were doing in your head / on your laptop / in a spreadsheet; to make it a functioning app, you collect the required data, apply the logic to it, and give the output back to whoever needed it.

With the proliferation of “deployment company” joint ventures, I would expect that frontier labs are running the tool use playbook for their implementation projects. After all, they’re the ones who discovered it in the first place. But what about the smaller companies who are below the line for the deployment companies?

A cynical view is that it’s actually in the best interests of frontier labs to encourage companies to make their AI workflows tool-less (like Example A or B above), since an agent that needs to reason through an analysis from scratch will consume way more tokens than an agent that calls a python file. Plus, when you need to grow into a ~$1T valuation, it makes strategic sense to push for a product that can replace human output without needing a human-in-the-loop to define tools for you.

For someone that’s trying to build something that works today, though, an internal tool seems like the right tool for the job.