AI Agent vs Zapier/Make: What's Actually Different in 2026

Last post was about writing the system prompt that tells an agent what to do. The question that comes right after writing one, almost every time I've seen it asked, is some version of: “I already built this in Zapier — why would I need any of this?”

A year ago the honest answer was simple: Zapier and Make ran fixed, trigger-to-action sequences with no model deciding anything, full stop. That's no longer true, and pretending it still is would make this comparison a strawman. Zapier shipped its own Agents product and, in July 2026, an AI Orchestration layer explicitly built to move past linear if-this-then-that automation. Make shipped AI Agents inside its scenario canvas earlier the same year. “Does a model get to decide something” isn't the dividing line anymore. Where that decision happens, and how much of the agent you actually control, still is.

Both Can Look Like “AI Agents” Now

Concretely, that looks like a visual canvas where one node is now “let a model decide,” sitting inside the same drag-and-drop builder as every other step — the model picks from the actions already wired into that scenario rather than being handed an open-ended set of tools you defined. Reviews of these 2026 features, taken together, describe something consistent: the decision-making happens inside a bounded set of pre-built actions the platform already knows how to perform, generally called semi-autonomous rather than fully autonomous. That's not a knock — it's the trade-off a no-code platform makes on purpose, and for a lot of jobs it's the right one. But it means the honest comparison isn't “no-code tool, zero reasoning” against “custom code, real reasoning” anymore. It's: a model making decisions inside a platform's own action library, against a model making decisions inside tools, memory, and boundaries you designed yourself, the way every post in this series has built one from the raw SDK up.

The Real Dividing Line: Who Decides the Path, and When

A trigger-action platform, AI-enhanced or not, still has one shape at its core: something happens, a workflow runs, it ends. Even where one step of that workflow now has a model inside it, the workflow's overall shape — which apps are involved, roughly what order things happen in — is drawn by a human in the builder, ahead of time.

An agent you build the way the four-parts post described — brain, memory, tools, loop — doesn't have a pre-drawn shape at all. The model reads the actual message and decides, every single step, which of its tools apply, in what order, and when it's done. Nothing about the path is fixed in advance; all of it is tool design and prompt design, the things the last several posts in this series have actually been about.

Think of it as the difference between a flowchart someone drew before any request ever arrived, and a person who reads each request fresh and decides what to do about it. The flowchart might have a diamond-shaped decision box in it, even one a model fills in now — but the box, and the paths leading out of it, were placed by a human in advance. The agent doesn't start from a drawn shape at all; the shape is whatever the model decides it needs to be, for this message, right now.

flowchart TD
    subgraph Fixed automation
        F0[Any trigger] --> F1[Step A, always] --> F2[Step B, always]
    end
    subgraph Agent
        A0[Any message] --> AD{Model reads it}
        AD -->|only A applies| A1[Step A]
        AD -->|only B applies| A2[Step B]
        AD -->|both apply| A3[Step A and Step B]
        AD -->|neither applies| A4[No tool, just reply]
    end

Flow summary: A fixed automation runs the same steps every time, no matter what triggered it. An agent's model reads the actual message first and decides which steps, if any, apply — the same two tools can produce four different outcomes depending on content, not one fixed outcome every time.

Seeing the Difference in Code

Install the SDK with npm install @anthropic-ai/sdk, set ANTHROPIC_API_KEY, save this as agent/fixed-vs-agent.ts and run npx tsx agent/fixed-vs-agent.ts.

// agent/fixed-vs-agent.ts
import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

const expenses: { item: string; amount: number }[] = [];
const log: string[] = [];

function addExpense(item: string, amount: number) {
  expenses.push({ item, amount });
  return { ok: true, recorded: expenses.length };
}

function getTotal() {
  return { total: expenses.reduce((sum, e) => sum + e.amount, 0) };
}

function notify(message: string) {
  log.push(message);
  return { sent: true };
}

// ---- A fixed automation: every run executes the same two steps,
// in the same order, no matter what the incoming text says.
function runFixedAutomation(item: string, amount: number) {
  const step1 = addExpense(item, amount);
  const step2 = notify(`Recorded: ${item} (${amount})`);
  return { step1, step2 };
}

// ---- An agent: the model reads the message and decides which
// tool, if any, applies — nothing is pre-wired.
const tools: Anthropic.Tool[] = [
  {
    name: 'add_expense',
    description: 'Record one expense. Use it whenever the user says they spent money.',
    input_schema: {
      type: 'object',
      properties: { item: { type: 'string' }, amount: { type: 'number' } },
      required: ['item', 'amount'],
    },
  },
  {
    name: 'get_total',
    description:
      "Return the exact sum of every expense recorded so far. Use this whenever the user asks for a total, a sum, or how much they've spent overall.",
    input_schema: { type: 'object', properties: {} },
  },
  {
    name: 'notify',
    description: 'Send the user a short notification. Use this only when the user explicitly asks to be notified or reminded.',
    input_schema: {
      type: 'object',
      properties: { message: { type: 'string' } },
      required: ['message'],
    },
  },
];

function execute(name: string, input: Record<string, unknown>): unknown {
  if (name === 'add_expense') return addExpense(String(input.item), Number(input.amount));
  if (name === 'get_total') return getTotal();
  if (name === 'notify') return notify(String(input.message));
  return { error: 'unknown tool' };
}

async function runAgent(userText: string): Promise<string> {
  const messages: Anthropic.MessageParam[] = [{ role: 'user', content: userText }];

  for (let step = 0; step < 4; step++) {
    const response = await client.messages.create({
      model: 'claude-sonnet-5',
      max_tokens: 300,
      tools,
      messages,
    });

    messages.push({ role: 'assistant', content: response.content });

    if (response.stop_reason !== 'tool_use') {
      const block = response.content.find((b): b is Anthropic.TextBlock => b.type === 'text');
      return block?.text ?? '';
    }

    const results: Anthropic.ToolResultBlockParam[] = [];
    for (const block of response.content) {
      if (block.type === 'tool_use') {
        results.push({
          type: 'tool_result',
          tool_use_id: block.id,
          content: JSON.stringify(execute(block.name, block.input as Record<string, unknown>)),
        });
      }
    }
    messages.push({ role: 'user', content: results });
  }

  return 'Stopped: step limit reached';
}

runAgent('I spent 500 on lunch.').then(console.log);

runFixedAutomation is the trigger-action shape in miniature: call it for any expense at all and it always runs both addExpense and notify, in that order, regardless of whether a notification was ever asked for — because nothing in that function reads the content to decide. runAgent, with the identical three tools available, behaves differently depending on what's actually said: “I spent 500 on lunch” calls only add_expense; “what's my total so far” calls only get_total; “I spent 200 on tea, and please notify me” calls both. Three different messages, three different paths, decided by the model each time rather than written into the function.

The Mistake I Almost Made Writing This

The first draft of this post made the old argument — no-code tools can't reason, agents can, done. Before publishing, checking what Zapier and Make actually look like right now turned up Zapier's AI Orchestration launch and Make's AI Agents feature, both from earlier this year. The old argument would have been wrong the moment it went live. The fix wasn't a small wording change; it was rebuilding the comparison around what's actually still true — where the decision happens and who controls the tool set — instead of whether a model is involved at all.

Common Mistakes Comparing the Two

• Assuming “no-code automation platform” still means “no model reasoning involved.” Check what the platform ships today rather than what it shipped when you last looked; this space moves fast.
• Treating “I used the platform's AI Agent feature” as the same exercise as building one. Designing your own tools, memory, and system prompt is a different, more controllable job than configuring a feature inside someone else's bounded action library.
• Reaching for custom code when the platform's library already covers it. A job you can describe in one sentence, connecting a couple of existing apps, is usually faster and cheaper to wire up in a platform built for exactly that.
• The reverse mistake: forcing a complex, stateful job into a platform's bounded actions. Once you need a tool the platform doesn't have, memory shaped for your own product, or a prompt you can tune precisely, that's the signal to build rather than configure.

What's Next

Knowing the real difference between a fixed workflow and a decided one sets up the next question naturally: how much should an agent be allowed to decide on its own, and where does that autonomy need a limit? That's worth its own post.

Frequently Asked Questions

Do Zapier and Make count as “real” AI agents now?

Their own agent features do involve a model making decisions, so a flat “no-code tools don't reason” test no longer holds. What's still different is scope: those decisions happen inside a platform-defined, bounded set of pre-built actions, not a tool set, memory system, and prompt you design yourself.

When should I just use Zapier or Make instead of building an agent?

When the job fits in one sentence — connect app A to app B when something happens — and you don't need a custom tool, your own memory system, or a model you fully control. The platform's bounded action library and per-task pricing are a fair trade for not writing or maintaining code.

When does it make sense to build a custom agent instead?

When you need a tool the platform doesn't ship, memory shaped the way your own product needs it, a system prompt you can tune precisely, or a cost structure that doesn't scale per task — everything the last several posts in this series have actually been building.