Skip to content

Guides4 min read

How to build an AI agent without code: a step-by-step guide

You do not need to write code to build an AI agent that does real work. You need a clear job, a model, a few tools and a way to see what happened on every run. This guide walks through the steps with one worked example, using a no-code AI agent builder, and ends with the agent running behind an API.

Oshadha VimukthiBuilder of Worfilo

What you are actually building

An AI agent is a model that reads an input, decides what to do, can call tools to look things up or act, and returns a result. Building one means choosing four things: the job, the model, the tools, and what should happen around it.

That last part is where most first attempts go wrong. An agent left alone with a goal and a pile of tools is hard to predict. An agent placed inside a small workflow, with fixed steps before and after it, is easy to test and easy to trust. That shape is called an AI agent workflow, and it is what a no-code builder gives you.

Step 1: pick one small job

The best first agent has a narrow job with a clear input and a clear output. Good examples:

  • Read a support ticket and decide how urgent it is.
  • Summarise a new GitHub issue and post it to Slack.
  • Take a lead's company name and return a short research note.

Write the job as one sentence, in the form "when X happens, do Y, and send the result to Z". If you cannot say it in one sentence, split it into two agents. The use case library has complete examples to start from.

Step 2: describe it and let the builder draft it

In Worfilo you can type that sentence and let Claude draft the workflow. It returns a validated graph that uses your connected apps and APIs, and you preview it before anything is created. For example:

Prompt
When a support ticket arrives, classify how urgent it is. If it is urgent,
post it to the on-call Slack channel. Otherwise draft a reply.

You get a trigger, an agent, a branch and two outputs on a canvas. Nothing is hidden: every step is a node you can click, read and change. See Generating workflows for how the draft is checked.

Step 3: give the agent the tools it needs

A model on its own can only read and write text. Tools are what let an agent act: call an HTTP API, use a connected app such as GitHub or Slack, or use any MCP server. In a canvas builder you connect a tool node to the agent, and the agent decides when to call it.

Keep the tool list short. An agent with two well-named tools makes better choices than one with twenty. The full walk-through is in how to give a Claude agent tools.

Step 4: make the agent return structured output

If the next step depends on what the agent decided, do not parse free text. Ask for structured output against a JSON Schema, so the result is always the same shape:

Agent output
{
  "urgency": "high",
  "topic": "billing",
  "reply": "Thanks for flagging this. We have refunded the charge."
}

Now the branch after the agent is plain logic: if urgency is high, go to Slack. The model makes one judgment call in a known place, and everything else behaves the same every time.

Step 5: test one node at a time

The slow way to improve an agent is to rerun the whole workflow after every prompt change. The fast way is to test the agent node alone, with a sample input, and read what it returned. Worfilo has a Test this node button for exactly this, and it shows the input and output of every node when you run the full graph.

Try the awkward cases early: an empty ticket, a very long one, one in another language. A replayable run history lets you reopen any run later on the graph that actually ran, which is how you find out why an agent made a surprising choice.

Step 6: protect personal data before it reaches the model

If the input contains names, emails or phone numbers, mask them first. A Mask PII node swaps them for tokens before the agent sees them, so the model never receives the raw values. See how to mask PII before it reaches the model.

Step 7: run it on its own, or ship it as an API

A working agent should not need you to press Run. You have three ways to start it:

  • On a schedule, such as every weekday at 9.
  • From a webhook, when another system sends an event.
  • Over HTTP, from your own code. Publish a version and every workflow becomes an endpoint you can call with an API key. See the workflow API.

Publishing freezes a version, so editing the draft never changes what production runs until you publish again.

Common mistakes when you build your first agent

  • Too many jobs in one agent. Split it. Two small agents are easier to test than one big one.
  • Free text between steps. Use structured output wherever a later step branches on the answer.
  • No way to see what happened. If you cannot open a run and read each step, you are guessing when something goes wrong.
  • Too many tools. Start with the one or two the job really needs.

Start building

Create a free account, describe the job in one sentence and let Claude draft the graph. Follow Getting started for the first run, and keep the node reference open for the details of each step.

Share this post

Build it on the canvas

Describe a workflow, watch every node run, and ship it as an API. Free to start.