Agents are useful when you do not know the process yet. Code is useful once you do.
Instead of choosing one, I use the agent to discover the algorithm and then turn the repeatable parts into code. The model stays only where the work actually needs judgment.
What's covered
- Giving an agent an unfamiliar support database and asking which subscribers may cancel
- Reviewing the queries and steps it used to find the answer
- Rebuilding that route as SQL plus one bounded ticket classifier
Start with the agent
In the example, I know the outcome I want but not how to get there: identify the subscribers most likely to cancel. The agent gets the support database as its only tool. It inspects the tables, filters orders and tickets, reads what customers wrote, and returns the people it thinks are at risk.
Every query appears in the run, so we can check its work. More importantly, the run gives us the algorithm we did not have before.
Turn the route into code
Most of what the agent discovered is plain filtering. Only reading the support tickets needs judgment. The builder converts the filtering to SQL, adds one small classifier prompt for the tickets, and keeps the output the same so the two versions can be compared.
The new Task finds the same customers in seven seconds instead of forty, for about one-hundredth of the cost. There is no agent exploring the database on each run because there is no longer anything to discover.
The first agent run was not wasted. It found the process. Once the process is known, code should own it.
Video transcript
There are two ways to automate a job. You can use an agent or code. An agent gets instructions and a set of tools, then works out the steps itself. It looks around, tries things and checks its work, and it does this every time it runs. Code runs the same steps in the same order every time. That is why code is fast and cheap while agents are slow and expensive. But to write the code, you have to know the steps, and sometimes you do not.
Here is the trick. Let the agent solve it once, then turn what it did into code and use AI only for the part that needs judgment, like a classifier. I want to know which subscribers are about to cancel and I have no idea how to tell, so I give an agent the support database and let it work it out. I do not tell it how, just what I want to know. It asks which login to use, then writes the script and prompt and tests them. The script hands the question to an agent with the database as its only tool.
The agent starts knowing nothing about the data. It looks at the tables, queries the orders and tickets, and reads what people wrote. It returns who is at risk and how it decided. That is the algorithm we did not have. Every query it ran is in the steps so we can check its work. Most of it is plain filtering. Only reading the tickets actually needs judgment.
I ask the builder to turn that into code, using SQL for the filtering and a small prompt for the tickets, while keeping the output the same so I can compare. It reads the agent's run and works out which parts are really just queries. The new version adds one prompt, classify ticket, on a small model. SQL does the filtering and a fast model reads each ticket.
This time there is no agent exploring. The flow shows the real steps: queries, then a classifier on each ticket. We see the same customers in seven seconds instead of forty, for about one-hundredth of what the agent cost. That is how we let the agent find the algorithm and then make it code.