Before I Begin, when I talk about AI Agents. It’s good to know what I intend to convey. As the space is evolving at a pace so rapid that I cannot keep up, see my post on [AI Agents](AI Agent).
Level 1 - No Code
No code solutions are a great way to view how workflows can execute in a quick proof of concept way. They are proving to be excellent toy builders or personal automations that will streamline things that need to be done on a small level. The cost to build and maintain these agents are relatively low as you just need someone who can define the business workflow, know the no code tools, use LLMs to make non-deterministic decisions, and hit the buttons to plug the SaaS tools together. While knowing the business problem well enough to build custom workflows and [agents](AI Agents) is quite a feat, those agents are severely limited in their ability to accomplish tasks at scale.
Problem 1 - Integrations
The most glaring issues with these no code agent builders is the lack of tool integrations. What happens if your team uses a different SaaS product that isn’t plug and play? This will lead to either needing an engineer to build hooks from tool to tool, or needing more custom build where you may as well use an [Agentic Framework](Agentic Framework).
Problem 2 - Speed
What happens if you need to hook multiple no code builders together to make the workflow or agent do what you want? This will drastically reduce speed and limits the capabilities of the company implementing it to abandon certain types of functionality that is either too slow or too complicated such as complex database structure, [vectorization of data](Vector Database), or live chat. These no code agent builders were a conceptual branch from the automation tools of the world like Zappier and were not designed with these specific use cases in mind, but instead bolted on partial functionality to claim capability.
Problem 3 - Capabilities and Customization
The issue with the capabilities and level of customization with no code builders is akin to no code website builders. If you need an online store to sell your widgets, a blog to post your thoughts, or a pretty single page website to show off your local restaurant menu and hours, Squarespace is a great option. If you are trying to kill Blockbuster by innovating a new way to move massive files over a relatively slow internet, with a relatively new customer pricing model, and trying to solve the problem of global coverage at the click of a button, you aren’t going to use a Squarespace or a Wordpress with plugins to get your site built. You’re going to hire thousands of engineers to solve really difficult problems that didn’t exist as a concept just a few years before. I’m not trying to claim that becoming the next Netflix is the goal for agent builders, I’m just trying to convey the drastic differences in capabilities between custom build with some of the best and brightest engineers in the world and Timmy from youth group who “is definitely a web developer” that can build the church a website in an afternoon for his community service project. People who don’t know software engineering may look at little Timmy and think he’s a prodigy because he made value while using the computer, while people who knows what’s up will give Timmy props for his work using the right tool for the job and making a site that will have a monthly visitor number close to Timmy + his mom.
Level 2 - Agentic Frameworks
Agent building frameworks like Pydantic and LangGraph are great alternatives to teams who have more specific build, but don’t have the pockets for level 3. These tools allow for software engineers to have a way to interface with the workflow orchestration and LLM calls in one tier abstracted when building the workflows, state management systems, and agentic decision making. They solve a handful of very important problems right away
- They can integrate, for the most part, with anything that has an API. While no code builders will require someone more technical than your standard Ops person to setup an HTTP request (which in most cases is the extent of the tool’s capability), an engineer will run circles writing REST APIs, RPCs, or even POSIX connections when we want to stay super fast and local.
- They have the ability to be much faster as you aren’t making calls from one SaaS to another, but handling everything you need to in house.
- These frameworks have the potential to build real world tools. You aren’t going to be the next Netflix with one of these, but you are going to be able to make an actual tool that a medium sized company could use to manage a small aspect of their business. All of a sudden those voice agents helping you book your doctor’s appointment after office hours giving the doctor notes and answers to simple followup questions, or those marketing agents helping you take your PR teams’ work and highly target potential customers with 1:1 feeling marketing all of a sudden becomes real.
Problem 1 - Extensibility
The biggest issue I can see from my junior bubble is that while tools built out in these frameworks are certainly more powerful than no code builders, they lack the ability to make non prescribed desiscions. A tool in LangGraph, for example, will be able to take the state in, pass the information to an LLM, and pass a tool choice back. What if your team hasn’t built a tool for that yet? what if there is an edge case you didn’t foresee? The tool will fail and the customer’s faith in the tool will plummet, as they could have just hired a low-mid pay employee who would have a higher success rate with these edge cases.
Problem 2 - LLM Design
LLMs were designed first to be conversational, then they became trained for code generation, then for “thinking”, then for “deep research”. Each of these tasks were trained into the model. There is no model for “decide what tool I should use”. We use these other models in place of training one on our own for the specific task we need. This is fine if we build sufficient scaffolding, error handling, and data cleaning into our agent, but it is simply not at the same caliber as something that is trained from the get go to search the web, access the entirety of human created knowledge with or without regard to their legality, or trained to do a specific thing like talk or drive. These AI models were trained with specific use cases in mind and have the context built, or in some cases distilled, right into them. They can think around the edge case issue more easily than a framework built agent will be able to for that very reason. While we have to build around these general purpose AI models, hand crafted ones will always outperform.
Level 3 - Hombrew
Obviously the most costly of the three options, homebrewing a model will be many orders of magnitude higher than agentic framework builds would cost. I don’t have enough experience to claim anything from my own experience or knowledge, but hearing from Josh Tobin, who is a member of the technical staff at OpenAI (which I recognize is like hearing from Big Ketchup that hotdogs are going to replace software engineers) claimed that reinforcement learning helps mitigate “all the scencarios that the model might face” when trying to complete the task it was trained to do. That’s pretty much all I have to say on the topic, as I have never built any reinforcement models before, but only used models others have used.
Conlcusion
While this might not be very actionable for many people, I, in all my junior dev wisdom, think that there will still be tons of room for new companies to grow into reinforcement models and bring new kinds of agents to the world that are outside the realm of cars, coders, and conversations. I think that companies will create valid and successful companies using agent frameworks, the biggest, the next Anthropic, Google, and OpenAI may still have yet to be created. The long game is yet to be lost to the current giants of industry. There is room to innovate, room to niche, and room to thrive in the still brand new AI world we live in. And hopefully one day, someone can make me my robot butler.