To build first agent no-code builder, you need to understand four primitives: a model endpoint, a system prompt, short-term memory, and at least one tool. This tutorial assembles a support triage agent in Flowise, a mainstream open-source visual builder, and verifies the deployed flow with raw HTTP calls. You will point the model node at an OpenAI-compatible gateway so the agent survives provider hiccups.
Prerequisites
- A Flowise instance (cloud or self-hosted via
npx flowise start). - An API key from an OpenAI-compatible inference gateway. I used n4n.ai because it exposes one endpoint for 240+ models and handles fallback automatically, but any compliant base URL works.
curlandjqinstalled locally for testing.- Python 3.10+ to run a mock order API.
- A basic mental model of REST and JSON schemas.
Before you build first agent no-code builder flows, confirm you can reach the model endpoint and run a local service on port 8080.
Step 1: Verify the model endpoint
Run a minimal completion call against the gateway. This isolates auth and networking from builder complexity.
curl https://api.n4n.ai/v1/chat/completions \
-H "Authorization: Bearer $N4N_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4o-mini",
"messages": [{"role":"user","content":"say pong"}],
"max_tokens": 5
}'Expected output (truncated for clarity):
{
"id": "chatcmpl-abc123",
"object": "chat.completion",
"choices": [
{ "index": 0, "message": { "role": "assistant", "content": "pong" }, "finish_reason": "stop" }
],
"usage": { "prompt_tokens": 10, "completion_tokens": 1, "total_tokens": 11 }
}A 401 means the key is wrong. A 429 means rate limiting; a properly configured gateway should rotate to a non-degraded provider without client changes.
Step 2: Create the canvas and add a chat model
Open the Flowise UI. Click “New Flow” and select “Blank”. Drag a “Chat OpenAI” node onto the canvas.
Configure the node with these values:
- Base Path:
https://api.n4n.ai/v1(no trailing slash) - API Key: reference a stored credential, do not paste inline
- Model Name:
gpt-4o-mini - Temperature: 0.2
Keep temperature low for triage. Higher values introduce erratic tool calls and inconsistent classification. To build first agent no-code builder correctly, treat the model node as a configured client, not a black box.
Step 3: Add system prompt and memory
Drop a “Buffer Memory” node onto the canvas. Set window size to 6, meaning the last three user/assistant exchanges persist. For triage, that is enough context to resolve a follow-up question without bloating the prompt.
Draft the system prompt now. Precision beats length:
You are a support triage agent for Acme Corp.
Classify incoming messages as: billing, technical, or order_status.
If the user provides an order ID (format A followed by digits), call get_order_status.
Never invent order details. If the intent is unclear, ask exactly one clarifying question.This prompt constrains the agent to a single tool and forbids hallucinated order data. Vague prompts like “be helpful” produce unpredictable branching.
Step 4: Define and serve a tool
The agent must check orders. Run this mock server locally:
# mock_orders.py
from http.server import BaseHTTPRequestHandler, HTTPServer
import json
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path.startswith("/order/"):
oid = self.path.split("/")[-1]
body = {"order_id": oid, "status": "shipped", "eta": "2024-09-01"}
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.end_headers()
self.wfile.write(json.dumps(body).encode())
else:
self.send_response(404)
self.end_headers()
if __name__ == "__main__":
HTTPServer(("0.0.0.0", 8080), Handler).serve_forever()Start it: python mock_orders.py &.
In Flowise, add an “HTTP Request” tool node. Set method GET, URL http://host.docker.internal:8080/order/{order_id} (or localhost if not containerized). Then attach a function schema:
{
"name": "get_order_status",
"description": "Get fulfillment status for an order ID like A123",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string", "description": "Order identifier, e.g. A123"}
},
"required": ["order_id"]
}
}The no-code builder serializes this schema into the OpenAI function-calling payload. Missing required fields cause the model to omit arguments and the tool to fail silently.
Step 5: Assemble the agent
Add a “Conversational Agent” node. Connect:
- Chat Model → Model input
- Buffer Memory → Memory input
- HTTP Tool → Tools input
Set Agent Type to openai-functions. Paste the Step 3 prompt into the System Message field.
This is the core of how you build first agent no-code builder without writing an orchestration loop. The node runs the function-calling cycle: it inspects the user message, decides whether to call the tool, waits for the HTTP response, and synthesizes the answer.
Step 6: Test the flow via API
After saving, extract the flow ID from the Flowise URL (/flow/<flow-id>).
curl -X POST http://localhost:3000/api/v1/prediction/$FLOW_ID \
-H "Content-Type: application/json" \
-d '{"question":"Where is my order A123?"}' | jq '.text'Expected output:
"Your order A123 is shipped and estimated to arrive on 2024-09-01."If you get “I don’t have order information”, the tool schema name and the node’s expected function name diverged. Flowise logs show the exact payload sent to the model.
A full response object also includes chatHistory and sourceDocuments. Inspect those when debugging memory:
curl -X POST http://localhost:3000/api/v1/prediction/$FLOW_ID \
-H "Content-Type: application/json" \
-d '{"question":"Where is my order A123?"}' | jq '.chatHistory'Step 7: Multi-turn and fallback behavior
Send a follow-up with a session ID so memory keys correctly:
curl -X POST http://localhost:3000/api/v1/prediction/$FLOW_ID \
-H "Content-Type: application/json" \
-d '{"question":"Actually, I meant billing.","overrideConfig":{"sessionId":"user1"}}' | jq '.text'Without sessionId, the buffer memory resets each request. With it, the agent knows the prior order context if needed.
Because the model node points at the gateway, a degradation on one upstream provider does not break the flow. The gateway returns the same OpenAI-compatible shape from a healthy backend. Your visual agent requires zero redesign.
Common pitfalls
Trailing slashes on base URL. OpenAI clients append /chat/completions. A base path of https://api.n4n.ai/v1/ yields //chat/completions and a 404. Use https://api.n4n.ai/v1.
Tool name casing. Some builders lowercase function names; the model may emit Get_Order_Status. Align the schema name with the node’s expectation exactly.
Memory window too large. Window size 20 wastes tokens on irrelevant early turns. For triage, 6 is enough.
Secrets in flow exports. If you pasted the API key directly into the node, the exported JSON contains it. Use the credential store and scrub exports before version control.
Mock host resolution. Inside Docker, localhost:8080 points to the Flowise container, not your host. Use host.docker.internal on macOS/Windows or a docker network alias on Linux.
Extending the agent
Replace the mock with a real order API by updating the HTTP node URL and adding an Authorization header. Add a second POST tool named create_ticket with a schema containing email and issue fields. The same connect-and-test loop applies.
To build first agent no-code builder that holds up in production, put the Flowise endpoint behind an authenticated proxy, rate-limit predictions, and pull per-token usage from the gateway’s metering to track cost per session.
You now have a running, tool-using agent assembled entirely in a visual canvas, backed by a compliant model endpoint, and verified with curl. The pattern transfers to any OpenAI-compatible builder or gateway.