Agents, Not Workflows, Should Be the First-Class Citizens of AI Platforms

Written By Swanand Rao

For the last decade, automation has been shaped by a simple mental model:

“Draw a workflow. Drag some nodes. Connect APIs. Ship.”

Tools like n8n, Make.com, and many others have built powerful ecosystems around this idea. They treat workflows as the first-class abstraction: everything else, integrations, triggers, actions are just a node in the graph.

That made perfect sense in the pre-agent world. But with the rise of LLM-powered agents, this model is starting to show its age.

Agents reason. They decide. They coordinate. They use tools. They adapt. Trying to force that into a workflow-first world is like bolting a jet engine onto a bicycle frame. It can move faster, but it was never designed for that.

It’s time to flip the architecture!

Next Moca’s core philosophy is simple but transformative:

  • Agents are the atomic unit of intelligence.

  • Workflows are orchestration - not the center of the system.

  • Agents should be the first-class citizens. Workflows should be second-order. Not the other way around.

1. Workflow-First vs Agent-First: Two Different Universes

Workflow-first tools like n8n are optimized for this question:

“Given a trigger, what exact sequence of steps should run?”

Agent-first platforms are optimized for a different question:

“Given a goal, which agent should pursue it, with what tools, under what constraints?”

Those are not the same question. And confusing them leads to brittle architectures.

In workflow-first (like n8n):

  • The workflow is the product.

  • “Intelligence” is scattered across condition nodes, expressions, and error handlers.

  • LLM calls are just another node, no more important than a Slack notification.

In an agent-first model:

  • The agent is the core, enduring object.

  • It encapsulates reasoning, tools, policies, memory, and identity.

  • Workflows are optional orchestration layers around agents, not the foundation.

Once you see this difference, it’s hard to unsee.

2. Where Workflow-First Platforms (Like n8n) Hit Their Ceiling

This isn’t about dunking on n8n. n8n is great at what it was designed for: deterministic, node-based automation. But it’s equally important to be honest about where workflow-first platforms strain under agent-native workloads.

Workflow platforms assume:

  • A node has predictable input and predictable output

  • Failures are handled with retries or branches

  • State is passed linearly from one block to the next

Now introduce an LLM:

  • Outputs vary by context, prompt phrasing, and model version

  • Tool choices may need to be dynamic

  • Reasoning may require multiple iterations, reflection, or delegation

In n8n, you end up encoding this as:

  • Loops

  • Condition nodes

  • JSON-transform nodes

  • Error branches

  • “LLM Node 1 → Function Node 2 → LLM Node 3 → Merge Node 4” spaghetti

You’re essentially trying to recreate an agent’s inner loop via a graph of nodes. It works at small scale. It becomes unmaintainable at serious scale.

In an agent-first world, that entire inner loop lives inside the agent definition and not splattered across dozens of workflow nodes.

3. Agents Have Identity and Policy, Workflows Don’t

A workflow is:

  • A file / definition

  • A collection of nodes

  • A trigger plus a series of actions

That’s useful, but it’s not enough for AI-native systems.

An agent has:

  • A name and role (e.g., “Customer Billing Investigator Agent”)

  • Capabilities and tools (e.g., “can read Zendesk tickets, query Stripe, access internal RAG index”)

  • Policies & constraints (e.g., “never refund above $500 without human approval”)

  • Memory (past runs, user history, embeddings, local state)

  • Governance (who can invoke it, from where, with what guardrails)

  • LLM configuration (model, temperature, context limits, safety filters)

In a workflow-first model, these concepts are scattered:

  • Some live in nodes

  • Some live in environment variables

  • Some live in separate docs or dashboards

  • Some live in ad-hoc code blocks

That fragmentation is fine when all you’re doing is “send lead from Typeform to HubSpot.” It’s not fine when you’re delegating meaningful decisions to AI systems.

Agent-first platforms instead define agents using a formal schema, often via an agent definition standard.

4. Enter ADL: A language to model agents

This is where concepts like ADL (Agent Definition Language) - an open standard developed incubated and championed at Next Moca, matter.

ADL treats an agent like an API:

  • It has a contract (inputs, outputs, tools, constraints)

  • It has a definition (role, description, behavior)

  • It has governance (auth, scopes, permissions)

  • It is versioned and testable

Instead of saying:

“We have 37 workflows that call OpenAI in different ways.”

You say:

“We have 5 well-defined agents, each expressed in ADL, and workflows only orchestrate them.”

Here:

  • ADL is the source of truth for each agent.

  • Workflows (whether in n8n, a custom orchestrator, or another system) simply call agents as stable, governed capabilities.

  • You can change, test, or swap an agent implementation, without rewriting every workflow that uses it.

Workflow-first tools do not give you a clean, shared, interoperable representation of agents. They give you graphs. ADL gives you a language and contract.

5. Honest Comparisons: n8n vs Next Moca’s Agent-First Thinking

Let’s be specific in a few areas - respectfully, but directly.

5.1. Reuse and Composability

  • In n8n:

    • Reuse is mainly through sub-workflows or duplicating workflows.

    • Agent-like logic (e.g., “support triage with LLM + tools”) is often embedded inside a specific flow.

    • You end up with multiple flows that each have slightly different LLM prompts, parameters, and tool usage.

  • In an agent-first + ADL world:

    • The Support Triage Agent is defined once as a reusable capability.

    • Multiple workflows (support intake, escalation, QA, analytics) call that same agent.

    • Updating its behavior is done in one place—its ADL definition and implementation.

Result: Agent-first design dramatically reduces drift and duplication.

Workflow-first platforms tend to accumulate “prompt spaghetti” across flows.

5.2. Governance & Audit

  • In workflow-first platforms:

    • You can see workflow runs, node executions, logs, and errors.

    • But you often can’t easily answer:

      • “Which logical ‘agent’ made this decision?”

      • “Under what policies?”

      • “Using what tools and memory?”

    • Those concepts are implicit, not explicit.

  • In an agent-first world:

    • Every decision is attributed to a specific agent identity.

    • You can attach compliance policies, RBAC, and audit trails to that agent.

    • You know exactly what tools it was allowed to use and under what constraints.

If you’re just moving rows in Airtable, that might not matter.
If you’re approving refunds, changing credit limits, or modifying infrastructure, it absolutely does.

5.3. Scaling Multi-Agent Systems

Can you approximate multi-agent systems in n8n? Sure.


You could:

  • Create multiple workflows

  • Have them call each other

  • Use LLM nodes and HTTP nodes as “agents”

  • Implement some shared state via a DB or queue

But you’re working against the grain of the platform.

You’re trying to recreate:

  • Agent registries

  • Inter-agent messaging

  • Shared memory

  • Role boundaries

  • Hierarchical planners

…inside a tool that fundamentally thinks in terms of triggers and node graphs.

On the other hand Agent-first platforms like Next Moca, especially those built around something like ADL, treat:

  • Agent definitions as first-class objects

  • Inter-agent communication as a native pattern

  • Multi-agent orchestration as a core capability, not a hack

That matters if you believe the future is not one agent, but many specialized agents collaborating.

6. Workflows Actually Get Better When They’re Not the Star

Here’s the twist - Making agents first-class doesn’t diminish workflows. It rescues them.

When workflows aren’t responsible for:

  • Encoding all decision logic

  • Managing LLM retries, reflections, and tool selection

  • Juggling prompts across nodes

…they become what they were always meant to be:

Choreography and coordination, not intelligence.

Workflows become:

  • Thinner

  • More declarative

  • Easier to reason about

  • Easier to migrate between tools (because they mostly call agents, APIs, and events, not embed bespoke logic)

In other words, workflow-first platforms are fantastic orchestration layers - once you stop making them carry the full weight of intelligence.

7. The Opinionated Take: You Can’t Build the Future with Yesterday’s Abstractions

If your platform:

  • Treats LLMs as “just another node”

  • Has no concept of an agent identity with capabilities and policies

  • Stores “agent behavior” as scattered prompts and conditionals in graphs

  • Lacks a structured way to define, version, and govern agents (e.g., via ADL)

…then it is fundamentally a workflow tool with LLM add-ons, not an agent platform.

That’s fine if your goal is lightweight automation.
It’s not fine if your goal is:

  • Building reliable, governable AI agents

  • Creating a system of record for agent behavior across an organization

  • Running multi-agent systems in production

  • Meeting compliance and audit requirements for AI decisions

In that world, agents must be the first-class citizens.
Everything else—workflows, triggers, orchestrators, schedulers—is secondary.

We’ve already seen this story in software history:

  • We moved from scripts to services.

  • From ad-hoc JSON to OpenAPI contracts.

  • From snowflake deployments to container standards.

Agents are the next abstraction.
ADL or specs like it are the OpenAPI moment for agents.

Workflow-centric thinking will not disappear. It will just take its rightful place as a powerful, but supporting, layer.

8. Where to Go from Here

If you’re building or adopting automation / AI systems today, ask yourself:

  • Are we treating workflows as the unit of intelligence?

  • Do we have named, well-defined agents with explicit capabilities and policies?

  • Is there a declarative spec (like ADL) for our agents?

  • Can we swap agent implementations without redoing workflows?

  • Can we clearly answer: “Which agent did this, and under what rules?”

If the answer is “no” across the board, you’re not building an agent platform yet—you’re retrofitting agents onto a workflow tool.

The future belongs to platforms that:

  • Treat agents as first-class citizens

  • Use standards like ADL as the system of record for those agents

  • Let workflows do what they do best: orchestrate, not thin

Workflows were designed for tasks.
Agents are designed for intelligence.

If intelligence is at the center of your roadmap,
your architecture needs to be agent-first, workflow-second.

Swanand Rao
Next

Agent Definition Language (ADL): The Open Source Standard for Defining AI Agents