Your Next Startup: The Agentic Workflow Engine

n8n has over 400 integrations. Zapier claims 7,000+. Every single one was hand-built, tested against a moving API, and will eventually break when that API ships a v2. The entire workflow automation industry runs on a treadmill: build connectors, fix connectors, rebuild connectors. Meanwhile, the real shift in software, agents that reason and act autonomously, is happening outside these platforms entirely.

Here is a startup idea that kills the integration treadmill and builds for the agentic era at the same time.

The Integration Tax

Every workflow platform eventually becomes an integration company. n8n, Zapier, Make, Pipedream, Tray.io, they all spend enormous engineering effort building and maintaining connectors. Each connector is a custom adapter: someone reads the API docs for Salesforce or HubSpot or Stripe, writes the mapping code, handles auth, pagination, error states, rate limiting, and then maintains it forever. When Stripe changes a webhook payload or HubSpot deprecates an endpoint, that connector needs an update. Multiply that by thousands and you have a permanent tax on the business.

This made sense in a world where the consumer of these workflows was a human dragging boxes on a canvas. Humans need pre-built nodes with nice dropdown menus and labeled fields. But agents don't need any of that. An agent can read a spec.

Specs Are the New Connectors

MCP (Model Context Protocol) gives you a standardized way to describe tools that AI agents can call. OpenAPI specs already describe REST APIs in machine-readable format. GraphQL has introspection built into the protocol. Every serious API already publishes at least one of these.

Instead of building a Stripe connector, you point the engine at Stripe's OpenAPI spec. Instead of maintaining a Slack integration, you register Slack's MCP server. The engine reads the spec, understands the available operations, their parameters, their auth requirements, and generates step configurations automatically. You get instant support for any service that publishes a spec, which is effectively every service worth integrating with.

The step configuration layer works like this: given a spec (MCP, OpenAPI, or GraphQL schema), the engine extracts available operations, input/output schemas, and authentication flows. It builds typed step definitions that can be used in flows, both by agents constructing flows dynamically and by humans editing them in a UI. When the upstream API changes and publishes an updated spec, the step definitions update automatically. No connector code to maintain. No integration team racing to keep up.

Built for Enterprise Scale

n8n runs as a single Node.js process. You can add workers, bolt on Redis, configure queue mode, but at its core you're scaling an application server. For a team running a few hundred workflows, that's fine. For an enterprise running tens of thousands of concurrent flows across dozens of teams, it's a ceiling you'll hit hard.

The engine should be Kubernetes-native from day one. Each step in a flow runs as its own container. The orchestrator schedules steps across the cluster, scales horizontally without configuration, retries failed steps independently, and handles massive parallelism because that's just what Kubernetes does. There's no single bottleneck, no shared process, no "upgrade to our enterprise tier for more workers." You scale by adding nodes to your cluster, the same way you scale everything else in your infrastructure.

This matters for enterprises specifically because their workflows aren't simple "if this then that" chains. They're complex graphs with fan-out, fan-in, conditional branching, human approval gates, and SLA requirements. Running these on a single process with a queue is like running your CI/CD pipeline on a cron job. It technically works until it doesn't.

Agentic First, Not Agentic Bolted On

Here's the part that makes this more than just "n8n with better infrastructure." The engine is designed from the ground up for flows where agents are participants, not just triggers.

A traditional workflow is fully deterministic. Step A calls an API, passes the result to Step B, which transforms it, passes it to Step C. Every input and output is known at design time. These workflows are valuable and this engine supports them through the spec-driven step system described above. An MCP client or HTTP client executes the call, the output schema is known, validation is straightforward.

But the interesting workflows combine deterministic and non-deterministic steps. An agent step takes context from previous steps, reasons about it, decides what to do, and produces output that might vary every time. Maybe an agent reads a customer support ticket, decides which internal team should handle it, drafts a response, and flags whether the issue needs escalation. The reasoning is non-deterministic. The actions it takes (filing a Jira ticket, sending a Slack message, updating a CRM record) are deterministic steps driven by specs.

The engine lets you compose these freely. You can follow an agent step with a validation step that checks the output against a schema or a set of business rules before the flow continues. You can have an agent step that dynamically constructs a sub-flow by selecting which spec-driven steps to execute based on its reasoning. You can insert human review gates after agent steps for high-stakes decisions. The flow graph becomes a mix of reliable, typed, spec-driven operations and flexible, reasoning-capable agent nodes, with explicit boundaries between them.

This is what enterprises actually need. Not a chatbot that can call tools, but a governed system where agent behavior is observable, auditable, and constrained by the flow structure around it. The deterministic steps give you predictability and compliance. The agent steps give you flexibility and intelligence. The validation steps give you guardrails.

Why Agents Should Build the Flows

The last piece is that agents aren't just participants in flows, they're also builders. Because every integration is spec-driven, an agent can browse available specs, understand what operations are possible, and assemble a flow from them. A product manager describes what they need in natural language: "When a deal closes in HubSpot over $50k, create a Jira onboarding epic, notify the CS team in Slack, and schedule a kickoff in Google Calendar." The agent reads the relevant specs, constructs the flow graph with the right steps, parameters, and connections, and presents it for review.

This works because the specs are self-describing. The agent doesn't need to know how your custom n8n node for HubSpot works. It reads HubSpot's OpenAPI spec, finds the deal webhook and the relevant endpoints, and wires them up. The same agent can build flows against any service you've registered, even internal APIs, as long as they publish a spec.

For enterprises with hundreds of internal services, this is transformative. Instead of waiting for an integration team to build a connector for your internal billing API, you publish an OpenAPI spec for it and every agent in the system can immediately build flows against it.

The Opportunity

The workflow automation market is large and growing, but every incumbent is anchored to the connector model. They can't easily abandon it because their entire value proposition is "we integrate with everything, pre-built." Switching to a spec-driven approach would mean admitting that the thing they spent years building is now a liability.

A new entrant doesn't carry that baggage. You start with zero connectors and infinite integrations. You ship a platform that scales like infrastructure, governs agent behavior like an enterprise demands, and lets teams build workflows by describing what they need rather than dragging boxes around.

The wedge is any enterprise already deep in Kubernetes that has outgrown n8n or hit the limits of Zapier's enterprise tier. They already think in containers and specs. They just need a workflow engine that thinks the same way.

Build it.