Hey everyone, welcome back to My Weird Prompts. We have got a really substantive one today. I was just sitting out on the balcony looking over at the Old City, thinking about how much has changed in the world of technology in just the last year or two. Our housemate Daniel sent us an audio prompt this morning that really highlights that shift. He is asking about the state of agentic artificial intelligence tooling. Specifically, how we move from those early, fractured developer-heavy frameworks into something a business can actually maintain without spending a fortune on subscription services.
Herman Poppleberry here, and let me tell you, Daniel is hitting on the exact nerve that the industry is feeling right now. It is that transition from the hobbyist phase to the infrastructure phase. Remember back in two thousand twenty-four when everyone was excited about Auto-G-P-T and Baby-A-G-I? Those were basically just scripts that would run in a loop until they hit an error or burned through your entire credit limit. They were fascinating, but they were a nightmare to manage. Now, in early two thousand twenty-six, we are finally seeing the emergence of what I like to call the operating system for agents.
That is a great way to frame it. It feels like we are moving from the command line era of agents into the graphical user interface era. But Daniel’s point about maintainability is the real kicker. It is one thing to build a cool demo; it is another thing to have a multi-agent system that your operations team can actually monitor and update without needing a computer science degree. Herman, you have been diving deep into some of these open-source projects lately. Where do you see the biggest leap forward?
The biggest leap is definitely the unification of the workflow and the chat interface. For a long time, you had two separate worlds. You had things like Flowise or LangFlow, which were very visual and great for building complex logic chains, but they felt like developer tools. Then you had things like Custom G-P-Ts or various chat interfaces which were easy to use but lacked the deep logic and the ability to branch out into complex business processes. The project that I think is really winning this space right now, and one I know Daniel would appreciate, is Dify. That is spelled D-I-F-Y. It is an open-source platform that essentially acts as an L-L-M application development platform. It allows you to build these agentic workflows using a visual interface, but it also gives you a unified chat front-end that you can deploy to your team or your customers.
I have seen you playing around with Dify in the living room. One thing that struck me was how it handles the orchestration of different agents. Daniel mentioned the challenge of getting agents to talk to each other. In the old days, you had to manually code the hand-offs. You had to say, okay, if Agent A produces this specific string of text, then trigger Agent B. It was incredibly brittle. How does a platform like Dify or some of the newer orchestration frameworks handle that now?
It is much more elegant now because we have moved toward a more intentional design. Instead of just letting agents wander around and hope they find the right answer, we are using what we call agentic design patterns. In Dify, for example, you can set up a manager node or a router. The router uses a high-reasoning model like G-P-T-five or one of the newer Claude models to analyze the incoming request and decide which specialized agent is best equipped to handle it. But the real secret sauce is the shared context and the standardized tool-calling. We talked about this a bit back in episode seven hundred ninety-five when we discussed sub-agent delegation. The idea is that instead of one giant, confused agent, you have a fleet of specialists who all speak the same language and have access to a shared memory layer.
That memory layer seems crucial for maintainability. If I am a business owner, I do not want to have to re-train or re-configure ten different agents every time my company policy changes. I want a central place where that knowledge lives. Does the current tooling allow for that kind of centralized knowledge base that all agents can pull from?
This is where the integration of R-A-G, or Retrieval-Augmented Generation, into the agentic workflow has become seamless. In a platform like Dify or even some of the newer enterprise versions of Crew-A-I, you can upload your business documents, your standard operating procedures, and your technical manuals into a central knowledge base. You do not have to give that data to every single agent. Instead, you create a search tool that all your agents are allowed to use. So, if your billing agent needs to know the refund policy, it does not need to have that policy in its head; it just knows how to ask the knowledge base tool for that specific information. This makes the system much more maintainable because when the policy changes, you just update the document in one place, and every agent in your ecosystem instantly has access to the new information.
That definitely addresses the maintainability side. But what about the cost and the reliance on Saas? Daniel mentioned wanting to avoid expensive subscriptions. We have talked before about the death of Saas in episode eight hundred sixty-four, and it feels like we are reaching a tipping point where self-hosting these agentic platforms is actually viable for a mid-sized business. What does the infrastructure look like for someone who wants to run this themselves?
It has never been easier, honestly. Most of these top-tier open-source tools, like Dify, Flowise, or even things like Open Web-U-I, are designed to be run as Docker containers. If you have a decent server or even just a robust cloud instance like an E-C-two or a Digital Ocean droplet, you can spin these up in minutes. But the real game-changer for cost control is the emergence of A-I gateways. We did a whole deep dive on this in episode eight hundred forty-one when we talked about Lite-L-L-M. For a business, you do not want to hard-code your agents to a specific provider like Open-A-I or Anthropic. You use something like Lite-L-L-M as a gateway. It provides a single, unified A-P-I that looks like Open-A-I's A-P-I, but behind the scenes, it can route requests to whatever model is cheapest or most effective at that moment. You can even route some tasks to local models running on your own hardware using Ollama or v-L-L-M.
So, you are saying a business could use a high-end model for the complex orchestration, the thinking and the routing, but then use a much smaller, cheaper, or even self-hosted model for the basic data extraction or summary tasks? That would drastically bring down the operating costs of a multi-agent system.
And that is where the unified interface becomes so powerful. In a tool like Dify, you can specify different models for different nodes in your workflow. You might use Claude four for the initial reasoning because its logic is so sharp, but then pass the actual drafting of an email to a smaller Llama model that you are running locally. This kind of hybrid approach is how you build a professional-grade system without getting bled dry by per-token costs from the big providers. Plus, from a security and sovereignty perspective, keeping your data within your own V-P-C or on your own hardware here in Jerusalem is a huge win.
Let’s talk about the user experience for a second. Daniel mentioned the divide between workflow-based approaches and chat-based approaches. As a business user, I sometimes want a deterministic workflow where I know exactly what steps are being taken, like an automated payroll check. But other times, I just want to chat with an agent to brainstorm a marketing campaign. How do these new tools bridge that gap? Can one agent do both?
That is one of the coolest developments in the last few months. The best tools now allow you to expose your workflows as chat-enabled agents. Think of it like this: a workflow is a set of instructions, a map. A chat-based agent is the person walking that map. In these modern platforms, you can build a very complex, rigid workflow for, say, processing an insurance claim. But then, you give that workflow a chat interface. The user can talk to the agent, and the agent uses the workflow to make sure it follows all the necessary steps, asks the right questions, and gathers the required data. It feels like a conversation to the user, but behind the scenes, it is a highly structured process. This prevents the agent from hallucinating or going off the rails, which was the biggest problem with the early chat-only agents.
It sounds like we are finally getting the best of both worlds. The flexibility of natural language and the reliability of structured code. I’m curious, though, about the learning curve. If Daniel or one of our listeners wants to set this up tomorrow, how much technical heavy lifting are we talking about? Is this still something where you need to be a senior developer, or have we reached the low-code stage yet?
We are firmly in the low-code stage, though I would say you still need some technical literacy. You need to understand how A-P-Is work, what a system prompt is, and how to manage a basic server environment. But you are not writing thousands of lines of Python code anymore. You are mostly connecting blocks in a visual interface and writing clear, concise instructions in plain English. The real skill has shifted from coding to orchestration and prompt engineering. You need to be able to think logically about how a task should be broken down. If you can draw a flowchart of a business process, you can build an agentic workflow in two thousand twenty-six.
That is an encouraging thought. It democratizes the power of these tools. I want to circle back to the multi-agent orchestration piece because I think that is where most people get stuck. There is this idea of the manager agent pattern that I find fascinating. Instead of the user managing five different agents, the user talks to one manager, and that manager delegates. How does that look in practice within these tools?
It looks like a nested hierarchy. In a framework like Crew-A-I, which is very popular right now for this specific reason, you define a crew. You have a researcher, a writer, and a manager. The manager is an agent whose only job is to look at the task, decide which of the other agents should handle it, and then review their work before passing it back to the user. In a visual tool like Dify, you can replicate this by having a routing node that acts as the manager. What is really interesting is that these manager agents are getting much better at handling edge cases. If the researcher agent comes back with no results, the manager agent can now say, wait, that doesn't seem right, try searching this other database instead. It is that iterative, self-correcting behavior that makes it truly agentic.
And I imagine that also helps with the context window issues we used to have. If you try to cram everything into one conversation, the model eventually gets confused and starts forgetting things from the beginning of the chat. By breaking it into sub-agents, you are essentially giving each task its own fresh context window, right?
Spot on, Corn. That is a huge part of the maintainability and the reliability. Each sub-agent only gets the information it needs for its specific task. The researcher doesn't need to know the user's billing history; it just needs the search query. The writer doesn't need to see the raw search results; it just needs the summarized notes from the researcher. This keeps the prompts short and focused, which reduces hallucinations and keeps the costs down. It is much more efficient than trying to have one giant brain do everything at once.
So, if we were to give Daniel a concrete recommendation list, what are the top three projects he should look at if he wants to build a maintainable, unified, multi-agent setup for a business today?
Number one is definitely Dify. It is the most complete package right now. It has the visual workflow builder, the knowledge base management, the multi-model support, and a really slick chat interface that you can just hand over to non-technical users. It is open-source, you can host it yourself, and it is very robust. Number two, I would say look at Crew-A-I, especially if you have someone on the team who is comfortable with a little bit of Python. Their enterprise features and their focus on structured agent roles are top-notch. And number three, for the infrastructure layer, you have to use Lite-L-L-M. It is the only way to stay provider-agnostic and keep your costs under control as you scale.
That is a solid list. I would also add that people shouldn't sleep on Open Web-U-I if they just want a very clean, familiar interface for their team to interact with various models and agents. It is not as deep on the workflow side as Dify, but for a simple chat-based agent setup that connects to your local or cloud models, it is incredibly easy to maintain.
Good point. It is all about choosing the right tool for the complexity of the task. If you are just doing simple Q-and-A, Dify might be overkill. But if you are trying to automate a three-step business process with multiple agents, that is where the power of a real orchestration platform shines. One thing I want to mention, though, that often gets overlooked, is the importance of observability. When you have five agents talking to each other, things will eventually go wrong. You need to be able to see exactly what Agent A said to Agent B.
Right, the black box problem. If the final output is wrong, you need to know which link in the chain broke. Do these tools provide that kind of debugging or tracing?
They do. This is another area where the tooling has matured. Dify has built-in tracing where you can see the full execution log of every node in a workflow. For more advanced setups, people are using tools like Lang-Smith or Phoenix. These are essentially like the Chrome Developer Tools but for A-I. You can see the exact prompt that went to the model, the exact response, how many tokens were used, and how long it took. For a business, this is non-negotiable. You can't have a mission-critical process running on a system that you can't audit or debug.
It is amazing to see how quickly the ecosystem is building out the boring but necessary parts of the stack. The monitoring, the logging, the cost management. It makes it feel like A-I is finally growing up. It is not just a parlor trick anymore; it is becoming real infrastructure.
It really is. And for us here in Jerusalem, where we have such a vibrant tech scene, we are seeing this happen in real-time. There are so many startups focusing just on the evaluation and the safety of these agentic workflows. It is a great time to be building. I think Daniel is in a perfect position to start deploying this. My advice to him would be to start small. Don't try to build a ten-agent crew on day one. Build one solid workflow that solves a single, annoying problem, and then build from there.
That is always the best advice. Solve a real problem first. One thing that occurs to me is the geopolitics of this. By using open-source tools and self-hosting, businesses are insulating themselves from some of the volatility of the big tech giants. If a specific provider changes its terms of service or gets caught up in a regulatory battle, a business using Dify and Lite-L-L-M can just point their A-P-I key somewhere else and keep running. That kind of resilience is very much in line with the worldview we often talk about on this show. American innovation is driving a lot of this, but the open-source movement is ensuring that the power is distributed and not just concentrated in a few boardrooms in Silicon Valley.
It is about sovereignty. Digital sovereignty for businesses and individuals. When you host your own agentic platform, you own your logic, you own your data, and you own your workflows. No one can turn you off or double your prices overnight without you having a choice. That is a very conservative, pro-business approach to technology. It is about building on solid ground rather than renting space on a shifting sand dune.
Well said, Herman. I think we have given Daniel a lot to chew on. This whole area of agentic A-I is moving so fast that I am sure we will be revisiting it in another fifty episodes or so. But for now, the path seems clear. Move toward unified, open-source platforms that give you visibility and control.
And don't be afraid to experiment. The cost of failure is so low right now because the tools are so accessible. You can spin up a Docker container, try out a workflow, and if it doesn't work, you just delete it and try again. It is a playground for productivity.
I love that. A playground for productivity. Well, I think that is a good place to wrap up our core discussion for today. Before we go, I want to remind everyone that if you are finding these deep dives helpful, we would really appreciate it if you could leave us a quick review on Spotify or whatever podcast app you are using. It genuinely helps other people find the show and keeps us motivated to keep digging into these weird prompts that Daniel sends our way.
Yeah, it really does make a difference. And if you want to reach out or see our full archive of over nine hundred episodes, head over to our website at myweirdprompts dot com. You can find our R-S-S feed there and a contact form if you have a topic you want us to tackle. We have covered everything from battery chemistry to the future of the Middle East, so there is plenty to explore.
Definitely. We actually mentioned a few related episodes today, like episode seven hundred ninety-five on sub-agent delegation and episode eight hundred forty-one on A-I gateways. If you are serious about building what we talked about today, those are great companion listens. You can search for them right on the website.
Alright, I think that is it for this one. Thanks for the prompt, Daniel, even if you are just in the other room probably already tinkering with some of these tools.
He probably is. Alright everyone, thanks for listening to My Weird Prompts. We will be back soon with another deep dive. Until then, stay curious and keep building.
See ya next time!
