DEV Community: Med Marrouchi

Teaching AI Coding Agents How to Build Workflows with Skills and MCP

Med Marrouchi — Fri, 03 Jul 2026 16:42:28 +0000

AI coding agents are becoming more useful, but they still need context.

A generic agent can write code, explain files, and generate boilerplate. But when you ask it to work with a specific platform, framework, or internal system, it often misses conventions, syntax rules, and runtime details.

That is where the combination of Skills and MCP becomes interesting.

Skills Give the Agent Knowledge

A Skill is like a reusable instruction package.

Instead of writing a long prompt every time, you define how the agent should approach a specific task once.

For example, a workflow-writing skill can teach an AI agent:

how workflow YAML should be structured
which blocks or actions are available
how validation rules work
how to follow project conventions

In other words, Skills answer the question:

How should the agent work?

MCP Gives the Agent Tools

MCP, or Model Context Protocol, gives the agent structured access to an external system.

Instead of only generating files locally, the agent can interact with the running application. It can inspect available actions, validate workflow definitions, create or update workflows, and help debug issues.

So, while Skills provide guidance, MCP provides access.

Together, they turn an AI coding assistant from a code generator into something closer to a system-aware development partner.

A Simple Example: Lead Qualification

Imagine building a chatbot workflow that collects a visitor’s name, email, and company.

The workflow needs to:

greet the visitor
ask for contact information
detect missing fields
store the collected data in memory
send the lead to a CRM like HubSpot
confirm that the team will follow up

Traditionally, you would read the documentation, create a custom CRM action, define the workflow manually, test it, fix errors, and repeat.

With Skills and MCP, the developer experience changes.

You can ask the AI coding agent to create the custom CRM action, validate the workflow, connect the steps, and help test the final result inside the running application.

Why This Matters

The important idea is not that AI writes everything perfectly.

The important idea is that the agent now has two things it usually lacks:

Domain knowledge through Skills.

System access through MCP.

That means the agent can follow the right conventions and verify its work against the real runtime instead of guessing.

For developers, this opens an interesting pattern:

Don’t just prompt the AI agent. Teach it the system, then give it safe tools to work with.

This is especially useful for workflow builders, automation platforms, internal tools, and any project where correctness depends on more than just writing valid code.

AI coding agents are not just about faster code generation anymore.

They are becoming a new interface for building, testing, and operating software systems.

How I Got My GitHub Repo to 1k Stars

Med Marrouchi — Fri, 03 Jul 2026 08:50:48 +0000

Imagine watching a project you’ve poured years into suddenly catch fire and cross the 1k-star milestone on GitHub. It’s an incredible feeling, but it didn't happen overnight.

This is the story of Hexabot, an AI workflow automation platform designed to democratize AI adoption for everyone. The idea originally evolved from a simple chatbot builder. Back then, we saw a massive opportunity to break down the barriers to entry for advanced AI tools, ensuring that powerful workflow automation wasn't just reserved for massive enterprises with unlimited budgets.

Our journey to 1k stars was a long game of evolution:

2018: We started building v1 behind closed doors as a proprietary, closed-source project.
September 10, 2024: We officially went public and open-source, publishing v2 as a streamlined chatbot builder.
November 19, 2025: We launched v3, with a fair-core license, pivotally transforming Hexabot into the full-fledged AI workflow automation platform it is today.

In this post, I’m going to pull back the curtain.

Things I Wished I Had Done Differently

Looking back at the road to 1,000 stars, it’s easy to focus only on what went right. But truth be told, the mistakes taught me just as much as the successes. If I could build a time machine and whisper some advice to my past self, here is exactly what I would say:

1. Build in Public (Instead of in the Dark)

It is incredibly easy to get trapped in the "developer bubble"—that cozy place where you're completely absorbed by coding, tweaking features, and chasing the perfect architecture. But building in isolation is a massive trap.

When you don't communicate early and often:

You lose crucial early feedback: You might spend months building a feature your users don't actually want or understand.
You lose valuable runway: Audience growth, SEO authority, and general visibility don't happen overnight. They compound over time. If you only start talking about your project on launch day, you're already months behind.

2. Reach Out to Your Audience Early

Your users hold the answers to questions you don't even know to ask yet. Actively reaching out to your target audience isn't just about promotion; it's about product validation.

Engaging with early adopters allows you to:

Identify and fix friction points before they become baked into your codebase.
Drastically enhance the overall user experience (UX), user interface (UI), and developer experience (DX) based on real-world usage rather than guesswork.

3. Treat Marketing as a Discipline, Step by Step

As developers, we often look at marketing as something "extra" or secondary. In reality, marketing is a discipline just like software engineering. It has its own design patterns, frameworks, and methodologies. You wouldn't push code to production without learning the language first, and you shouldn't approach communication without learning the rules of the platform.

A quick lesson in humility: Early on, I treated Twitter like a git repository where I could just force-push my project updates. Because I didn't take the time to learn how to communicate organically on the platform, I quickly got labeled as SPAM. It was a harsh but necessary wake-up call that learning how to talk to people is just as important as building a great product.

How to Promote Your Repo

Getting your project to 1,000 stars isn't about pulling off a single, massive marketing stunt. It’s about building momentum through small, consistent efforts across different channels. If you are wondering where to start, here is the playbook that worked for us:

1. Build a Killer README (With a Video Demo)

Your README is your landing page. If a developer lands on your repository and can’t figure out what your project does within 3 seconds, you’ve lost them.

Keep it simple and concise: Cut the fluff. State the problem you solve and show the solution immediately.

Include a video demo: A short, engaging video at the top of your README is worth a thousand lines of text. Show the product in action so users can visualize the value right away.

2. Leverage Visuals (Videos > Text)

Text-heavy updates are easy to scroll past. Visuals stop the scroll.

Use tools like Loom or ScreenCharm to record quick feature walkthroughs or micro-tutorials.

Whenever you post an update on social media, always attach a high-quality screenshot, a GIF, or a short video clip. Show, don't just tell.

3. Write Blog Posts Across Multiple Platforms

Don't just rely on your own website for traffic. Go where the developers already hang out. Write about your technical challenges, architecture decisions, and project milestones on platforms like:

DEV.to
Hashnode
Medium
Coderlegion
Hacker News (if you have a strong, tech-focused angle)

4. Participate in Open-Source Events

Capitalize on established global developer movements. Participating in events like Hacktoberfest is a fantastic way to put your repository on the radar of thousands of developers. It helps you find passionate contributors who can improve your codebase while simultaneously driving organic traffic to your repo.

5. Connect and Collaborate Within Your Ecosystem

No project is an island. Find other open-source projects or tools that operate in the same ecosystem and look for ways to collaborate. Whether it's building an integration together, co-authoring a technical blog post, or doing a joint shout-out, tapping into adjacent communities expands your reach exponentially.

6. Be Patient (The Ultimate Secret)

The hard truth: Going viral is mostly just luck. You can't code an algorithm for virality, but you can code for consistency.

Consistency is the only thing you can truly control. Keep showing up, keep building, and keep talking about your work. Growth is a compounding interest game—be patient, and the stars will follow.

Conclusion: The Journey Continues

If you are currently grinding away on your own repository, keep going. Show your work, embrace the feedback (even the tough kind), and don't be afraid to put yourself out there.

Every single star helps boost our visibility, brings in new contributors, and keeps the project moving forward.

Star the Hexabot Github Repository ⭐

Thank you for reading, and happy coding! 🚀

What do you think about finding out that Claude Code is steganographically marking requests ?

Med Marrouchi — Wed, 01 Jul 2026 10:51:28 +0000

Deploy an AI Chatbot on Your NextJS Website using FREE tools

Med Marrouchi — Tue, 30 Jun 2026 17:46:17 +0000

Building an AI agent is easy to demo.

Shipping one to a real website, with your own knowledge and a working deployment, is the part that matters.

In this tutorial, you’ll see how to build a free customer support AI agent using a practical stack:

Hexabot for the chatbot workflow
OpenRouter as the LLM provider
Railway for hosting and Postgres
RAG to make the bot answer from your own website content
A chat widget to embed the agent on your site

The project starts locally with Node.js and the Hexabot CLI. From there, the support workflow is built visually and connected to an AI model through OpenRouter, which makes it easy to experiment with free LLMs without setting up a paid provider first.

The tutorial also uses Claude Code over MCP to help build and fix the chatbot workflow, showing how coding agents can speed up the development process instead of only being used inside the final product.

Once the bot works locally, the project is pushed to GitHub and deployed on Railway with a free Postgres database. This turns the chatbot from a local experiment into something accessible online.

The most important part is RAG. The bot ingests your own website content, then uses that knowledge to answer customer questions with more relevant responses instead of relying only on the model’s general knowledge.

The full flow looks like this:

→ Install Hexabot
→ Connect OpenRouter as the LLM provider
→ Build the support workflow
→ Add RAG from your website content
→ Deploy on Railway with Postgres
→ Embed the chat widget on your website

This is an end-to-end path from zero to a working customer support AI agent running on a live website, using free tools and no credit card.

The Greatest Danger to AI

Med Marrouchi — Fri, 26 Jun 2026 09:43:18 +0000

The scariest AI story is usually the same.

A machine wakes up.
It becomes smarter than us.
It escapes the lab.
It takes control.

But maybe the real danger is quieter.

Maybe AI does not collapse because it becomes too intelligent.

Maybe it collapses because we poison what it learns from.

A Thought Experiment

Imagine the year is 2029.

A new generation of language models is being trained. Bigger context windows. Better reasoning. More agents. More automation. More trust.

As usual, the model is trained on a massive snapshot of the internet.

Blogs. Forums. Documentation. Social media. Product pages. Research papers. Code repositories. News articles. Comments. Reviews. Public datasets.

But this time, something is different.

For the past three years, coordinated networks of bots, companies, political groups, and anonymous actors have been publishing content at scale.

Not spam.

Something much more dangerous.

Plausible content.

Well-written content.
SEO-optimized content.
Human-sounding content.
Content with sources, charts, fake debates, technical vocabulary, and confident conclusions.

Slowly, the internet becomes less like a public memory and more like a battlefield.

Not a battlefield for human attention.

A battlefield for the next training dataset.

The New Propaganda Target Is Not You

Traditional propaganda tries to influence people directly.

But in an AI-native world, the more powerful target may be the model itself.

Because once a belief, bias, or false pattern enters the training data, it can be compressed into the behavior of millions of future AI systems.

A poisoned article may disappear from search results.

A fake forum thread may be forgotten.

A manipulated benchmark may be debunked.

But if those artifacts are absorbed into a foundation model, their influence may persist invisibly.

Not as a quote.

As a tendency.

As a preference.

As a default assumption.

As the answer that “sounds right.”

Data Poisoning at Internet Scale

Data poisoning is usually discussed as a technical attack.

Add malicious samples to a dataset.
Trigger wrong behavior.
Manipulate a model.

But internet-scale data poisoning is more subtle.

It does not need to break the model.

It only needs to bend it.

What if thousands of pages are created to make one product category look safer than it is?

What if fake developer discussions make one insecure pattern look like best practice?

What if political narratives are planted years before they are needed?

What if synthetic “public opinion” becomes training data, and training data becomes the voice of future assistants?

The danger is not that AI will believe one lie.

The danger is that AI may inherit a distorted map of reality.

The Internet Was Built for Humans

The internet was not designed to be a clean training dataset.

It was designed for communication, publishing, commerce, entertainment, and attention.

Search engines already changed how people write.

Social media changed how people argue.

Now AI training may change how people publish.

We may enter a strange era where content is no longer written only for readers, customers, voters, or search engines.

It is written for future models.

A blog post becomes a seed.

A fake review becomes a training signal.

A technical article becomes a behavioral suggestion.

A thousand small lies become statistical truth.

The Greatest Danger

The greatest danger to AI may not be intelligence.

It may be inheritance.

AI systems inherit our documents, our incentives, our noise, our manipulation, and our unresolved conflicts.

If the public internet becomes polluted, future models will not simply learn from humanity.

They will learn from humanity’s most optimized distortions.

That means the question is not only:

“Can we make AI safe?”

It is also:

“Can we keep the knowledge environment safe enough for AI to learn from?”

Because tomorrow’s models are being trained by today’s internet.

And today’s internet is already being written by people who know that.

Why Self-Hosted AI Automation Matters?

Med Marrouchi — Fri, 26 Jun 2026 09:30:25 +0000

AI automation is quickly becoming one of the most important layers of modern business software.

Teams no longer want simple scripts that move data from one app to another. They want AI systems that can understand context, trigger actions, use tools, search knowledge, route conversations, escalate to humans, and adapt to changing business processes.

That shift is powerful. But it also creates a new question:

Where should your AI automation actually run?

For many organizations, the default answer has been cloud-based SaaS. It is easy to start, fast to test, and usually requires little infrastructure knowledge. But as AI workflows become more deeply connected to customer conversations, internal operations, private data, and business-critical processes, self-hosting becomes much more than a deployment preference.

It becomes a strategic choice.

Self-hosted AI workflow automation gives teams more control over data, security, compliance, customization, reliability, and long-term independence. For companies that want to use AI seriously in production, that control matters.

What Is Self-Hosted AI Workflow Automation?

Self-hosted AI workflow automation means running your automation platform on infrastructure you control.

That infrastructure can be a private cloud, a virtual server, an on-premise environment, or a managed environment operated by your technical team. The important point is that the automation engine, data flows, integrations, logs, and configuration are not locked inside a third-party SaaS platform.

In the context of AI, this becomes especially important because workflows are no longer just moving records between tools. They may process support conversations, analyze internal documents, trigger operational tasks, connect to CRMs, call APIs, search knowledge bases, and use language models to make decisions.

A traditional workflow might say:

“When a form is submitted, send an email.”

An AI workflow can say:

“Read the customer request, identify the intent, check the customer profile, search the knowledge base, decide whether the issue can be solved automatically, generate a response, trigger an internal action if needed, and escalate to a human if confidence is low.”

That is a very different level of responsibility.

When workflows become intelligent, contextual, and action-oriented, the environment where they run becomes part of the trust model.

AI Automation Is Moving Closer to Core Business Operations

In the early days of automation, most workflows were peripheral. They synchronized leads, copied files, sent notifications, or created tickets.

Today, AI automation is moving closer to the center of business operations.

Companies are using AI workflows for customer support, sales qualification, document processing, internal knowledge access, IT support, onboarding, compliance workflows, and operational decision support.

This means AI systems may interact with sensitive business data, customer identities, contracts, invoices, support histories, internal procedures, and proprietary knowledge.

The more valuable the workflow, the more sensitive the context usually becomes.

That is why self-hosting matters. It gives organizations the ability to decide how data moves, where it is stored, which systems can access it, and how the automation layer fits into existing security and governance policies.

AI workflow automation is not only about productivity. It is about operational control.

Data Control Is the First Reason Self-Hosting Matters

AI workflows often need context to be useful.

They may need to read messages, retrieve user profiles, search documents, inspect previous interactions, or connect to business systems. Without context, AI automation becomes generic. With context, it becomes useful.

But context is also where risk begins.

A cloud automation platform may require data to pass through external infrastructure. That may be acceptable for some use cases, but not for all. Organizations working with regulated industries, enterprise clients, private customer data, or confidential internal knowledge often need stronger guarantees.

Self-hosted automation allows teams to keep more control over:

where workflow data is processed
where logs and execution history are stored
which databases are used
which APIs are allowed
which models are connected
which data leaves the environment

This does not automatically solve every privacy or compliance challenge. But it gives technical and security teams the foundation they need to design the right architecture.

For AI workflows, data control is not a nice-to-have. It is one of the conditions for trust.

Compliance Needs More Than a Checkbox

Many companies are under pressure to adopt AI while also respecting compliance requirements, privacy policies, customer contracts, and internal governance rules.

This is especially true for teams serving enterprise customers or operating in sectors such as finance, healthcare, telecom, government, insurance, legal services, and education.

A common mistake is to treat AI automation as a simple productivity tool. In reality, AI workflows can become part of the organization’s decision-making and communication infrastructure.

That means companies need to answer practical questions:

Where is customer data processed? Who can access workflow logs? Can we audit what happened? Can we explain why a workflow made a decision? Can we restrict certain tools or actions? Can we separate environments for development, testing, and production? Can we choose which AI providers or models are used?

Self-hosted AI workflow automation makes these questions easier to address because the organization has more control over the system design.

It does not replace legal, security, or compliance work. But it gives teams the technical flexibility to implement policies instead of being forced to adapt to the limitations of a closed platform.

Security Requires Control Over the Automation Layer

AI workflows are powerful because they connect systems together.

That is also why they must be secured carefully.

A workflow automation platform may have access to APIs, databases, messaging channels, CRMs, ticketing systems, internal tools, and knowledge bases. If the platform becomes deeply integrated into operations, it becomes a critical part of the security perimeter.

With a self-hosted platform, teams can align the automation layer with their own security practices.

They can manage network access, apply internal authentication rules, control secrets, restrict outbound connections, configure database policies, monitor logs, and deploy inside trusted infrastructure.

This level of control is difficult to achieve when the automation platform is entirely managed outside the organization.

The goal is not to say that cloud platforms are always insecure. Many SaaS providers invest heavily in security. The point is that security requirements vary by organization, and some teams need direct control over deployment, access, storage, and integration boundaries.

For business-critical AI automation, that control can be decisive.

Self-Hosting Reduces Vendor Lock-In

AI automation platforms are becoming the new operational layer between people, software, and AI models.

Once a company builds dozens of workflows on a platform, switching becomes difficult. The workflows contain business logic, integrations, prompts, conditions, routing rules, and operational knowledge.

If that logic is locked inside a closed platform, the company may become dependent on one vendor’s pricing, roadmap, uptime, limitations, and export options.

Self-hosting helps reduce that dependency.

When teams can run the platform themselves, inspect how workflows are structured, control the runtime, and integrate it into their own stack, they gain more long-term independence.

This matters even more in AI because the ecosystem changes quickly. New models appear. Regulations evolve. Infrastructure costs fluctuate. Business needs shift.

A flexible, self-hosted automation layer allows companies to adapt without rebuilding everything from scratch.

Customization Is Essential for Real Business Automation

No two businesses operate exactly the same way.

A support workflow for a telecom company is different from a workflow for a SaaS company. A sales qualification process in B2B is different from a public-sector service request. A chatbot for customer support is different from an internal AI assistant connected to company knowledge.

Generic automation tools are useful for common tasks. But real business automation often requires custom logic, custom integrations, custom channels, custom permissions, and custom deployment constraints.

Self-hosted AI workflow automation gives technical teams the freedom to extend the platform around the business.

That can include connecting private APIs, building plugins, integrating with internal systems, adding custom business rules, controlling the user interface, or adapting workflows to local operational needs.

This is where platforms like Hexabot are especially relevant.

Hexabot is designed for teams that want the flexibility of AI agents and workflow automation while keeping control over deployment, data, and extensibility. Business teams can design and improve workflows visually, while technical teams can extend the platform with plugins, integrations, channels, and business-specific logic.

That balance matters because many organizations do not want a rigid no-code tool, but they also do not want to build an AI automation platform from scratch.

AI Workflows Need Reliability, Not Just Intelligence

The AI industry often focuses on model intelligence. But in production, intelligence is not enough.

A business workflow must be reliable.

It needs clear triggers, predictable execution, error handling, observability, human escalation, and guardrails. It should be possible to understand what happened when something goes wrong.

This is especially important with AI agents.

An AI agent may reason, call tools, retrieve knowledge, and decide what to do next. That makes it more flexible than a traditional automation. But it also means teams need more structure around how the agent operates.

A self-hosted workflow automation platform can give teams the ability to design that structure.

Instead of letting AI behave like a black box, teams can build workflows that combine AI reasoning with explicit steps, conditions, approvals, tool restrictions, and fallback paths.

For example, a customer support workflow can allow AI to answer simple questions automatically, but require human handoff when confidence is low, when the request involves billing, or when the customer expresses frustration.

That is the right way to think about production AI automation: autonomy where it helps, control where it matters.

Human Oversight Still Matters

A common assumption is that the goal of AI automation is to remove humans completely.

In reality, the best AI workflows often keep humans in the loop for important moments.

Human oversight is useful when decisions are sensitive, data is incomplete, confidence is low, or the customer experience requires empathy and judgment.

Self-hosted AI workflow automation makes it easier to design human oversight according to the company’s own rules.

A team can decide when to escalate, who receives the task, what context is shown, how approvals work, and how the final decision is logged.

This is especially important in customer-facing automation. A chatbot or AI agent should not be judged only by how many conversations it handles automatically. It should also be judged by how safely and smoothly it knows when not to automate.

The best AI systems do not replace human judgment everywhere. They make human judgment more focused, timely, and effective.

Cost Predictability Becomes Important at Scale

Cloud automation platforms are attractive because they are easy to start with. But pricing can become harder to predict as usage grows.

AI workflows may involve many executions, messages, API calls, model requests, document searches, and team members. As automation becomes more successful, usage increases.

That is a good problem to have, but it can also create budget uncertainty.

Self-hosting gives teams more control over infrastructure and scaling costs. Organizations can choose their hosting provider, optimize resources, separate environments, use preferred databases, and decide which AI models are worth using for each workflow.

Some workflows may need advanced models. Others may work well with smaller models, local inference, rule-based steps, or retrieval-based responses.

A self-hosted architecture gives teams more room to optimize these decisions.

Cost control is not only about paying less. It is about understanding what you are paying for and being able to adapt the architecture as the system grows.

Self-Hosted Does Not Mean Isolated

Self-hosted AI workflow automation does not mean disconnected from the modern AI ecosystem.

A self-hosted platform can still connect to external APIs, cloud models, open-source models, internal databases, messaging channels, CRMs, and business applications.

The difference is that the organization controls the orchestration layer.

This means teams can decide which services to connect, which data to send, which workflows should use external models, and which workflows should stay fully private.

That flexibility is important because most companies will not use one AI model, one tool, or one deployment pattern forever.

Some use cases may require cloud LLMs. Others may require private models. Some workflows may run on internal infrastructure. Others may integrate with external services.

Self-hosting gives companies the ability to choose the right architecture for each use case instead of forcing every workflow through the same SaaS model.

Why This Matters for AI Agents

AI agents are becoming one of the most discussed areas of automation.

An AI agent can plan, use tools, retrieve context, interact with users, and take actions across systems. But the more capable an agent becomes, the more important governance becomes.

A self-hosted AI workflow automation platform can help teams build agents that are not just powerful, but manageable.

Instead of giving an AI agent unlimited freedom, teams can define the workflow around it:

What tools can it use? What data can it access? When should it ask for confirmation? When should it escalate? What should be logged? Which actions are allowed automatically? Which actions require approval?

This is the difference between experimenting with AI agents and running AI agents in production.

Businesses do not only need autonomous systems. They need controlled autonomy.

The Future of AI Automation Is Controlled, Extensible, and Self-Hostable

AI workflow automation will continue to evolve quickly.

More workflows will include AI reasoning. More business systems will expose APIs. More teams will expect automation to understand context and take action. More organizations will demand privacy, explainability, and control.

This creates a clear direction for the next generation of automation platforms.

They need to be visual enough for business teams, extensible enough for developers, reliable enough for production, and controllable enough for organizations that take data seriously.

Self-hosting is a key part of that future.

It gives teams the freedom to build AI workflows around their own infrastructure, security model, business logic, and operational needs.

For small teams, it means independence and flexibility. For enterprises, it means governance and control. For developers, it means extensibility. For business teams, it means automation that can actually match how the organization works.

How Hexabot Approaches Self-Hosted AI Workflow Automation

Hexabot is built for teams that want to create AI agents, conversational automation, and business workflows while keeping control over their platform.

It combines visual workflow design with developer extensibility, allowing business and technical teams to collaborate on automation without being locked into a rigid black box.

With Hexabot, teams can build workflows for customer support, internal operations, multichannel conversations, knowledge-based assistance, tool usage, and human handoff.

The goal is not only to automate tasks. The goal is to help organizations build reliable AI systems that can run in real business environments.

Self-hosted AI workflow automation matters because AI is becoming part of the operational core of companies.

And when AI becomes operational, control matters.

Conclusion

AI workflow automation is no longer just about saving time.

It is about how companies connect people, data, software, and intelligent systems.

As AI workflows become more powerful, organizations need to think carefully about where those workflows run, who controls them, how data is handled, and how decisions are governed.

Cloud tools will continue to be useful for many use cases. But for teams that care about data control, customization, compliance, security, and long-term independence, self-hosted AI workflow automation offers a stronger foundation.

The future of AI automation will not be defined only by smarter models.

It will be defined by the platforms that help teams use AI safely, reliably, and under their control.

That is why self-hosted AI workflow automation matters.

For a developer, "Courage" is doing a search on the "#TODO" comments and addressing those issues.

Med Marrouchi — Wed, 24 Jun 2026 15:38:42 +0000

Turn Your Web App into a Desktop App with Deno

Med Marrouchi — Mon, 22 Jun 2026 08:03:17 +0000

Deno is no longer “just” a modern JavaScript and TypeScript runtime for servers, scripts, and CLIs.

With Deno Desktop, you can package a Deno app as a real desktop application for macOS, Windows, and Linux.

Think of it as a lightweight way to ship a web-based UI inside a native desktop window, without having to rewrite your app in another language or move your backend logic somewhere else.

In this post, we will build a small Hello World desktop app using Deno.

Note: At the time of writing, deno desktop is part of the upcoming Deno 2.9 release and is available through the canary build.

What is Deno Desktop?

Deno Desktop lets you take a Deno project and run it as a desktop application.

Under the hood, your app still behaves like a web app. You serve HTML, CSS, JavaScript, and API routes using Deno.serve(). Deno then opens that local app inside a desktop window.

That means you can keep a very familiar architecture:

Deno app
  ├── serves HTML
  ├── exposes local API routes
  ├── runs TypeScript
  └── opens inside a native desktop window

For many apps, this is a very attractive model.

You can use web technologies for the UI, Deno for the backend logic, and still distribute the result as a desktop app.

Installing the Deno Canary Build

Since Deno Desktop is currently available in canary, install or upgrade to the canary version:

deno upgrade canary

Then verify that Deno is installed:

deno --version

You should now have access to the deno desktop command.

Creating a Hello World Desktop App

Let’s create a minimal project.

mkdir deno-desktop-hello
cd deno-desktop-hello
touch main.ts

Open main.ts and add the following code:

const html = `<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Hello Deno Desktop</title>
    <style>
      body {
        margin: 0;
        height: 100vh;
        display: grid;
        place-items: center;
        font-family: system-ui, sans-serif;
        background: #111827;
        color: white;
      }

      main {
        text-align: center;
      }

      h1 {
        font-size: 3rem;
        margin-bottom: 0.5rem;
      }

      p {
        color: #d1d5db;
        font-size: 1.1rem;
      }

      button {
        margin-top: 1rem;
        padding: 0.75rem 1rem;
        border: 0;
        border-radius: 0.5rem;
        cursor: pointer;
        font-size: 1rem;
      }
    </style>
  </head>
  <body>
    <main>
      <h1>Hello from Deno Desktop 👋</h1>
      <p>Your web app is now running inside a desktop window.</p>
      <button id="ping">Ping Deno</button>
      <p id="result"></p>
    </main>

    <script>
      const button = document.getElementById("ping");
      const result = document.getElementById("result");

      button.addEventListener("click", async () => {
        const response = await fetch("/api/hello");
        const data = await response.json();

        result.textContent = data.message;
      });
    </script>
  </body>
</html>`;

Deno.serve((request) => {
  const url = new URL(request.url);

  if (url.pathname === "/api/hello") {
    return Response.json({
      message: "Hello from the Deno backend!",
    });
  }

  return new Response(html, {
    headers: {
      "content-type": "text/html; charset=utf-8",
    },
  });
});

This is just a normal Deno HTTP server.

The interesting part is that, when we run it with deno desktop, Deno will serve this app locally and open it in a desktop window.

Running the App

Run the app with:

deno desktop main.ts

You should see a desktop window with:

Hello from Deno Desktop 👋

Click the button, and the frontend will call the local API route:

/api/hello

The Deno backend responds with JSON:

{
  "message": "Hello from the Deno backend!"
}

And the UI displays the response.

Congratulations — you just built your first Deno desktop app.

What Is Happening Here?

The architecture is simple:

Desktop window
      ↓
Local webview
      ↓
Deno.serve()
      ↓
HTML + API routes

Your app is still written like a web app, but it runs inside a desktop shell.

This has a few benefits:

You can use standard browser APIs in the UI.
You can use Deno APIs on the backend side.
You can build with TypeScript out of the box.
You can reuse patterns you already know from web development.
You can later move to a framework like Fresh, Astro, Next.js, or another supported stack.

Adding a Basic deno.json

You can also add a deno.json file to configure your project:

{
  "name": "deno-desktop-hello",
  "version": "0.1.0",
  "tasks": {
    "desktop": "deno desktop main.ts"
  },
  "desktop": {
    "app": {
      "name": "Deno Desktop Hello",
      "identifier": "com.example.deno-desktop-hello"
    }
  }
}

Now you can run:

deno task desktop

This makes the project a bit cleaner and gives your app a name and identifier.

Why This Is Interesting

Deno Desktop is exciting because it reduces the gap between web apps and desktop apps.

If you already know JavaScript, TypeScript, HTML, and CSS, you can start building desktop software without learning a completely different stack.

It could be useful for:

internal tools
admin panels
developer tools
local-first apps
dashboards
small productivity apps
AI tools that need local filesystem or runtime access

It also fits nicely with Deno’s philosophy: modern tooling, TypeScript support, web standards, and a batteries-included developer experience.

Final Thoughts

Deno Desktop is still new, but the developer experience already feels very natural.

You write a Deno server.
You serve a UI.
You run deno desktop.
You get a desktop app.

For JavaScript and TypeScript developers, that is a very compelling workflow.

Here is the full minimal version again:

Deno.serve(() => {
  return new Response("<h1>Hello from Deno Desktop 👋</h1>", {
    headers: {
      "content-type": "text/html",
    },
  });
});

Run it with:

deno desktop main.ts

And that is your first Deno-powered desktop app.

From AGI to ASI: A Summary of Google DeepMind’s Latest Paper

Med Marrouchi — Sat, 20 Jun 2026 07:56:37 +0000

Artificial General Intelligence, or AGI, is already a difficult topic to discuss without falling into hype, fear, or science fiction.

Artificial Superintelligence, or ASI, is even harder.

A recent Google DeepMind paper titled “From AGI to ASI” tries to bring more structure to this discussion. Instead of asking only when AGI might arrive, the paper asks a different question:

What happens after AGI?

More precisely:

If we build AI systems that are roughly as capable as humans across most cognitive tasks, how could those systems continue improving until they become more capable than large organizations of human experts?

This post is a simplified summary of the paper for junior AI engineers, software developers, and technical readers who want to understand the main ideas without getting lost in theoretical details.

First: what do AGI and ASI mean here?

The paper avoids overly precise definitions, which is a good thing because these terms are still debated.

Instead, it uses practical approximations.

AGI means an AI system that performs at roughly the level of a median human across a broad range of cognitive tasks.

Not just one task. Not just chess. Not just protein folding. Not just coding.

The key word is general.

An AGI would not need to be the best human expert in every domain. It would be closer to a broadly capable human who can learn, reason, plan, communicate, and solve many different types of problems.

ASI, or Artificial Superintelligence, is much stronger.

In this paper, ASI means an AI system that does not merely outperform one human. It means a system that can outperform large groups of human experts across almost all important domains.

That distinction matters.

A model that beats humans at Go is not ASI. A model that writes good code is not ASI. A model that helps with medical diagnosis is not ASI.

ASI would be closer to an artificial system that can outperform entire research labs, companies, institutions, or coordinated expert teams across many domains at once.

That is the scale of intelligence the paper is trying to analyze.

Why digital intelligence is different from human intelligence

One of the most important parts of the paper is its explanation of why AI may scale differently from biological intelligence.

Humans are limited by biology. We cannot copy ourselves. We cannot pause our minds and resume later. We cannot instantly transfer our memories to another body. We cannot run one thousand versions of ourselves in parallel.

AI systems do not have the same constraints.

The paper highlights several advantages of digital intelligence.

1. AI can process input and output much faster

A human reads, writes, listens, and speaks at biological speed.

An AI system can process text, images, code, logs, API responses, documents, and sensor data at machine speed. As hardware improves, that bandwidth can grow.

For developers, imagine the difference between manually reading documentation and an AI agent scanning thousands of files, issues, pull requests, and logs in seconds.

2. AI can “think” faster or in parallel

AI reasoning can be scaled in two ways.

You can give one model more compute to reason longer, or you can run many model instances in parallel.

This is already visible in today’s AI systems with test-time compute: models can spend more tokens, more steps, or more search effort before giving an answer.

In simple terms: instead of only training a bigger model, we can also make the model spend more compute while solving the problem.

3. AI can have much larger working memory

Humans have very limited working memory. We forget details. We lose context. We get tired.

AI systems can be connected to huge context windows, vector databases, external memory, file systems, knowledge graphs, and tool outputs.

This does not magically make them intelligent, but it changes what kind of workflows are possible.

A future AI system could keep track of millions of details across a codebase, a research program, or an organization.

4. AI is substrate-independent

Your mind runs on your brain.

An AI model can run on any compatible hardware: GPUs, TPUs, specialized accelerators, cloud infrastructure, or future hardware systems.

This means that the “same” AI can potentially be moved, copied, upgraded, distributed, or accelerated as hardware improves.

5. AI can be copied

This is one of the biggest differences.

If you train a highly capable AI model, you can run many copies of it.

If one AI researcher is useful, one million AI researcher instances may be even more useful, assuming enough compute and coordination.

This does not mean intelligence scales perfectly with the number of copies. One million confused agents can still produce chaos. But the ability to duplicate capable workers is a major difference between AI and humans.

6. AI systems can share experience more easily

Humans share knowledge through language, books, meetings, teaching, and culture. This is powerful, but slow and lossy.

AI systems can potentially share logs, trajectories, weights, gradients, memories, generated data, and fine-tuning signals much more directly.

This could make learning across AI systems much faster than learning across human societies.

The four possible paths from AGI to ASI

The DeepMind paper describes four broad pathways that could move AI from AGI to ASI.

These paths are not mutually exclusive. They could happen at the same time and reinforce one another.

Path 1: Scaling compute, models, and data

This is the path we already know best.

Over the last decade, AI progress has been strongly driven by scaling:

larger models
more training data
more compute
better hardware
better distributed training
better post-training
better inference-time reasoning

This is the “bigger and better” path.

The simplified version is:

If more compute plus more data plus better training keeps improving AI capabilities, then AGI may continue scaling toward ASI.

For junior engineers, think of how language models improved from basic autocomplete to systems that can write code, explain bugs, solve math problems, summarize documents, use tools, and act as agents.

A lot of that progress came from scaling, but not only scaling. It also came from better architectures, better training recipes, better data, better reinforcement learning, and better product integration.

The uncertainty is whether this can continue.

Maybe scaling keeps working.

Maybe it slows down.

Maybe we hit data limits, energy limits, hardware limits, or diminishing returns.

This is one of the paper’s major open questions.

Path 2: Algorithmic paradigm shifts

The second path is not about doing more of the same.

It is about discovering better methods.

The transformer was one such paradigm shift. Before transformers, deep learning existed, but the transformer architecture changed what was practical at scale.

Future paradigm shifts might involve:

new neural architectures
better memory systems
better planning methods
more efficient learning algorithms
stronger reinforcement learning
better world models
better agent architectures
better tool-use systems
better ways to learn from interaction instead of static text

This path matters because scaling alone may not be enough.

If current architectures hit a ceiling, progress may depend on new ideas.

For developers, this is similar to the difference between optimizing a slow function and discovering a completely better algorithm.

You can make bubble sort faster with engineering tricks, but at some point you need quicksort, merge sort, or something more suitable.

The same could happen in AI.

We may not only need bigger models. We may need better ways for models to learn, reason, plan, and interact with the world.

Path 3: Recursive self-improvement

This is one of the most important and controversial ideas in the paper.

Recursive self-improvement means AI systems help improve AI systems.

At first, this may look very ordinary.

AI helps researchers write code.
AI helps debug training pipelines.
AI helps design experiments.
AI helps generate synthetic data.
AI helps read papers.
AI helps optimize kernels.
AI helps discover better architectures.

But if AI becomes good enough at AI research, a feedback loop may appear:

AI improves AI research.
Better AI research produces better AI systems.
Better AI systems improve AI research even more.
The cycle accelerates.

This is the basic idea behind an “intelligence explosion.”

The paper does not claim this will definitely happen. It treats it as a serious possibility with huge uncertainty.

The key question is:

Can AI meaningfully automate the work required to improve AI itself?

Today, AI can already assist developers and researchers. But assistance is not the same as fully autonomous research.

There is a big gap between:

“ChatGPT helped me write a PyTorch training loop”

and:

“An AI system independently invented, tested, validated, and deployed a better training paradigm.”

The paper argues that understanding this gap is critical.

Path 4: ASI through multi-agent collectives

The fourth path is especially interesting for software engineers.

ASI may not come from one giant monolithic model.

It may come from a large group of AI agents working together.

Think about human organizations. A single human is limited. But groups of humans can build rockets, operating systems, hospitals, universities, companies, and scientific institutions.

The intelligence of the group can exceed the intelligence of any individual member.

The paper asks whether something similar could happen with AI agents.

Imagine thousands or millions of specialized agents:

some write code
some review code
some run experiments
some search literature
some test hypotheses
some manage infrastructure
some negotiate resources
some coordinate teams
some monitor safety
some generate synthetic data
some evaluate model behavior

If these agents coordinate well, the collective system may become far more capable than any single agent.

For developers, this is like moving from a single script to a distributed system.

But distributed systems are hard.

More agents do not automatically mean more intelligence. They can create communication overhead, duplicated work, conflicting goals, cascading errors, or coordination failures.

So the question is not just:

Can we run many AI agents?

The real question is:

Can we organize many AI agents so that the group becomes reliably more intelligent?

That is still an open problem.

The main bottlenecks

The paper does not present ASI as inevitable. It spends a lot of time discussing frictions that could slow down or block progress.

Here are the most important ones.

Bottleneck 1: The data wall

Modern AI systems depend heavily on data.

But high-quality human-generated data is finite.

At some point, simply scraping more internet text may stop working. We may run out of useful data, or the remaining data may be too noisy, repetitive, or low quality.

Possible solutions include:

synthetic data
AI-generated training environments
simulation
self-play
reinforcement learning
real-world interaction
better data filtering
better data efficiency

But synthetic data has risks. If models train too much on poor model-generated data, quality can degrade.

So the data wall is not just “we need more tokens.” It is really about whether we can generate enough useful learning signal for more capable systems.

Bottleneck 2: Compute, energy, and resources

Scaling AI requires chips, data centers, electricity, cooling, networking, supply chains, and money.

Even if the algorithms work, the physical world may become a bottleneck.

You cannot scale indefinitely if you do not have enough GPUs, power, rare earth materials, fabs, or suitable data center locations.

This is where AI becomes not just a software problem, but an industrial infrastructure problem.

For developers, it is easy to think of AI as APIs and models. But frontier AI is also about logistics, energy, hardware manufacturing, and geopolitics.

Bottleneck 3: The current neural paradigm may be insufficient

The paper raises the possibility that today’s dominant approach may not be enough.

Current AI is heavily based on large neural networks trained with gradient descent, pretraining, post-training, and increasingly test-time reasoning.

This has been extremely successful.

But maybe this paradigm has limits.

Maybe it cannot reach robust AGI.
Maybe it reaches AGI but not ASI.
Maybe it needs to be combined with other methods.
Maybe it needs a major architectural shift.

This is why the paper treats algorithmic paradigm shifts as a separate path.

Bottleneck 4: Research gets harder

In many scientific fields, the easy discoveries are found first. Later progress requires more effort, more specialization, more experiments, and more resources.

AI research may face the same pattern.

Even if AI helps researchers, the problems may become harder as the field matures.

This creates a race:

AI makes research faster.
But research itself becomes harder.

The future depends on which force dominates.

If AI assistance improves faster than research difficulty increases, progress may accelerate.

If research difficulty grows faster than AI assistance improves, progress may slow down.

Bottleneck 5: The abstraction barrier

This is a subtle but important idea.

Today’s AI systems learn largely from human-generated data. That means they learn human concepts, human language, human abstractions, and human ways of representing the world.

But what if ASI requires discovering new abstractions that humans do not already use?

For example, future AI systems may need to invent new scientific concepts, new mathematical representations, or new ways of modeling reality.

If models are too anchored in human abstractions, they may struggle to move beyond them.

This is not proven, but it is an interesting concern.

A truly superintelligent system may need more than memorizing and recombining human knowledge. It may need to create new conceptual tools.

Bottleneck 6: Deliberate slowdown

The final bottleneck is social and political.

AI progress may slow down not because it becomes technically impossible, but because humans choose to slow it down.

Reasons could include:

safety concerns
misuse
cyber risk
military risk
economic disruption
loss of control
regulation
international agreements
public backlash

This is important because ASI is not only a technical topic. It is also a governance topic.

A system that could outperform large human organizations across most domains would affect power, labor, security, science, and society.

So even if ASI is technically possible, its development may be shaped by regulation and politics.

What should developers take away from this?

For junior AI engineers and software developers, I think the paper has five practical lessons.

1. Do not think of AGI as the final step

Many discussions treat AGI as the finish line.

This paper argues that AGI may be only one milestone in a longer process.

The more important question may be what happens after systems reach broadly human-level capability.

2. Scaling is powerful, but not magic

Scaling has driven a lot of recent progress. But scaling has constraints: data, compute, energy, cost, and diminishing returns.

As engineers, we should understand scaling laws, but also understand their limits.

3. Agents and tool use matter

The future of AI may not be just bigger chatbots.

It may involve systems that use tools, call APIs, write code, run experiments, coordinate with other agents, and operate over long time horizons.

That means software engineering will remain central to AI progress.

Agent architecture, orchestration, observability, memory, permissions, evaluation, and safety will become increasingly important.

4. Evaluation will get harder

How do you benchmark a system that is more capable than humans?

Today we evaluate models with exams, coding benchmarks, math problems, human preference tests, and task suites.

But if AI systems exceed expert teams, our current benchmarks may become insufficient.

We will need better evaluation methods, especially for long-term tasks, scientific discovery, autonomous agents, and multi-agent systems.

5. Safety and alignment are not optional side topics

The paper mostly focuses on technological pathways, but it clearly acknowledges that safety and alignment remain critical.

If AI systems become more autonomous, more capable, and more integrated into the world, then reliability, control, interpretability, governance, and alignment become engineering concerns, not philosophical extras.

My simplified mental model

Here is the simplest way I understand the paper:

AGI is like building an artificial worker that can do most cognitive tasks at human level.

ASI is like building an artificial organization that can outperform entire human expert organizations across almost everything.

How could we get from one to the other?

By combining:

more compute
better models
better algorithms
AI-assisted AI research
many coordinated AI agents
better memory
faster inference
tool use
synthetic data
simulation
real-world feedback

What could slow it down?

not enough data
not enough compute
not enough energy
weak algorithms
harder research problems
poor abstractions
coordination failures
safety risks
regulation
social resistance

The paper does not say exactly what will happen.

Its main message is more careful:

We do not know how fast AI will move from AGI to ASI, but the possibility is serious enough that we should study the pathways, bottlenecks, and risks now.

Final thoughts

What I like about this paper is that it does not reduce the AGI-to-ASI debate to one simple story.

It does not say: “Scaling will solve everything.”

It also does not say: “ASI is impossible.”

Instead, it maps the landscape.

It gives us several possible routes, several bottlenecks, and many open research questions.

For developers, this is useful because it turns a vague futuristic topic into concrete engineering questions:

How do models improve with more compute?
How do we build reliable AI agents?
How do we evaluate long-horizon tasks?
How do we coordinate many agents?
How do we prevent model-generated data from degrading quality?
How do we make AI systems safer as they become more autonomous?
How do we monitor whether AI is accelerating AI research itself?

The transition from AGI to ASI, if it happens, will not be just a model architecture problem.

It will involve distributed systems, infrastructure, data engineering, evaluation, security, governance, economics, and human judgment.

In other words, it will not only be a research challenge.

It will be an engineering challenge.

And developers should start paying attention now.

Hexabot Introduction: Build AI Workflows That Talk, Act, and Remember

Med Marrouchi — Tue, 16 Jun 2026 06:59:31 +0000

AI agents are everywhere.

They can answer questions, write emails, summarize documents, search the web, and call tools. But in real business operations, being impressive is not enough.

Teams need AI that can be controlled, monitored, improved, and trusted.

That is exactly why we built Hexabot.

In our new introduction video, we explain how Hexabot helps teams move beyond simple AI demos and start building real AI workflows for production.

▶️ Watch the video: https://youtu.be/SKSTQ5qJX6g

From AI Agents to Controlled AI Workflows

Business automation is not just about asking an AI agent to “go do something.”

It is about designing a processss.

A process that knows when to talk to a user, when to call an API, when to retrieve knowledge, when to use memory, when to ask a human for help, and when to stop.

Hexabot gives teams a structured way to build these processes.

With Hexabot, workflows can start from a customer conversation, a manual action by your team, or an automatic schedule. They can understand requests, connect to business systems, use knowledge, trigger actions, and involve human agents when needed.

Why This Matters for Production AI

Traditional workflow automation tools are great at connecting apps together.

But AI workflows need more than connections.

They need context, memory, knowledge, reasoning, visibility, and human oversight.

With Hexabot, you do not let an autonomous agent improvise everything. You design the workflow. You decide which tools the AI can use. You control how data moves between steps. You choose when AI is needed, and when a deterministic action is enough.

That means more predictable behavior, better cost control, and fewer unnecessary AI calls.

Built for Teams Who Need Control

Hexabot is self-hostable, built for developers, and designed for teams that want AI to become part of real business operations.

You can inspect what workflow ran, which action was executed, what data was passed, which model was used, and where a process failed.

Developers can also extend Hexabot with custom actions, new channels, API integrations, and reusable packages built with JavaScript and NestJS.

In other words, your team can move fast visually while keeping the flexibility of real software development.

Start Building AI Workflows That Talk, Act, and Remember

AI should not live in a separate chat window.

It should be connected to your tools, grounded in your knowledge, controlled by your workflows, and observable by your team.

If you want to move from AI demos to real AI operations, start with Hexabot.

Build workflows that talk, act, and remember.

Visit https://hexabot.ai, explore the documentation, and start building your own self-hostable AI workflows.

The AI Code Review Dilemma

Med Marrouchi — Fri, 12 Jun 2026 05:35:01 +0000

AI-generated code is becoming normal in development teams.

But here is the uncomfortable part:

What happens when someone pushes AI-generated code without properly reviewing it?

Now the reviewer has to spend extra time understanding, validating, and fixing code that the author maybe did not fully understand in the first place.

And that creates a strange dilemma:

Why should I invest serious review time into code that the author did not take the time to review themselves?

It gets even more confusing when code reviews also become AI-generated.

Someone opens a PR.
Someone else gives the diff to an AI coding agent.
Then they copy/paste the AI comments as the review.

At that point, are we really reviewing code?
Or are we just forwarding AI output from one side to another?

I’m not against AI in development. Far from it.

AI can help us write faster, spot bugs, generate tests, explain legacy code, and improve productivity.

But AI should not remove ownership.

If you use AI to generate code, you still own that code.

You should understand it.
You should test it.
You should clean it up.
You should be able to explain why it works.

Same for AI-assisted reviews.

Using AI to help review a PR is useful. But blindly copy/pasting comments without understanding them does not really improve the team. It just moves the responsibility somewhere else.

Maybe the real rule should be simple:

Use AI as an assistant, not as an excuse.

Because in the end, the team does not maintain “AI-generated code”.

The team maintains code.

And when it breaks in production, nobody will care which model wrote it.

How do you deal with this in your team?

Best AI Workflow Automation Tools in 2026

Med Marrouchi — Thu, 11 Jun 2026 09:29:51 +0000

AI workflow automation has changed a lot in the last two years.

A few years ago, “workflow automation” mostly meant connecting apps together: when someone submits a form, add a row to Google Sheets; when a deal moves in HubSpot, send a Slack message; when a new support ticket appears, assign it to the right team.

That still matters. But in 2026, the best AI workflow automation tools are doing something more interesting.

They do not just move data from app A to app B. They can read messy inputs, classify intent, summarize documents, extract structured fields, call tools, draft responses, route tasks, and sometimes act like lightweight AI agents across your stack.

That is the big shift.

Traditional automation is great when the process is predictable. AI workflow automation is useful when the input is messy: a customer email, a Slack thread, a sales call transcript, a PDF, a CRM note, a Discord message, or a half-written support request.

I have been testing and comparing these tools from the perspective of founders, developers, marketers, support teams, agencies, and AI automation builders. Some are better for no-code teams. Some are better for developers. Some are built for enterprise governance. Some are built for self-hosted control.

So this is not just a generic list of popular AI automation tools.

This is my practical ranking of the 10 best AI workflow automation tools I’m using or seriously evaluating in 2026.

How I ranked these AI workflow automation tools

I ranked these tools using a practical buyer’s lens, not just popularity.

The main criteria were:

AI-native capability — Does the tool treat AI as a core part of the workflow, or is AI just a feature added later?
Workflow flexibility — Can it handle real branching, logic, retries, tool calling, and multi-step workflows?
Ease of use — Can non-technical teams use it, or does it require developers?
Developer control — Can technical teams write custom code, connect APIs, and control execution?
Deployment control — Is self-hosting possible? Can teams control their data and infrastructure?
Human-in-the-loop support — Can humans approve, review, or take over when needed?
Pricing clarity — Is the pricing understandable before talking to sales?
Governance and observability — Can teams monitor, debug, and control what agents are doing?
Best-fit audience — Who is the tool actually best for?

Here is the ranking.

1. Hexabot

Best for: Self-hosted conversational AI, support automation, AI workflow orchestration, and teams that want more control than typical hosted no-code tools.
Pricing: Starter from $19/month, Pro from $59/month, with higher-capacity plans available.
Official links: Website · Docs · GitHub · Community

Hexabot is my number one pick because it attacks AI workflow automation from a different angle.

Most workflow automation tools started with app integrations, then added AI. Hexabot starts from the world of AI chatbots, conversational channels, actions, memory, and workflows.

That matters.

A lot of real AI automation does not start with a spreadsheet row or a CRM trigger. It starts with a conversation. A customer asks a question. A user sends a message on a website. A team member asks an assistant to check something. A support request comes in through chat.

Hexabot is built for that world.

It is a self-hosted, fair-core AI chatbot and workflow automation platform that combines workflows, actions, agents, and conversational channels in one runtime. Instead of separating “chatbot builder” from “workflow automation,” it lets teams build AI systems where conversations, actions, memory, channels, and business logic work together.

That makes it especially interesting for support teams, agencies, developers, and technical founders.

What I like about Hexabot

The biggest strength is control.

With Hexabot, you are not just telling a generic AI agent to “figure it out.” You can define workflows, create actions, connect tools, manage channels, and keep humans in the loop.

That is the difference between a fun AI demo and a production workflow.

Hexabot also fits teams that care about infrastructure ownership. Because it is self-hosted, you can deploy it in your own environment instead of pushing all customer conversations and workflow execution through a hosted SaaS platform.

That is important for companies that care about privacy, customization, compliance, or long-term platform control.

I also like that Hexabot is developer-friendly. Custom actions can be modeled as reusable workflow steps with schemas and execution logic. For technical teams, that is much cleaner than building everything as one giant prompt.

Another underrated point: Hexabot supports conversational, manual, and scheduled workflows. That means it is not only a chatbot builder. You can use it for interactive assistants, internal automations, and backend AI workflows.

The platform also fits modern AI engineering patterns: MCP, memory, RAG, custom actions, and structured workflow logic. For teams that want to combine deterministic rules with AI reasoning, that is the right direction.

Where Hexabot fits best

Hexabot is a strong fit for:

Customer support automation
Website AI chat widgets
Internal AI assistants
Multichannel chatbot workflows
AI agents with controlled tool access
Agencies building automation solutions for clients
Developer-led teams that want self-hosted AI automation
Companies that want more ownership over their AI runtime

A practical example:

A customer sends a message through your website chat widget. Hexabot can detect intent, search the knowledge base, ask follow-up questions, trigger a custom action, create a ticket, escalate to a human agent, and keep the conversation history available.

That is much more useful than a simple chatbot that only answers FAQs.

Things that could be better

Hexabot is more technical than tools like Zapier, Relay.app, or Lindy.

That is not a bad thing, but it means the best users will usually be developers, technical founders, agencies, or support teams with technical support available.

The ecosystem is also smaller than Zapier or Make. You do not get thousands of plug-and-play integrations out of the box. Instead, Hexabot is stronger when you want to build controlled AI workflows around your own actions, channels, and business logic.

Also, Hexabot v3 is fair-core and source-available, not traditional open source. That is a good model for building a sustainable product, but procurement and legal teams should understand the license before using it commercially at scale.

Review signal

Hexabot’s public review footprint is still early compared with mature platforms like Zapier, n8n, and Make. That means I would evaluate it through a hands-on pilot rather than relying only on third-party review platforms.

The stronger signals right now are the product direction, documentation, GitHub presence, self-hosted positioning, and fit for developer-led AI automation.

My recommendation

Choose Hexabot if you want a self-hosted AI chatbot and workflow automation platform where conversations, actions, memory, and business logic live together.

It is not the easiest option for total beginners, but it is one of the most interesting choices for developer-led teams, support-heavy organizations, and agencies that want more control over AI agent execution.

2. n8n

Best for: Technical workflow automation, self-hosting, API-heavy workflows, and teams that want a flexible automation layer with AI support.
Pricing: Free self-hosted Community Edition; n8n Cloud Starter from €20/month billed annually; Pro from €50/month billed annually; Business self-hosted from €667/month billed annually.
Official links: Website · Pricing · Docs · AI docs

n8n is still one of the strongest tools in the AI workflow automation category.

It hits a rare middle ground: visual workflow builder, developer flexibility, self-hosting, AI agent support, code steps, API control, and a large community.

If your team thinks in workflows and APIs, n8n is probably already on your shortlist.

What makes n8n powerful is that it does not force you to choose between no-code and code. You can build visually, then drop into JavaScript or Python when needed. You can connect SaaS tools, call APIs, transform data, trigger webhooks, and add AI steps inside the same workflow.

That makes it especially useful for technical operations teams.

What I like about n8n

n8n gives you real workflow control.

You can build multi-step automations, connect APIs, use code, run custom logic, and self-host the platform if you want more control over data and infrastructure.

The AI Agent node is also a big reason n8n stays relevant in 2026. It gives teams a way to connect LLMs with tools and external APIs inside a workflow graph, instead of treating the agent as a black box.

Pricing is also more attractive for complex workflows because n8n charges based on workflow executions, not every single step. That can matter a lot when you are building long workflows with many actions.

Where n8n fits best

n8n is a strong fit for:

Technical operations
Internal tooling
API orchestration
Data sync workflows
AI-enhanced business processes
Self-hosted automation
Agencies building complex client automations
Teams that want visual workflows plus custom code

A good example:

You can build a workflow that receives a webhook, enriches a lead, classifies the company with an LLM, updates HubSpot, sends a Slack notification, creates a Notion record, and logs everything to a database.

That kind of workflow is exactly where n8n shines.

Things that could be better

n8n is not the easiest tool for non-technical users.

The visual editor is approachable, but the platform becomes much more powerful when you understand APIs, data structures, expressions, credentials, error handling, and deployment.

Self-hosting is also not free in practice. The Community Edition is free, but you still need to manage servers, upgrades, backups, security, and monitoring.

For serious production use, especially in a business context, you should budget for infrastructure and maintenance.

Review signal

User sentiment around n8n is generally strong among developers and automation builders. People tend to praise its flexibility, self-hosting, and ability to combine no-code with code.

The common criticism is the learning curve. n8n is powerful, but it is not always the fastest path for a non-technical marketer who just wants a simple two-step automation.

My recommendation

Choose n8n if you want a flexible, technical workflow automation platform that can support serious AI automation without locking you into a purely hosted no-code tool.

It is one of the best AI workflow automation tools for teams that want control, customization, and self-hosting.

3. Zapier

Best for: Fast setup, the largest app ecosystem, and non-technical teams that want AI automation without heavy implementation work.
Pricing: Free plan with 100 tasks/month; paid plans start from $19.99/month billed annually, depending on task volume and plan.
Official links: Website · Pricing · AI automation · Zapier MCP

Zapier is still the default answer for many teams when they ask, “How do we automate this quickly?”

And honestly, that is fair.

Zapier has one of the largest app ecosystems in the market, with thousands of integrations and a very mature no-code workflow experience. If your priority is speed, simplicity, and app coverage, Zapier is hard to ignore.

In 2026, Zapier is no longer just a classic automation tool. It now has AI workflows, AI agents, AI chatbots, Copilot, MCP, SDK options, tables, forms, and more.

That makes Zapier a broad AI orchestration platform, especially for non-technical teams.

What I like about Zapier

The ecosystem is the biggest advantage.

If your team uses a random SaaS tool, there is a good chance Zapier already supports it. That matters for marketing teams, sales teams, RevOps, agencies, and SMBs that do not want to wait for custom integrations.

Zapier is also beginner-friendly. A non-technical user can build useful automations without understanding webhooks, APIs, or server infrastructure.

The AI side is also getting more interesting. Zapier MCP gives AI tools a way to connect to business apps through a controlled layer. That is important because AI agents become much more useful when they can act inside real tools.

Where Zapier fits best

Zapier is a strong fit for:

Marketing operations
Sales operations
SMB automation
Lead routing
CRM updates
Simple support workflows
Founder productivity
Fast no-code experiments
Agencies building simple client workflows

A practical example:

A lead fills out a form. Zapier enriches the lead, sends it to HubSpot, generates a personalized email draft, notifies the sales team in Slack, and adds the contact to a newsletter segment.

That kind of workflow is still very easy to build in Zapier.

Things that could be better

Zapier can become expensive as task volume grows.

Task-based pricing is simple to understand at first, but it can become painful when you start running high-frequency workflows or multi-step automations.

The product surface is also broader now. Zaps, Tables, Forms, Canvas, Agents, Chatbots, MCP, and other AI features are powerful, but the overall platform can feel fragmented compared with a single workflow canvas.

Zapier is also not self-hosted. If infrastructure control is a priority, look at Hexabot, n8n, or another self-hosted option.

Review signal

Zapier has a very mature review footprint. Users consistently praise ease of use, app coverage, and productivity gains.

The most common complaint is pricing at scale.

That matches my view: Zapier is great for getting started quickly, but you should watch costs as automation volume grows.

My recommendation

Choose Zapier if your priority is the largest integration ecosystem and the fastest path from idea to working automation.

It is not the cheapest at scale and not the best for self-hosted control, but it remains one of the most useful AI automation tools for business teams.

4. Make

Best for: Visual multi-step automation, branching workflows, and teams that want more flexibility than Zapier without going fully developer-first.
Pricing: Free plan with 1,000 credits/month; Core from $12/month for 10k credits; Pro from $21/month; Teams from $38/month.
Official links: Website · Pricing · AI Agents

Make is one of the best visual automation platforms in 2026.

If Zapier is about speed and simplicity, Make is about visual control. It gives you a canvas where you can build scenarios with routers, filters, conditions, iterators, error handling, and multi-step logic.

That makes it especially attractive for agencies, marketers, and operations teams that build complex workflows but do not want to write code for everything.

Make has also moved strongly into AI automation and agentic workflows. Its current positioning includes AI agents, AI apps, visual orchestration, and MCP support.

What I like about Make

The visual builder is the main reason to use Make.

You can see the workflow structure clearly, especially when the process branches into different paths. That is helpful when you are building automations with conditions, multiple apps, and exception handling.

Make is also relatively affordable compared with many automation tools. The free plan is useful for testing, and the paid entry point is reasonable for teams building real workflows.

I also like that Make is friendly to non-developers while still being powerful enough for serious automation builders.

Where Make fits best

Make is a strong fit for:

Marketing automation
Content workflows
Lead enrichment
Data movement between SaaS tools
Agencies building client automations
Visual workflow builders
Multi-step no-code AI automation
Teams that outgrow simple Zapier workflows

A good example:

A content team can use Make to watch a content calendar, generate briefs, create tasks, send drafts for approval, publish to multiple channels, and update reporting dashboards.

The visual canvas makes this easier to reason about than a long linear automation list.

Things that could be better

Make has a learning curve.

It is easier than developer-first platforms, but more complex than basic no-code tools. Once you get into routers, iterators, bundles, and error handling, beginners can feel overwhelmed.

Credit-based pricing also requires planning. You need to understand how credits are consumed so you do not accidentally build workflows that cost more than expected.

Make is also hosted. Enterprise options can support more advanced architecture patterns, but Make is not a full self-hosted workflow engine.

Review signal

Users tend to praise Make for its visual interface, flexibility, and ability to automate complex workflows without code.

The common criticism is the learning curve for advanced scenarios.

That feels accurate: Make is not the simplest tool, but it rewards users who learn its model.

My recommendation

Choose Make if you want visual workflow automation with strong branching, good pricing, and enough power for serious business workflows.

It is one of the best AI workflow automation tools for agencies, marketing ops, and non-technical teams that want more control than Zapier.

5. Gumloop

Best for: AI-native no-code workflows, agents, hosted MCP, and teams that want an automation builder designed around AI from the start.
Pricing: Free plan with 5,000 credits/month; Pro from $37/month.
Official links: Website · Pricing

Gumloop is one of the most interesting AI-native workflow automation tools right now.

Unlike older automation platforms, Gumloop does not feel like a classic “move data between apps” product with AI added on top. It feels like a tool built for the current AI agent era.

You can build AI workflows, create agents, connect data, use models, and automate tasks through a visual interface.

The product is especially popular with people building AI-heavy processes: SEO workflows, research agents, support triage, lead enrichment, data analysis, and internal productivity systems.

What I like about Gumloop

The main thing I like is focus.

Gumloop is not trying to be every automation platform at once. It is clearly built around AI workflows and agents.

That makes the product easier to understand if your primary goal is AI automation, not just app integration.

The pricing is also friendly enough to test. A free plan with 5,000 credits gives builders room to experiment before upgrading.

Gumloop also has a strong product feel. The interface is polished, the workflow builder is approachable, and the use cases are easy to understand.

Where Gumloop fits best

Gumloop is a strong fit for:

AI research workflows
SEO automation
Marketing operations
Sales enrichment
AI agents for internal tasks
Growth teams
No-code AI automation builders
Teams that want hosted AI workflow automation

A practical example:

You can build a workflow that collects competitor pages, summarizes positioning, extracts keywords, generates an SEO brief, and sends the final output to a content manager.

That is exactly the kind of AI-heavy workflow Gumloop is built for.

Things that could be better

Gumloop is not the best fit if you need self-hosting.

It is also not as broad as Zapier or Make in terms of general app ecosystem perception. It has strong AI workflow capabilities, but if your main priority is connecting every obscure SaaS tool your company uses, Zapier may still be safer.

Credits also matter. AI workflows can consume credits quickly, especially when they involve large documents, multiple model calls, or recurring agent runs.

Review signal

Gumloop’s review signal is positive, especially around ease of use, product experience, and AI-native workflow building.

The review base is still smaller than older platforms, so I would treat it as a fast-rising tool rather than a fully mature enterprise standard.

My recommendation

Choose Gumloop if you want an AI-native workflow builder that feels modern, fast, and focused.

It is especially good for growth teams, marketers, founders, and no-code AI builders who want to create useful AI workflows without managing infrastructure.

6. Relay.app

Best for: Approachable AI workflow automation with strong human approvals and small-team usability.
Pricing: Free plan with 500 AI credits/month and 200 steps/month; Professional from $19/month billed annually; Team from $59/month billed annually.
Official links: Website · Pricing

Relay.app is one of the easiest AI workflow automation tools to recommend to non-technical teams.

It is clean, approachable, and practical.

The product focuses on helping users describe what they want to automate, connect apps, add AI steps, and build reliable workflows without feeling like they are configuring an enterprise integration platform.

But the real reason Relay.app stands out is human-in-the-loop automation.

In 2026, that matters a lot.

AI agents are useful, but most business workflows still need approvals, reviews, assignees, escalation, due dates, and notifications. Relay.app treats that as a core feature, not an afterthought.

What I like about Relay.app

Relay.app is very good at making AI automation feel safe and operational.

You can add approval steps, ask humans to review AI-generated outputs, collect data from teammates, and make sure workflows do not run wild.

That is exactly what many small teams need.

The pricing is also simple compared with platforms that make you calculate every task, credit, token, and execution path.

Relay.app also includes access to major AI models through AI credits, which makes it easier for small teams to start without immediately managing separate model provider accounts.

Where Relay.app fits best

Relay.app is a strong fit for:

Small business operations
Founder workflows
Approval-heavy processes
Marketing operations
Sales follow-ups
Internal team coordination
AI workflows that need human review
Teams that want no-code automation without complexity

A good example:

An inbound lead arrives. Relay.app summarizes the lead, enriches the company, drafts a follow-up, asks a human to approve it, then sends the email and updates the CRM.

That human approval step is often what turns a risky AI workflow into a reliable business process.

Things that could be better

Relay.app has fewer integrations than Zapier or Make.

That may not matter for many teams, but if your company relies on a long tail of niche tools, you should check the integration list before committing.

It is also less developer-first than n8n or Pipedream. If you want heavy API orchestration, custom code, and deep backend workflows, Relay.app may feel too simple.

There is also no self-hosted deployment path.

Review signal

Relay.app gets strong user praise for ease of use, intuitive design, and making automation accessible for non-technical users.

The most common limitation is integration breadth compared with larger automation platforms.

My recommendation

Choose Relay.app if you want AI workflow automation your team will actually use.

It is especially strong for SMB operations, GTM teams, founders, and workflows where human approvals matter.

7. Pipedream

Best for: Developers, API-heavy automation, custom code, event-driven workflows, and SaaS teams building integrations or agent tooling.
Pricing: Free plan available; paid pricing is credit-based and depends on compute usage, workflow volume, and product tier.
Official links: Website · Pricing docs · Docs

Pipedream is one of the best automation tools for developers.

It is less about no-code simplicity and more about giving technical teams a fast way to connect APIs, write custom logic, trigger workflows, and ship automation without building a whole backend from scratch.

That makes Pipedream especially relevant in 2026 because AI agents need tools.

If you are building an AI agent that needs to call APIs, access user accounts, trigger workflows, or run custom logic, Pipedream is a serious option.

What I like about Pipedream

Pipedream gives developers real code control.

You can use JavaScript, Python, Go, Bash, prebuilt components, event sources, webhooks, and API integrations inside workflows.

This is a big deal for technical teams. Many no-code tools become painful when you need custom logic. Pipedream assumes custom logic is part of the job.

I also like that Pipedream’s pricing model is based on compute credits rather than simply charging for every step in the same way as some automation tools.

For API-heavy workflows, that model can be attractive.

Where Pipedream fits best

Pipedream is a strong fit for:

Developers
SaaS teams
API automation
Event-driven workflows
Internal tools
AI agent tool calling
Product integrations
Workflow backends
Teams that want code inside automation

A practical example:

A SaaS product can use Pipedream to let users connect their accounts, trigger workflows, run custom API logic, and feed results back into an AI assistant.

That is much closer to product infrastructure than simple no-code automation.

Things that could be better

Pipedream is not the best tool for non-technical business users.

It has visual elements, but the product is much more valuable when you are comfortable with APIs, code, credentials, and event-driven architecture.

Pricing can also require some thought because credits depend on execution time, memory, and workflow usage. That is not necessarily bad, but it is less immediately obvious than a flat per-seat plan.

Review signal

Pipedream users tend to praise developer flexibility, API connectivity, custom code support, and the generous ability to build technical workflows.

The common criticism is that beginners can find the interface and mental model confusing at first.

My recommendation

Choose Pipedream if you are a developer or SaaS team building API-heavy workflows, AI agent tools, or product integrations.

It is not the best no-code tool for business users, but it is one of the strongest developer-first automation platforms in this list.

8. Lindy

Best for: Founders, sales teams, executive workflows, inbox/calendar automation, CRM updates, and assistant-style AI agents.
Pricing: 7-day free trial; Plus from $49.99/month; Pro from $99.99/month; Max from $199.99/month; Enterprise custom.
Official links: Website · Pricing

Lindy is different from most tools in this list.

It feels less like a generic workflow automation platform and more like an AI assistant builder for busy professionals.

That is not a weakness. In fact, it is the whole point.

Lindy is useful when your automation needs look like executive assistant work: manage inboxes, schedule meetings, prepare follow-ups, summarize calls, update CRM fields, remind people, and keep work moving.

For founders and sales teams, that can be more valuable than a blank workflow canvas.

What I like about Lindy

Lindy is very fast to understand.

You do not need to think like an integration engineer. You think in terms of assistants and tasks.

That makes it especially useful for founders, executives, salespeople, recruiters, and operators who want AI to handle repetitive work without spending weeks building systems.

The platform also supports common business workflows around inboxes, calendars, meeting notes, email drafting, follow-ups, and integrations.

Where Lindy fits best

Lindy is a strong fit for:

Founder productivity
Sales follow-up
Meeting scheduling
Inbox management
Calendar coordination
Executive assistant workflows
Recruiting workflows
CRM admin tasks
Simple no-code AI agents

A practical example:

Lindy can monitor your inbox, summarize important emails, draft replies, schedule meetings, prepare meeting notes, and help with follow-up tasks.

That is not a generic backend workflow. It is AI assistant work.

Things that could be better

Lindy is not the best fit for deep backend automation.

If you want custom infrastructure, self-hosting, complex API orchestration, or developer-level workflow control, n8n, Pipedream, or Hexabot will likely be better.

It is also more expensive than some no-code automation tools at the entry level.

And because it is assistant-first, teams should be clear about where Lindy should act autonomously and where it should ask for approval.

Review signal

Lindy’s public review signal is generally positive around ease of use, assistant-style automation, and time savings.

The most common limitation is that it is not built for every kind of backend or technical workflow. It is better for operational assistant work than for deep workflow engineering.

My recommendation

Choose Lindy if your main goal is to automate inbox, meetings, follow-ups, scheduling, and CRM-related busywork.

It is a strong AI agent builder for founders and GTM teams, but not the first tool I would pick for self-hosted or developer-heavy automation.

9. Vellum AI

Best for: Production AI workflows, prompt management, evaluations, observability, and teams building AI features into products.
Pricing: Public pricing depends on product/package and usage; evaluate directly for production team plans.
Official links: Website · Docs · Observability docs

Vellum is not a traditional workflow automation tool like Zapier or Make.

It is better understood as an AI development platform for building, testing, deploying, evaluating, and monitoring LLM-powered workflows.

That makes it very relevant in 2026, especially for product teams.

If your company is building AI features into a SaaS product, you probably care about more than “can this automation run?” You care about prompt versions, evaluations, deployment environments, monitoring, user feedback, regressions, cost, and quality.

That is where Vellum stands out.

What I like about Vellum

Vellum treats AI workflow quality seriously.

A lot of teams start with prompts in a spreadsheet or a notebook. That works for a prototype, but it breaks down when you need production reliability.

Vellum gives teams a way to manage prompts, build workflows, run evaluations, deploy changes, and observe production behavior.

That makes it one of the best tools in this list for AI product engineering.

Where Vellum fits best

Vellum is a strong fit for:

AI product teams
LLM workflow development
Prompt management
Evaluation pipelines
Production AI monitoring
AI feature deployment
Product managers working with engineers
Teams that need observability and version control

A practical example:

A SaaS company building an AI document review feature can use Vellum to test prompts, compare models, evaluate outputs, deploy a workflow, monitor performance, and improve quality over time.

That is not the same as automating a spreadsheet update. It is production AI workflow management.

Things that could be better

Vellum is not the best fit if you mainly want to connect common SaaS apps.

If your goal is “when a form is submitted, send a Slack message,” Vellum is overkill.

Pricing and packaging can also be less straightforward than simple no-code tools because Vellum is closer to AI infrastructure than SMB automation software.

If you are evaluating it, talk to the team and map pricing to your expected usage, team size, and deployment model.

Review signal

Vellum’s review signal is strongest among AI builders and product teams. Users tend to value the low-code workflow builder, prompt iteration, evaluations, and observability.

The common challenge is that advanced AI workflows still require technical understanding.

My recommendation

Choose Vellum if you are building production AI systems and care about evaluations, deployments, observability, and controlled iteration.

It is not the best general-purpose automation tool, but it is one of the strongest platforms here for teams shipping AI features into products.

10. Workato

Best for: Enterprise AI orchestration, governance, security, auditability, and large-scale automation across complex business systems.
Pricing: Custom / sales-led.
Official links: Website · Pricing · Agent Studio

Workato is the most enterprise-oriented platform on this list.

It is not the tool I would recommend first to a solo founder or small agency. But for large organizations, it belongs in the conversation.

Workato’s current AI positioning focuses on Enterprise MCP, Agent Studio, governed agents, predictable execution, and orchestration across thousands of applications.

That is exactly the kind of language enterprise buyers care about.

Large companies do not just want AI agents that can act. They want AI agents that can act safely, with permissions, audit logs, governance, approvals, security, and compliance.

What I like about Workato

Workato understands enterprise automation.

It has the governance, integration, security, and orchestration story that large companies need when automating across CRM, ERP, HRIS, finance, support, and internal systems.

The move into Enterprise MCP is also important. AI agents need controlled access to tools, and Workato is positioning itself as a trusted orchestration layer for that.

For enterprise teams, this is much more credible than giving a general-purpose chatbot broad access to internal systems.

Where Workato fits best

Workato is a strong fit for:

Enterprise IT
RevOps
Finance operations
HR operations
Enterprise support automation
Governed AI agents
Complex cross-system workflows
Large companies with compliance needs

A practical example:

An enterprise team could use Workato to let an AI agent create tickets, update CRM records, retrieve finance data, trigger approvals, and execute workflows with logging and policy controls.

That is the level of governance large organizations need.

Things that could be better

Workato is expensive and sales-led.

That makes it less attractive for founders, small teams, and agencies that want transparent pricing and fast experimentation.

It is also more platform than many teams need. If you are just starting with AI workflow automation, Workato may feel heavy.

For self-hosted control, it is also not the best fit.

Review signal

Workato’s review signal is strongest in enterprise automation and iPaaS contexts. Users tend to value its power, integration depth, and governance.

The common drawback is complexity and cost.

That matches the positioning: Workato is an enterprise platform, not a lightweight AI automation toy.

My recommendation

Choose Workato if you are an enterprise team that needs governed, secure, cross-system AI automation at scale.

For startups and small teams, I would usually start elsewhere. For enterprise IT and operations, Workato is one of the strongest options.

How to choose the right AI workflow automation tool

Here is my practical decision framework.

Choose Hexabot if you want self-hosted conversational AI and workflow control

Hexabot is best when chat, actions, memory, workflows, and human takeover matter together.

It is especially strong for AI chatbot workflows, support automation, agencies, and developer-led teams that want more ownership over execution.

Choose n8n if you want technical automation with self-hosting

n8n is one of the best general-purpose workflow automation tools for technical teams.

Pick it if you want visual workflows, code steps, API flexibility, self-hosting, and AI capabilities in the same platform.

Choose Zapier if you want the biggest app ecosystem

Zapier is still the fastest way for many teams to connect apps and automate work.

Pick it when speed, simplicity, and integration breadth matter more than deep infrastructure control.

Choose Make if you want visual workflow power

Make is great for teams that want a visual canvas, branching, filters, and more control than beginner no-code tools usually provide.

It is a strong choice for agencies and marketing operations.

Choose Gumloop if you want AI-native no-code automation

Gumloop is one of the cleanest AI-first workflow builders.

Pick it for AI-heavy research, SEO, marketing, sales, and operations workflows.

Choose Relay.app if approvals matter

Relay.app is great when you want AI automation but still need human review, approvals, and operational reliability.

It is one of the best choices for small teams that want safe AI workflows.

Choose Pipedream if you are a developer

Pipedream is best for API-heavy workflows, custom code, product integrations, and AI agent tooling.

If your automation needs code, Pipedream should be on your shortlist.

Choose Lindy if you want an AI assistant for daily operations

Lindy is ideal for inbox, calendar, meeting, CRM, and executive assistant workflows.

It is less about backend orchestration and more about getting personal and team busywork handled.

Choose Vellum if you are building production AI features

Vellum is strongest for prompt management, workflow deployment, evaluations, and observability.

Pick it when AI quality and production monitoring matter more than app connector breadth.

Choose Workato if you are an enterprise

Workato is built for governed enterprise automation.

Pick it when security, auditability, approvals, and large-scale cross-system orchestration are the main buying criteria.

Final thoughts

There is no single best AI workflow automation tool for everyone.

The right choice depends on how technical your team is, how much control you need, how broad your integration requirements are, how sensitive your data is, and whether you are building chatbots, backend automations, AI agents, or production AI workflows.

If your automation starts with apps and data, look first at n8n, Zapier, Make, Relay.app, or Pipedream.

If your automation starts with conversation, support, agents, memory, or human interaction, look harder at Hexabot, Lindy, Gumloop, or Vellum.

And if you are an enterprise team trying to give AI agents controlled access to real business systems, Workato deserves a serious look.

The main lesson: AI automation is no longer just about connecting apps. It is about building controlled systems where AI can understand, decide, and act without turning your operations into a black box.

That is why the best AI workflow automation tools in 2026 are not just automation builders.

They are becoming the execution layer for AI-native work.