Every production agent in 2026 — whether it lives inside Lindy, n8n, Agentforce, Relevance AI, Copilot Studio, or a hand-rolled Claude script — is built from the same five parts. Once you can see the skeleton through the brand paint, every vendor demo gets dramatically easier to evaluate.

The Skeleton

Strip away the canvas, the colors, the marketing taxonomy, and every agent reduces to five components. Memorize them in this order, because the order matters when you debug.

1. Model — the language model that does the reasoning and selects the next action.
2. Tools — the things the agent can do to the outside world.
3. Memory — what the agent remembers within a run, across runs, and about its user.
4. Loop — the control structure that says do, observe, decide, do again.
5. Guardrails — the budgets, gates, and policies that keep the loop from eating itself.

If you can name all five for any system in front of you, you can predict its failure modes, you can size its risk, and you can talk back to vendors with precision. If you cannot name all five, you do not yet understand the system, no matter how slick the demo was.

The fastest debugging trick in 2026: when an agent misbehaves, ask which of the five components is missing or under-specified. The answer is almost never "the model is dumb." It is almost always "memory is wrong" or "guardrails are absent."

Part One: The Model

The model is the reasoning engine. In May 2026, the credible production choices for operator-builders are Claude (Sonnet 4.5, Opus 4.7), GPT (GPT-4o, GPT-5 in some accounts), Gemini 2.5, and a handful of open-weight models that have crossed the production threshold like Llama 4 70B and DeepSeek-V3.1. Inside no-code tools you usually pick from a dropdown; the choice is rarely Python-level. But the choice still matters.

What the model actually does

In every agent loop, the model receives the current state — the goal, the conversation so far, the observations from previous tool calls, the available tool definitions — and returns one of two things: a tool call (with arguments), or a final answer. That's the entire job. Reason, then either act or stop. The cleverness of "agentic AI" is just doing this hundreds of times in sequence.

The choice that matters: capability per dollar per latency

Operator-builders should think about model choice on three axes:

• Capability: can it reliably emit valid tool calls, follow instructions under pressure, and avoid making up tool names that don't exist? GPT-4o-mini, Claude Haiku 4, and Gemini Flash 2.5 are the cheap workhorses; Sonnet 4.5 and GPT-4o are the reliable middle; Opus 4.7 and GPT-5 are the heavyweights for hard reasoning.
• Cost: agents make many model calls per run. A run that calls the model twenty times at $0.03 per call costs sixty cents per execution; multiply by a thousand runs a day and you have $600/day. The 10x cost spread between Haiku 4 and Opus 4.7 shows up at the bottom line, not in the demo.
• Latency: tool-calling agents serialize many model calls. If each round trip is two seconds, a 10-step run takes 20 seconds before the user sees output. Streaming hides some of this but not all.

The 2026 anti-pattern: "just use the smartest model"

The cheap-mistake builder picks Opus 4.7 for everything because it scores highest on the leaderboards. Then the agent makes 30 tool calls per run, the bill spikes, and nobody notices until the credit-card decline email arrives. Production agents should match model capability to step difficulty. A "classify this email as RFP/not-RFP" step deserves Haiku 4. An "investigate why the payment failed across three systems" step deserves Sonnet or Opus. Some agent platforms (Lindy, Relevance AI, n8n) now let you pick the model per node; if yours does, use that knob.

Part Two: Tools

Tools are how the agent interacts with the world. Each tool is a typed function the model can call: send_email(to, subject, body), search_crm(query), create_ticket(title, priority, body). The model picks one, fills in the arguments, the runtime executes it, and the result becomes the next observation in the loop.

The tool surface is your real product

Operator-builders frequently spend 80% of their time tuning prompts and 20% defining tools. The ratio should be reversed. The tool surface — what tools exist, what they accept, what they return, what guardrails sit inside them — is the agent's actual contract with the world. A well-defined tool surface makes a mediocre model behave well. A sloppy tool surface makes the best model behave dangerously.

This is what Model Context Protocol (MCP) standardizes. By May 2026, MCP is the open standard for tool definitions, supported by Claude, OpenAI, n8n's AI Agent node, Lindy, and an explosion of community MCP servers (Notion, Linear, Stripe, Slack, GitHub, etc.). The win is not novelty — it's that the same tool definition works across runtimes, and the same security/audit story applies everywhere.

Three properties of a safe tool

1. Narrow: a tool that does one thing well is safer than a tool that takes a free-form natural-language argument. Prefer refund_order(order_id, amount, reason_code) over do_customer_service_thing(instructions).
2. Auditable: every invocation logs to a queryable store. If the agent did something weird, you can replay the trace.
3. Authorized: the tool checks at runtime that this agent, on behalf of this user, in this tenant, is allowed to do this. Identity flows through; the agent does not inherit god-mode credentials.

The Comet OTP exfiltration: a tool-design failure

In late 2025, Perplexity's Comet browser agent was the subject of a widely-shared security writeup: a crafted webpage tricked the agent into navigating to a banking site and copy-pasting an OTP code visible in the user's other browser tab. The root cause was not "the model is dumb." It was a tool surface that conflated two privileges: read whatever is on screen and send whatever you read to a third party. A safer tool design would have refused cross-domain content transfer without a per-domain authorization. The Comet team patched it. Every operator-builder shipping browser-agent capability should treat that incident as the canonical "your tools must distinguish read from exfiltrate" story.

Part Three: Memory

Memory is the most under-discussed of the five parts, and the one that produces the most "wait, why does the agent keep asking the same question?" tickets.

Three layers of memory

• Working memory (within a run): the conversation/observation history that gets passed back to the model on each iteration of the loop. This is just context-window content. When your agent is on iteration 15, it sees iterations 1 through 14 in the context. If the context overflows, things get dropped, and the agent appears to "forget" what it just did.
• Session memory (across runs in a session): stored conversation state between user turns. In a chatbot or recurring agent, this is what lets the agent remember what you said yesterday.
• Long-term memory (across all runs): facts the agent persists in a database — vector store, structured record, or a tool like Mem0 or Letta. "User prefers Slack notifications over email." "This account is in trial and ends June 14."

Failure mode: missing memory looks like "the agent is broken"

An ops team at a B2B SaaS company built a customer onboarding agent in Lindy. It worked in testing. In production, customers reported that the agent asked them for their company size on day 1, day 3, and day 7 — three times. The problem was not the model. The problem was no long-term memory. Each scheduled run created a fresh session with no recall of prior runs. Adding a Mem0 tool that wrote and read customer_facts fixed the symptom in an afternoon.

Conversely: too much memory is also a failure. An agent that retains every interaction forever bloats context, slows iteration, and surfaces stale information. ("The customer mentioned six months ago they hated emails. Even though they just asked for email follow-ups.") Good memory design is selective: persist what's useful, expire what's stale, version what changes.

The "memory is just RAG" trap

A common 2026 mistake: treating long-term memory as "just throw everything in a vector store." Vector retrieval is good at finding semantically similar text, but it is not good at answering "what is the current state of this customer's onboarding?" — that's a structured database question. Production agents use both: a vector store for unstructured recall, and a structured record (Airtable row, Postgres table, CRM field) for state. The model reads from both via tools.

Part Four: The Loop

The loop is what makes an agent an agent. Without a loop, you have a workflow with an LLM step. With a loop, you have autonomy — and with autonomy, you have all the risk we have been talking about.

The ReAct pattern, without the math

Most production agents in 2026 are still descendants of the ReAct pattern (Reason-Act-Observe). At each iteration:

1. Reason: the model thinks about the current state and what to do next. ("The customer says they didn't get the invoice. I should check Stripe.")
2. Act: the model emits a tool call. (search_stripe(customer_id="cus_abc123"))
3. Observe: the runtime executes the tool and feeds the result back into the model's context. ("Stripe returned: invoice inv_xyz, status sent, email [email protected].")
4. Loop: the model now reasons again with the new observation. Maybe it stops here ("the invoice was sent; tell the customer to check spam"). Maybe it acts again ("let me check the email logs").

Newer patterns (Reflexion, Tree-of-Thoughts, Plan-and-Execute) are variations on this. The variations matter less than the fact: there is always a loop, and the loop must terminate.

How the loop terminates

Three legitimate termination conditions:

• The model emits a final answer (a "done" signal — in tool-calling formats this is "no tool call this turn, return text").
• The runtime hits a max iteration cap. ("After 10 iterations, stop and escalate.")
• An external interrupt fires — a kill switch, a budget gate, a human cancellation.

If your agent has no max-iteration cap, you have committed to a loop that ends only when the model decides to stop or your wallet does.

The shape of a bad loop

A bad loop, in trace form, looks like this:

• Iter 1: "The user wants their invoice. Let me search the CRM." → tool call.
• Iter 2: "The CRM didn't have it. Let me search billing." → tool call.
• Iter 3: "Billing had it but the email looks old. Let me check the email logs." → tool call.
• Iter 4: "Email logs don't load. Let me retry." → same tool call.
• Iter 5: "Still no email logs. Let me retry." → same tool call.
• Iter 6: "Still no. Let me search the CRM again to confirm the customer ID." → tool call.
• Iter 7: "Let me try email logs once more." → same tool call.
• ...

This is the spiral that ate $47,000 in November 2025. Every iteration is plausible in isolation; in aggregate, it is a system burning tokens while not converging. Lesson 3 of this chapter focuses entirely on diagnosing and stopping this pattern.

Part Five: Guardrails

Guardrails are the policies, budgets, and checks that prevent the loop, the tools, the model, and the memory from producing outcomes you don't want. They are the most important component and the one most often missing in vendor demos.

The guardrails taxonomy

• Budget caps — max iterations per run, max tokens per run, max wall-clock per run, max tool calls per run, max dollars per run/day/week.
• Authorization caps — what the agent is allowed to do, scoped to identity. "This agent can refund up to $100 with no approval; above that, escalate." "This agent can read but not write." "This agent can send internal email but not external."
• Content gates — input filters (PII redaction, prompt-injection detection) and output filters (don't send anything containing customer credit card numbers).
• Approval gates (HITL) — irreversible actions require a human approval step. Sending external email, issuing refunds, closing accounts, escalating to legal.
• Observability — every model call, every tool call, every loop iteration is logged in a queryable store with timestamps, costs, and outputs. Without observability, you cannot diagnose anything.
• Kill switches — an out-of-band way to stop the agent now, that doesn't require the agent's cooperation. A red button. A revoked credential. A circuit breaker.

The 47-customer email incident

A real story from December 2025 (the team requested anonymity in the postmortem published on the company's engineering blog): a customer-success agent built on Relevance AI was given a tool called send_email_to_customer(customer_id, body). The agent's job was to draft a follow-up to one specific customer per run. A misconfigured prompt caused the agent to loop, and on each iteration it called send_email_to_customer with a different ID from a list it had pulled. By the time someone noticed, 47 different customers had received auto-drafted "checking in on your renewal" emails — including three customers who had already churned and one who was in active litigation with the company. The investigation found four missing guardrails: no max-tool-calls-per-run cap; no HITL gate on outbound external email; no per-day per-customer dedup check; no observability dashboard. Any one of those would have stopped it.

Guardrails are not a feature you bolt on after the demo. They are the half of the architecture that determines whether the agent survives contact with reality.

Mapping Real Tools to the Skeleton

Now the payoff. Once you have the five-part skeleton in your head, every agent product on the market sorts into the same diagram.

n8n (AI Agent node)

• Model: dropdown — pick OpenAI, Anthropic, Google, Mistral, local Ollama, etc.
• Tools: attach n8n nodes or MCP servers as tools to the Agent node. The Feb 2026 schema change tightened how tool arguments are declared.
• Memory: built-in working memory; long-term memory via separate Postgres/Pinecone/Mem0 nodes.
• Loop: the AI Agent node runs the ReAct loop internally; max iterations is a parameter.
• Guardrails: max iterations and timeout are first-class; budgets, HITL, observability are your job to wire up.

Lindy

• Model: per-agent choice from Anthropic, OpenAI, Google.
• Tools: "Skills" library — integrations with Gmail, Slack, HubSpot, etc., plus custom HTTP and MCP.
• Memory: built-in conversation memory; "Lindy Memory" beta for long-term.
• Loop: autonomous mode runs unbounded by default; "supervised mode" inserts HITL between turns.
• Guardrails: approval workflows, action limits per integration, audit log. Caps must be configured explicitly.

Salesforce Agentforce

• Model: Atlas Reasoning Engine — Salesforce-managed model selection, with some customer-byo options.
• Tools: "Actions" — Apex, Flow, prompt templates, API calls. Tightly bound to Salesforce metadata.
• Memory: conversation memory plus the Data Cloud as long-term store.
• Loop: the Reasoning Engine runs a constrained loop; many Agentforce "agents" are actually workflows with one model-driven branch.
• Guardrails: Einstein Trust Layer (PII masking, toxicity filter), permission set inheritance, audit log via Event Monitoring. Strong on enterprise compliance; weak on per-run cost caps unless you set them.

Microsoft Copilot Studio

• Model: Azure OpenAI under the hood.
• Tools: Power Platform connectors, custom MCP, plugins.
• Memory: Dataverse for long-term.
• Loop: "Autonomous agents" run loops; "Copilot" mode is single-turn.
• Guardrails: Purview integration, Entra ID for identity, content filtering. Excellent identity story; the loop caps are configurable but not always defaulted safely.

Relevance AI

• Model: dropdown.
• Tools: a deep library of pre-built tools plus custom.
• Memory: built-in plus optional external.
• Loop: "Agents" run a ReAct loop with configurable max steps.
• Guardrails: approval steps, scope limits, but the 47-customer incident showed the defaults can permit broad outbound actions.

How to Evaluate a New Agent Tool in 15 Minutes

Use the five-part skeleton as your interview script.

1. Model: "Which models are supported? Can I pick the model per node/step? What's the cost shown to the operator?"
2. Tools: "How are tools defined? Do you support MCP? What does an audit log entry look like? Can I scope tool access by user or role?"
3. Memory: "What memory layers exist? Where is long-term memory stored? How do I write/read facts from inside an agent run?"
4. Loop: "What's the default max iterations? Can I cap tokens per run? What happens if a tool errors three times in a row?"
5. Guardrails: "How do I require human approval before specific actions? Where is the kill switch? What's the audit story?"

If a vendor cannot answer any one of these crisply, you have just identified the risk surface of their product. That is gold for an operator-builder: you now know what to test, what to monitor, and what to ask the security team about.

The Missing-Component Diagnostic

When an agent misbehaves in production, run through the five parts as a diagnostic checklist. The bug is almost always a missing or under-specified component.

• Agent keeps repeating itself, asks same question repeatedly: memory is missing or scoped wrong. Add long-term memory; ensure session memory persists across runs.
• Agent does the wrong thing technically — wrong customer, wrong record, wrong amount: tools are too broad or unauthorized. Narrow the tool surface; add identity scoping.
• Agent costs spike unexpectedly: loop is unbounded or model is over-tier. Cap iterations and tokens; downsize model on cheap steps.
• Agent emits embarrassing or off-brand text: model choice or system prompt is wrong; possibly an input not filtered (prompt injection).
• Agent takes irreversible bad actions in production: guardrails are missing. Add HITL on irreversible actions; add per-action authorization checks.
• Agent works in testing, fails in production: almost always memory or identity. Test env memory is empty; prod has accumulated state. Or test env has god-mode credentials; prod has scoped permissions and the agent's tools silently fail.

Key Takeaways

• Five parts, every time: Model, Tools, Memory, Loop, Guardrails. If you cannot name all five for a system, you do not yet understand it.
• The tool surface is the product. Most failure modes trace back to tools that are too broad, unauthorized, or non-auditable. Spend more time on tools than on prompts.
• Memory is the silent killer. The agent that keeps asking the same question is not stupid; it is amnesiac. Build a memory model deliberately; mix structured state with vector recall.
• The loop must terminate. Max iterations, max tokens, max wall-clock, max dollars. All four. Always.
• Guardrails are half the architecture. Budget caps, authorization caps, content gates, HITL on irreversible actions, observability, kill switch. The 47-customer email incident was four missing guardrails in a trench coat.
• Map every vendor to the same five parts. Lindy, n8n, Agentforce, Copilot Studio, Relevance AI — all five components must be inspectable. Use the 15-minute interview script.
• Diagnose by missing component. When an agent misbehaves, ask which of the five is absent or under-specified. The answer is almost never "the model is dumb."