You probably don't need an agent

Do you remember n8n? It was the next shiny AI thing for a while. People used it to make agents before the frontier labs gave us agents like Claude Code and Codex.

Looking back, n8n wasn't really built for this. It's basically a visual workflow automation tool. You connect a trigger to some logic, perform a couple of actions, and produce an output.

I've used it a lot, and I still do. It has been the most stable and reliable part of my AI stack.

And the biggest thing it taught me is that most workflows don't need much AI at all.

Let me give you an example:

At one point, I wanted to automate the customer service for my company. The trigger for this workflow is a new email.

Normally, I would read the email, look up the customer in Stripe, check their account in Ghost, figure out what was going on, take whatever action was needed, and send a reply.

I figured that automating the information-gathering part of this process would be a good place to start. So, I hooked up an AI agent node (n8n works with nodes) to the process trigger. This means that every time a new email arrives, the AI agent will wake up.

I gave it the email, some instructions, and access to tools for Stripe and Ghost. Its job was to find the relevant customer information and send me a summary of the problem, links to the customer data, and a proposed next step.

It worked. Kinda.

The first problem was speed. Not because every LLM is inherently slow, but because agent loops are slow compared with direct API calls. Sometimes it took over twenty tool calls to get to the data it needed.

This leads to the next problem: it's expensive. Every additional round through the model meant more context, more tokens, and more latency.

But the biggest problem was reliability. It's like the old meme: "60% of the time, it works every time".

And that could be fine for some workflows. Something that works 60% of the time could be very valuable. But for most workflows, it's quite easy to make something that works 100% of the time. Just good ol' deterministic programming. If this, then that.

So that's what I did. When a new e-mail arrived in the inbox, the workflow used the e-mail address to gather customer data via the official Stripe and Ghost API. This means the workflow collects the e-mail content, payment data, and profile in three steps.

After that step, I still use an LLM to triage the problem, but it's not really an agent. It doesn't need tool calls anymore. I feed it the relevant data, and the agent returns a summary of the problem and a proposed follow-up.

Conclusion: Use deterministic code for deterministic work. Use models where the problem is actually fuzzy.

In the example, I used an LLM to summarize a problem. Another way I use LLM's is as a classifier. For instance, for our YouTube channel, I made a workflow that classifies comments as SPAM or NOT SPAM. It's been in production for over a year, and it works great. It even got better, cheaper, and faster as new models were introduced.

This brings me to Jev. The tldr; LLMs are good at chatting and human language. Jev is good at making decisions and formulating the answer in a way that software understands.

In more technical words: it's a fuzzy if statement. This means it doesn't say yes or no, but assigns probabilities.

I can feed it a YouTube comment, ask it 'is this spam?' and it will give me back a JSON with answers and their probabilities.

For example:
spam: 0.91
not_spam: 0.09

That gives your software something much more useful than a paragraph of generated text. You can decide that anything above 0.95 gets automatically deleted, anything below 0.20 stays up, and everything in between gets reviewed.

Now, you might say: couldn't I just do this with DeepSeek Flash and structured output?

You are right. That's what I was doing before.

Modern LLM APIs are actually pretty good at structured output. JSON itself isn't the interesting part.

The difference is that Jev is designed specifically for these decisions. It doesn't need to generate a free-form answer token by token and then squeeze that answer into a schema. Typed probabilistic decisions are the output.

What sets Jev apart is speed and cost. In my test, it was about three times cheaper and twice as fast.

Another interesting property is that Jev can make multiple independent decisions in parallel.

So instead of only asking:
Is this spam?

I could also ask:
Is this promotional?
Is this impersonating someone?
Is this discussing a specific crypto asset?

After that, you could use the answers to these three questions to decide whether to remove the comment. This parallelization doesn't impact speed!

Which brings me back to the lesson I learned from n8n.

I think the starting point should be the simplest, fastest, and cheapest tool that can reliably solve the problem. And most of the time, that means starting with code.

Most problems in a workflow can be solved deterministically.

When one part requires understanding messy human language or making a fuzzy decision, put a model there, whether that's an LLM or something like Jev.

Only when the process itself is unpredictable do you need an agent.

I'm quite excited to test this model out in some of my workflows and software. I think the frontier labs will come up with their own Jev-like models.

You can try Jev on via Typesafe, Vercel or Openrouter.

Other stuff

• I'm on a holiday in Puglia, Italy. I was looking forward to eating a lot of pasta. The thing is, they eat quit different pasta here than in the north. More fish, more seafruit, and more horse meat.
• I finished The Infinity Machine by Sebastian Mallaby. 5/5 book. It's the story of Demis Hassabis and the AI lab Deepmind. It's about the different forms of AI, about the rise of transformer models, about Google aqcuiring Deepmind and much more.
• I finished The Nord Stream Conspiracy by Bojan Pancevski. 4/5. The title says it all: it's about the destruction of the Nord Stream pipelines. I learned quite a lot about Ukraine in this book, especcialy the relationship with Russia. It's also a cool peak behind the curtain of different secret services.
• I finished Empire of AI by Karen Hao. Also a 4/5 for me. Really good book. Hao is quite critical on some parts of the industry. The chapters where she had access inside OpenAI are really good. Shows that this industry is so weird and concentrated in Silicon Valley.
• I finally got my Apple Developer account approved. Weird process. Had to apply multiple times. Instead of giving you feedback on what to improve, they just turn down you application and you can try again. Will soon talk about the app that I'm working on.
• I want the iPhone Duo because I'm fed up with the boring form factor of smartphones. Not going to do it though. Too expensive. Also, I tried to make my iPhone as dumb as possible and use my iPad for entertainment.

See you next time

Bart