Enterprise AI agent development tools 2026

This page has a Markdown version optimized for AI tools. See llms.txt for all machine-readable content.
A technical evaluation of workflow-based automation tooling for building enterprise-grade agentic systems using LLMs. This is the second iteration of the report, conducted by independent research analyst Andrew Green in Q2 2026
Workflow-based AI Agent Development Tools are products for enterprises which offer a no-code/low-code development environment to automate business logic using LLMs. They allow users to define an automation sequence using both deterministic actions and self-governing agents.
A common critique is that these tools do not create authentic agents, as they are not fully self-governing and require users to have prior knowledge of how a flow looks. I therefore want to clearly define the intent of this report is to evaluate agent-based automation for enterprises. If it is acceptable for solopreneurs to delegate their calendars and emails to fully autonomous agents, it is not an acceptable scenario in an enterprise.
This report is evaluating the enterprise qualities of these AI agents. I therefore distinguish between an enterprise-grade agent and an enterprise-grade agent development tool, as these capabilities cut both ways. I find that both humans and agents interpret them whichever way they want in a given scenario.
For example, take authentication and authorization. This takes two forms
This report exclusively focuses on the second aspect. This will be applicable across triggers, Code execution, Sandboxing, Filesystem access, API call logs, Killswitches, Rate Limits and the rest.
Writing a prompt asking the LLM not to hallucinate or disclose sensitive data does not qualify as a security feature.
I have also excluded other non-AI product features such as tool hosting and form factor, or monitoring and error handling of wider workflow.
Only a handful of vendors offer a sandbox as a security boundary for untrusted, LLM-generated code. While roughly half of the vendors offer some incarnation of code execution, even fewer have sandboxing. Out of those with sandboxing, most rely on third party services, most commonly E2B.
CrewAI notably deprecated its native code execution service and suggested customers use E2B as a purpose-built sandbox. Some don’t offer conventional MicroVM or virtual kernels, but rather use process isolation through a self-hosted configuration.
Most marketing assets conflate "the agent uses an API key to call Anthropic" with "the agent provides credentials when accessing third party services." Only Google, Langflow, Workato, CrewAI, Sim.ai, and Gumloop score 2.
Lineage, which refers to the ability to trace an agent to a human identity is essentially non-existent across the market, with only Google, Workato and Gumloop scoring anything.
Secrets management is similarly thin: only Google, Sim.ai and Gumloop score 2, with Make, and Retool scoring 1. This matters most in enterprise contexts where agents are calling third-party APIs or accessing internal systems.
Most tools don’t really have a security-first mindset. Google and Gumloop were noticeably one of the tools concerned with security, being the only ones to offer all the following Proxy-based filtering and firewalling, policy definition, tool ABAC, authentication and authorization, lineage, and secrets management.
Some vendors use evaluations as a way to define guardrails and security policies. For example, some vendors use a “does answer contain PII” evaluation to enforce the “don’t disclose PII” guardrails, to result in a data loss prevention security policy.
This can, for example, use an LLM-as-judge to detect PII, whose outcome is then sent to a summarizer agent that non-determinically determines not to share the PII.
This is different from running a deterministic regex rule that detects social security numbers and replaces them with asterisks and a slap on the wrist.
MCP Host/Client functionality, where agents consume external MCP servers are commonplace. MCP Servers, where exposing the platform itself as an MCP server for other agents to call are similarly widespread. By contrast, Google's agent-to-agent protocol is only employed by Google (obvs), CrewAI, Retool, and Sim.ai.
There is nuance in MCP implementation, but generally speaking it is a commoditized feature.
However much you want to position these tools for citizen developers, you cannot ignore that sophisticated automation still requires technical knowledge. Most people with technical knowledge know how to code, so offering a coding environment which can just be a “run script” action, is a huge asset to the product.
Between the rather lackluster agent code execution and running human-written code, there are NO PLATFORMS that do both to a good degree. Not even Google.
Considering how important evaluations are to determine how an agent and workflow are performing, many vendors are not implementing them.
Evaluations were hard to define for the report. There are many ways you can implement evaluations, and it is difficult to write an exhaustive list. This report has mainly focused on evaluating agents against known answers, as these are one of the better ways of preventing hallucinations. These include Matches, Semantic similarity/relevancy, and Factual Correctness. More generic LLM-as-judge and Custom evaluations, which can mean anything are also included.
This report is considerably different from the one written last year. While the premise remains consistent and most of the landscape includes familiar names, there are a number of changes which I will state and explain below:
The code-based and no-code duality continues this year. Users can use these tools to mix-and-match between the two. Generally speaking, the no-code canvas is used to define the high level logic, while code-based snippets (usually hosted within a node in an automaton tool) perform custom tasks which cannot be defined with the canvas.
However, we introduce another dime