There is a specific moment in the workflow-to-agent transition that you can only experience once. It happens about thirty minutes into your first build, when you click run on an agent that has a tool palette of four tools and a goal written in plain English, and you watch it pick a tool you would not have picked, pass arguments you did not see coming, and return an answer that is approximately correct. The mix of "this is amazing" and "I have no idea why it did that" is the whole point of this lesson. By the end of the next ninety minutes you will have shipped a working tool-using agent in Lindy, Relevance AI, or n8n's LangChain integration, you will have read its trace step by step, and you will be able to explain every decision it made — including the surprising ones. The skill we are building is not "ship an agent." Operators have shipped plenty of bad agents. The skill is reading what the agent did and being right about why.

The Three Platforms and Why Each Matters in 2026

The 2026 no-code-to-low-code agent platform landscape narrowed faster than most operators expected. Three platforms dominate the operator-built tool-using agent niche, and they map to three different starting situations.

Lindy

Lindy ships pre-built agent templates for common operator tasks (inbox triage, meeting prep, lead enrichment, scheduling). The platform handles the loop, the tool palette, and the LLM provider routing. Operators describe the agent's job in English; Lindy assembles the tool palette. May 2026 pricing: $49.99/month for the Pro tier, which handles roughly 50,000 task-credits and includes the agent-loop runtime. The strength: fastest time-to-first-working-agent. The weakness: less control over the loop's behavior and harder to inspect when something goes wrong.

Relevance AI

Relevance ships the most mature no-code agent IDE in 2026. Visual canvas, drag-and-drop tool palette, explicit loop configuration, native trace viewer, and a "human-in-the-loop" step that drops directly into the canvas. May 2026 pricing: starts at $99/month, scales to $1,200+/month for production volume. The strength: the trace viewer is the best in the no-code segment. The weakness: the learning curve is steeper than Lindy because the platform shows you the loop.

n8n with LangChain integration

n8n's LangChain nodes (released throughout 2024-2025, matured by 2026) turn n8n into a full agent platform with the open-source / self-hostable footprint operators already trust. The LangChain agent node accepts a tool palette of n8n sub-workflows as tools, an LLM provider config, and an iteration cap. May 2026 pricing: free self-hosted, $20/month cloud Starter, $50/month cloud Pro. The strength: lowest cost per run, full data residency, and the agent shares infrastructure with the workflows that came before it. The weakness: the trace viewer is utilitarian compared to Relevance AI's.

Operators choose Lindy when speed matters most (often for proof-of-concept work and small-team agents). Relevance AI when the operator is building agents as a primary job function and wants the best inspection tooling. n8n LangChain when cost, self-hosting, or integration with existing n8n workflows matters most. In this lesson we walk through the same agent build on all three platforms so you can see which fits your situation.

The Agent We Are Building: The Inbound Lead Qualifier

The build is a small, real, useful tool-using agent. Specifically: an inbound-lead qualifier that takes a new contact form submission and produces a one-paragraph qualification summary plus a routing recommendation (sales, marketing nurture, or disqualify). The agent must use tools, must loop, and must produce a structured output your downstream workflow can consume. We picked it because every operator has shipped a workflow version of it; the agent version is meaningfully more powerful, and the build is small enough to finish in a session.

The tool palette (four tools)

• lookup_existing_account — searches your CRM for an existing record matching the email domain. Returns the most recent activity, current owner, and lifecycle stage.
• fetch_company_firmographics — calls Apollo or Clearbit (or any similar enrichment vendor) for company size, industry, recent funding, and headcount.
• search_internal_kb — queries an internal knowledge base for any prior mention of this company or anyone at this email domain (sales notes, support tickets, partnership conversations).
• produce_qualification — the final output tool. Takes a qualification summary, a confidence score, and a routing recommendation. When called, the agent's loop terminates.

The goal in English

You are an inbound lead qualifier. A new contact-form submission has arrived with the following data: {{name, email, company, message, source}}. Your job is to gather information using the available tools, then call produce_qualification with your assessment. Consider firmographics, account history, and any prior internal mentions. If you cannot find useful information after three tool calls, call produce_qualification with confidence "low" and a brief explanation.

The iteration cap

Five iterations max. Enough room for the agent to call each non-final tool once and then synthesize, but not enough room for it to loop indefinitely on tools that return empty results. We will see in the trace whether five is actually the right number.

Building It in Lindy

Time to first working build: approximately 35-50 minutes for a first-time builder.

Step 1: Create the Lindy agent

In the Lindy dashboard, click "New Agent." Pick "Custom" rather than starting from a template — for this exercise the template would hide the parts we want to see. Name the agent "Inbound Lead Qualifier." Lindy presents a sidebar with sections for trigger, tools, and behavior.

Step 2: Wire the trigger

Lindy supports many triggers; for this build use the "Webhook" trigger. Lindy generates a webhook URL. The contact-form vendor (Typeform, HubSpot Forms, custom site form, whichever you use) POSTs to this URL with the lead data. Lindy parses the JSON body and exposes the fields to the agent.

Step 3: Add the tools

Lindy's tool catalog has native integrations for HubSpot, Salesforce, Apollo, Clearbit, and a generic "HTTP Request" tool. For this build:

• lookup_existing_account = Lindy's HubSpot Contacts search tool, filtered by email domain.
• fetch_company_firmographics = Lindy's Apollo Enrich tool with company as input.
• search_internal_kb = Lindy's generic HTTP Request tool pointed at your internal KB's search endpoint (or, more commonly, a Lindy "ask Notion" or "ask Confluence" tool if those are connected).
• produce_qualification = Lindy's "Return structured output" tool, configured with a JSON schema (qualification: string, confidence: enum, routing: enum, reasoning: string).

Each tool gets a one-sentence description that Lindy passes to the model. The descriptions are the most important part. Lindy auto-fills descriptions from the integration, and the auto-fills are usually fine for the first three tools and need editing for produce_qualification (you want the model to understand this is the terminal tool, not just any output channel).

Step 4: Write the system prompt

The "Behavior" section is where the system prompt lives. Paste the goal from the previous section. Add: "Always call lookup_existing_account first. If the company is unknown to your CRM, then call fetch_company_firmographics. search_internal_kb is optional; only call it if firmographics suggest the company might be in our existing customer base or has previously appeared in support tickets."

The "always call X first" pattern is one of the most powerful soft constraints in agent design. The model usually follows it; the order discipline reduces wasted tool calls.

Step 5: Set the iteration cap

In Lindy's "Advanced" section, set max iterations to 5. Set the cost ceiling per run to $0.30 (Lindy enforces this and aborts the run if exceeded). Pick the model — Lindy supports Anthropic, OpenAI, and Google. For this build pick Claude Haiku 4.5 (cheap-and-obedient tier; the agent is a tool-caller).

Step 6: Test with a real lead

Lindy has a "Test" mode that simulates a webhook payload. Paste a real lead (with personal data scrubbed): name, email, company, message body. Click run. Watch the agent execute.

The first run will surprise you. Specifically: the model will call tools in an order you did not specify, will pass arguments derived from the lead's message body that you did not explicitly tell it to extract, and will sometimes call the same tool twice with different arguments to "verify" something. The agent finishes (call to produce_qualification with a populated JSON object) in 8-15 seconds and costs $0.04 to $0.12.

Step 7: Read the trace

This is the lesson. In Lindy's run history, open the trace. Lindy shows each turn — the model's reasoning summary (if you're using a reasoning model, otherwise it's a placeholder), the tool the model picked, the arguments it passed, and the tool's return value. Read every turn out loud. Explain to yourself why the model picked that tool, why it passed those arguments, and what it learned from the return.

If something surprises you, write it down. The trace is the feedback loop. Common surprises on first builds:

• The model extracted the company name from the email domain rather than the message body, because the domain was more reliable.
• The model called the KB tool with a different search term than you would have used, because it inferred the term from the message's topic rather than the explicit "company" field.
• The model called fetch_company_firmographics before lookup_existing_account, ignoring your "call X first" prompt — usually because the model decided the existing-account check would be quick to skip if firmographics already indicated the company wasn't a fit.

All three behaviors are correct, or at least defensible. Reading the trace is how you find out whether the agent's reasoning matches yours and where the gaps are.

Building It in Relevance AI

Time to first working build: approximately 45-70 minutes. The longer time reflects Relevance AI's more explicit canvas; you see and configure more of the loop.

Step 1: Create the agent in the Relevance dashboard

"Agents" tab, "New Agent." Name it. Relevance presents a canvas with three main areas: the system prompt panel on the left, the tool palette in the center, and the trace/test viewer on the right.

Step 2: Configure the tool palette

Relevance has a tool library, but the platform's superpower is that any "Tool" in Relevance can itself be a workflow built in the same canvas. For this build:

• lookup_existing_account — built as a "Salesforce Query" or "HubSpot Query" tool, depending on your stack. Relevance's native CRM connectors are the leanest setup.
• fetch_company_firmographics — Relevance has a native Apollo tool and a native Clearbit tool. Pick one. Configure the input schema (company name and domain) and output schema (size, industry, funding, headcount).
• search_internal_kb — Relevance has a native vector-search tool that hooks up to a Pinecone, Weaviate, or Relevance-hosted index. If your KB is in Notion or Confluence, build a small wrapper workflow that queries the source and returns structured chunks.
• produce_qualification — Relevance's "Output" tool with a JSON schema (qualification, confidence, routing, reasoning).

The tool description fields in Relevance are first-class, not afterthoughts. Spend three minutes on each description; the model uses them to decide when to call each tool.

Step 3: Configure the agent loop

Relevance shows the loop explicitly. You set "max iterations" (set to 5), "max tokens per turn" (set to 4000), "loop stop condition" (set to "produce_qualification tool called"). The loop config makes the contract visible: the model loops until it calls the terminal tool or hits the cap.

Step 4: System prompt and model

Paste the goal in the system prompt panel. Pick the model — Relevance routes to Anthropic, OpenAI, Google, Mistral, and DeepSeek. For this build pick Claude Haiku 4.5 again. Relevance shows you the per-turn cost in the test panel, so you can watch the spend accumulate as the agent works.

Step 5: Test with a real lead

Relevance's test panel takes JSON input. Paste the lead. Click run. The right-side trace panel populates in real time.

Relevance's trace is the cleanest in the segment. Every turn shows: the model's reasoning (with thinking tokens highlighted), the tool selection (with the model's stated rationale), the tool arguments (with each argument labeled as "from input," "from prior tool output," or "model-generated"), and the tool return (with size and parse status).

Step 6: Read the trace, find the surprises

Same exercise as Lindy. Read every turn. Explain every decision. Common Relevance-specific surprises:

• Relevance's "tool argument provenance" tagging will sometimes show "model-generated" on a field you assumed came from the input. This is the model inferring something the input did not contain — usually correctly, occasionally hallucinatorily. Worth pausing on.
• The reasoning highlights will sometimes show the model considered calling a tool, then decided not to. This is meta-information you don't see in Lindy and rarely see in n8n. It's gold for understanding the model's decision logic.

Building It in n8n with LangChain Nodes

Time to first working build: approximately 60-90 minutes if you have not used n8n's LangChain nodes before. The build is more granular because n8n exposes the framework primitives rather than wrapping them.

Step 1: Create a new workflow

In n8n, "New Workflow." Add a "Webhook" trigger node. Set the path to /inbound-lead. Test that it receives a POST with the lead data.

Step 2: Build the tool sub-workflows

This is the part operators new to n8n's LangChain feature underestimate. Each tool the agent uses is its own n8n workflow, exposed to the agent as a "sub-workflow" tool. You build four small workflows:

• tool-lookup-existing-account — a workflow that takes an email domain, queries HubSpot or Salesforce, returns the matching contact's recent activity, owner, and lifecycle stage. Title the workflow exactly that — the title is what the agent sees.
• tool-fetch-company-firmographics — a workflow that takes a company name + domain, calls Apollo or Clearbit, returns size/industry/funding/headcount.
• tool-search-internal-kb — a workflow that takes a search term, queries your internal KB (Notion API, Confluence API, or Pinecone for embedded chunks), returns top 3 results.
• tool-produce-qualification — a workflow that takes a qualification JSON object and writes it to a Postgres or Airtable table where the downstream router can read it.

Each sub-workflow needs its input schema defined in n8n's "Workflow input schema" feature (a JSON Schema definition). The agent reads this schema to know what arguments to pass.

Step 3: Wire the LangChain agent node

Back in the main workflow, add a "LangChain Agent" node. Configure:

• Tools — link the four sub-workflows. Each one becomes a tool in the agent's palette. The sub-workflow title is the tool name; the input schema is the tool argument schema.
• LLM — pick the provider node (Anthropic, OpenAI, Google, Mistral, Ollama for self-hosted). For this build use the Anthropic node and pick Claude Haiku 4.5.
• System prompt — paste the goal.
• Iteration cap — set "Max Iterations" to 5.
• Output parser — n8n's LangChain agent supports a structured output parser. Configure it with the same JSON schema produce_qualification expects, so the final output is parseable downstream.

Step 4: Wire the response

After the LangChain Agent node, add a "Respond to Webhook" node that returns the agent's structured output to the form vendor. The form vendor's success page can then show the lead a "thank you" message based on the routing.

Step 5: Test

Use n8n's "Execute Workflow" with a sample webhook payload. The execution log shows each tool call, the arguments, the return. n8n's trace is less polished than Relevance AI's but more granular — you see the underlying LangChain interactions, including the prompt template that was sent to the model.

Step 6: Read the trace

Same exercise. The thing n8n's trace exposes more than the others: the exact prompt that was sent to the model at each turn. This is invaluable for debugging. If the model is making weird decisions, you can read the prompt and often see why — "the tool description I wrote is ambiguous," "the system prompt says X but the user prompt says Y." The prompt-level visibility is the n8n LangChain superpower.

Reading the Trace: The Detailed Version

Across all three platforms, the trace-reading discipline is the same. Six questions to ask every turn:

1. What was the model's stated reason for picking this tool? Even if the platform doesn't expose chain-of-thought, the tool's arguments and the model's prior turn give you the implicit reason. Be able to articulate it.
2. Did the model pick the tool you would have picked? If yes, the agent has learned your decision logic. If no, decide whether the agent's choice was defensible (worth keeping) or wrong (system prompt or tool description needs editing).
3. Did the model pass the arguments you would have passed? Common surprises: the model passed a derived value (extracted company from email domain), passed a different search term than you expected, or passed a default where you expected a specific value. Each is worth understanding.
4. Did the tool return what the agent expected? If the tool returned an unexpected shape (an error, an empty result, a longer-than-expected response), did the agent handle it sensibly on the next turn?
5. Did the agent terminate at the right time? Did it call produce_qualification with enough information, or did it terminate too early (low-confidence output that could have been improved with one more tool call)?
6. Did the agent stay within the iteration cap? If the cap fired before the agent finished, the cap is too low or the agent is looping. Read the loop and decide which.

Read the trace this way on the first ten runs, every time. By run eleven, the pattern recognition kicks in and you can skim. By run fifty, you can read a trace in under a minute and find the issue.

The Three Failures You Will See in Your First Week

Operators who ship their first agent run into these three failures predictably. We have seen them so many times we can describe them in advance.

Failure one: the missing-tool failure

The model decides it needs a tool that isn't in the palette. It either invents a call to a fictitious tool (which the platform rejects, and the model tries again) or it tries to accomplish the work with a tool it does have, often awkwardly. Symptom: the agent's trace mentions a tool name you do not recognize, or the agent calls a tool with arguments that don't quite fit.

Fix: either add the missing tool to the palette, or update the system prompt to clarify what the agent can and cannot do. The latter is usually faster and avoids palette bloat.

Failure two: the ambiguous-tool failure

Two tools have descriptions the model finds interchangeable. The model picks the wrong one. Symptom: the agent consistently calls tool A when you would expect tool B, or it alternates between them without clear reason.

Fix: rewrite the tool descriptions to be sharply distinct. The trick is to start each description with a verb phrase ("Looks up..." or "Searches..." or "Fetches...") and end with a discriminating clause ("...when you need historical context, not current data"). The verb-plus-discriminator pattern is the most effective tool-description style we've seen.

Failure three: the early-termination failure

The agent calls produce_qualification (or whatever your terminal tool is) before it has gathered enough information. The output is a "confidence: low" qualification when it should have been "confidence: high" after one more tool call. Symptom: the agent terminates in fewer iterations than you expected, with weaker outputs.

Fix: add to the system prompt a soft requirement: "Before calling produce_qualification, ensure you have either firmographics OR internal KB context. If you have neither, call one of those tools before terminating." The model usually follows soft requirements. If it doesn't, the iteration cap is doing the wrong job (terminating instead of preventing runaway).

The After-Action Review: How to Get to Production-Ready

After the first successful run, the work shifts. The agent works. Now you need to know it works on the variety of inputs production will throw at it. Three steps to get from "works on the first test" to "works in production":

Step 1: Build the test set

Take twenty real leads from the last two weeks of form submissions (scrub PII appropriately). Run the agent on each, manually review the output. Mark each as "correct," "defensible," or "wrong." This is your eval set v1. Target: 90%+ correct or defensible.

Step 2: Tighten the prompts and descriptions

For every "wrong," go back to the trace and find the decision that produced it. Was it a tool description? A system prompt ambiguity? An iteration cap issue? Edit the cause. Re-run the test set. The first iteration usually moves correctness by 5-10 percentage points.

Step 3: Wire the production safeguards

Once you're at 90%+ correctness, wire the safeguards from Chapter 2.7: the audit log (every run writes a row), the approval card for confidence-low outputs (route to a human in Slack), and the three buttons (rollback, pause, kill) for the workflow. The agent is now production-grade.

The total time from "first build" to "production-ready" for an agent of this complexity is typically 6-12 hours, spread over a week. The first 90 minutes is the build. The rest is the calibration, the safeguards, and the trace-reading discipline that turns a working agent into a reliable one.

The Cross-Platform Mental Model

The three platforms differ in the surface area they expose, but the underlying agent contract is identical. Goal in English + tool palette with schemas + iteration cap + termination condition = agent. Lindy hides the contract under templates and natural language config. Relevance AI shows the contract on a canvas. n8n LangChain exposes the contract as wired primitives. Operators who internalize the contract can move between platforms in an afternoon; operators who learn one platform's UI without the underlying contract are stuck when the company switches tools.

The skill we are building in this lesson is platform-independent. The platform is the keyboard; the contract is the typing. Pick the platform that fits your situation today, and learn the contract because it is what transfers when the next platform appears in 2027.

The first agent you build is a tool palette, a goal, a cap, and a trace. The trace is the lesson. Every weird decision the model makes is information about what your palette descriptions actually said, what your prompt actually implied, and what your iteration cap actually allowed. Reading the trace is how you ship the next agent better.

Key Takeaways

• Three 2026 platforms dominate operator-built tool-using agents: Lindy ($49.99/month, fastest time-to-first-agent), Relevance AI ($99-1,200+/month, best trace viewer), n8n with LangChain nodes (free self-hosted, lowest per-run cost, integrates with existing workflows).
• The exercise build: inbound-lead qualifier with a four-tool palette (lookup_existing_account, fetch_company_firmographics, search_internal_kb, produce_qualification), iteration cap 5, Claude Haiku 4.5 as the cheap-and-obedient tier.
• Lindy build time: 35-50 minutes first-time. Wire trigger, add tools from native integrations, write system prompt, set iteration cap and cost ceiling, test with real lead, read the trace.
• Relevance AI build time: 45-70 minutes first-time. Canvas-based, explicit loop config, best-in-class trace viewer that shows tool argument provenance ("from input" / "from prior tool output" / "model-generated").
• n8n LangChain build time: 60-90 minutes first-time. Each tool is a sub-workflow; agent node wires them as a palette; exposes the actual prompt sent to the model at each turn — invaluable for debugging.
• Six questions to ask every turn when reading the trace: (1) stated reason for tool pick? (2) is it the tool you'd pick? (3) are the arguments what you'd pass? (4) did the tool return what was expected? (5) did the agent terminate at the right time? (6) did it stay within the cap?
• Three failures you'll see in week one: missing-tool failure (model invents a tool, fix prompt or add tool), ambiguous-tool failure (two tools have overlapping descriptions, rewrite with verb-plus-discriminator pattern), early-termination failure (agent terminates with low confidence, add soft requirement to prompt before terminal call).
• Tool description pattern: verb phrase at start ("Looks up..." / "Searches..." / "Fetches...") and discriminating clause at end ("...when you need historical context, not current data"). The verb-plus-discriminator pattern is the most effective style we've seen.
• After-action review: 20 real leads from last two weeks as eval set v1; mark correct/defensible/wrong; iterate on prompts and descriptions; target 90%+ correctness before adding safeguards.
• Cross-platform mental model: goal in English + tool palette with schemas + iteration cap + termination condition = agent. Same contract on all three platforms. Learn the contract and you can move between platforms in an afternoon.
• Total time from first build to production-ready for an agent of this complexity: 6-12 hours over a week. First 90 minutes = build. Rest = calibration, safeguards, trace-reading discipline.