Can I Just Get an Agent to Do It?
Innovation

Can I Just Get an Agent to Do It?

A friend was recently picking my brains on how to solve a broken process that she has inherited at work: once a month, several people gather data from various sources and share with her. She combines the data into a single Excel spreadsheet with various checks and manual adjustments. That spreadsheet is passed into Claude (with several supporting documents) to produce a .html file that renders the data as an interactive report.

She asked me "Can I just get an agent to do it?". The question took me by surprise. Even though I have been building a bunch of agents and orchestration to automate some marketing tasks, I'm very conscious that the term is not well defined and means different things to different people. So this article aims to provide some clarity to her and others like her who are struggling with the ambiguity around agents and adjacent terms.

Before we talk about Agents, I want to talk about Tools and Chatbots first.

Tools

For the purposes of this article, think of a Tool as a piece of logic that performs a defined task when you invoke it, and does not decide on its own what to do. This does not mean all Tools are deterministic. Some, such as a Tool that fetches weather data from the internet, gives different results over time. The following are Tools in this context:

  • Excel and other "programs" that run on your computer that you access via a UI
  • Cloud services that you access via a UI (e.g. Excel via Microsoft365), an API or an MCP Server (basically a wrapper around an API that makes it easier for an agent to use)
  • A utility that runs on your computer that performs system level tasks such as moving files or fetching data from the internet
  • A utility/program that you or a coding agent wrote yourself that runs on your computer
  • etc...

If you have a predictable set of inputs and you have defined logic that, when applied to those inputs, gives you your desired output, use a Tool or build one to automate your task. You don't need AI, LLMs, Agents, etc... so you can stop reading now :)

In theory, my friend could solve her problem by making sure the people who gather the data provide it in a pre-defined location in a pre-defined format, and that data is then taken into a "program" to produce the desired output. In reality it's not so simple. At the end of this article, I'll outline how she can unpick and fix the broken process she has inherited.

Chatbots

I'm not talking about the Chatbots from 10 years ago where the logic was built into the Chatbot. I'm talking about modern Chatbots that use an LLM. These Chatbots take text or images, pass them to an LLM that returns the next best token and magically creates the illusion of an intelligent interlocutor. Think:

  • Claude.ai
  • Chatgpt.com
  • etc...

Use a Chatbot when you are looking to retrieve information. They work as shown in the diagram below. The user inputs some data, a piece of software called a harness takes that data and interacts with an LLM, takes the data back from the LLM and presents it in some way to the end user. The harness on ChatGPT.com is managing different chat sessions, adding/removing system level messages that would be confusing to the end user, letting you select different models, etc...

Chatbot diagram showing user, harness, and LLM interaction

AI Agents

Think of AI Agents as Chatbots that have the ability to use tools AND make informed decisions about which Tools to use. In the case of an AI Agent, the harness has a list of tools that are available to it. It passes that list of tools and their description to the LLM during your conversations, and the LLM may choose to use those tools to give you a better response. For example, if your harness has the ability to make an API call to your Email service and retrieve your emails, the LLM can make that happen. When the LLM does invoke a tool, it invariably is looking for additional information that the tool can provide, so the results of the tool call are passed back into the LLM for another assessment before giving any feedback to the end user (or triggering another tool call whose results then get passed back into the LLM again, etc...). This is shown in the diagram below:

AI Agent diagram showing tool call loop between harness and LLM

An AI Agent can do everything a Chatbot can do, but can also use Tools as needed. Keep the following caveats in mind:

  • The vast majority of tools that you use today do not expose their full functionality to harnesses. Prepare to be frustrated as your AI Agent hits up against obstacle after obstacle.
  • AI Agents are inherently unpredictable because the LLMs that they use are non-deterministic. If you want your Agent to do the exact same thing every time, you may be better off building a Tool. Otherwise accept that the Agent won't always complete tasks as you expect.

Some examples of AI Agents:

In all these examples the harness runs as a program on your computer.

A note on RAG

Retrieval-Augmented Generation is when a harness retrieves relevant information from a knowledge base or document store and adds it to the context to influence the LLM's response. Technically the ChatGTP.com harness is using a Tool to get that information, so strictly speaking it could be called an Agent. But since it only has limited access to 1 or 2 Tools, consensus is that that's not "agentic" enough. So the lines between these definitions are still being drawn.

Orchestration

Building agents with broad capabilities is asking for trouble. A more varied context input into the LLM is going to give a more varied output. For this reason it makes sense to build specialised agents where possible. This has the added advantage of modularity, i.e. the agents can easily be reused, chained together, combined, etc... This is called Agent Orchestration and it can be done in two ways:

  1. Using an Orchestration Tool: when you know in advance which agents need to be invoked (e.g. a Code Review Agent might always invoke a Security Agent, a Documentation Agent and a Coding Standards Agent), your Orchestrator can hardcode that logic, just like any other Tool.
  2. Using an Orchestration Agent: when you're not sure which agents might be needed for a task, you can build an Orchestrator Agent that passes a list of available Agents to the LLM, just as it would pass any other list of Tools and let the LLM decide which tool will help progress the task.

In either case, the Orchestration Tool must keep an audit trail of which Tools/Agents it called and for what purpose.

Fixing my friend's broken process

The bad news: her process is already very badly designed. Using Agents to execute parts of this broken process will only provide marginal improvements. It's as if they bought a car to replace their horse and carriage, but instead of driving the car as intended, they've hitched it to their horses.

The good news: LLMs open up a world of opportunities to improve such processes and they warrant a complete redesign. I propose the following steps for such redesign:

  1. Forget about your current processes and draw up a new process diagram. Start with a list of input data that is needed, a blank process box, and the outputs that are needed.
  2. Ask yourself whether this process box can be a single Tool (remember, it's much easier to build your own Tools now using Coding Agents like Claude Code). If not, can this process box be a single Agent? Do you already have such a Tool or Agent for reuse?
  3. If not, add an additional process box (or boxes) to complete the process. Use a Tool where possible. Use as few process boxes as possible.
  4. If you have multiple process boxes, ask yourself whether these processes will always be executed and whether in the same order (you'll need an Orchestration Tool) or whether the decisioning logic is too complex to capture in a Tool (you'll need an Orchestration Agent).
  5. Build, Test, etc...

For the case in question, I expect that my friend will get as far as Step 2. Her company has PowerBI. It's missing some data needed to build the report and they are short of users capable of configuring PowerBI, but these are both issues that can be overcome with some planning and produce a more robust solution than stringing agents together to automate their existing fragile process.