Building AI Agents

Building an agent by hand means placing nodes, wiring tools, and writing prompts. With Forge, you describe who the agent is for — and review the result. This page walks through a real session end to end.

Start with the goal, not the graph

You:   I need a support agent for our tour agency. Customers ask
       about their bookings — status, dates, price.

Forge doesn't build immediately. First it looks around your application — the database, existing flows, connected services — and asks about the things it can't decide for you:

Forge: I found a "bookings" table with 8 fields, including status
       and dates. Two questions before I build:
       1. Should the agent only read bookings, or also change them
          (e.g. cancel a booking)?
       2. How should customers identify themselves — booking number,
          email?

Answering these takes a moment and saves a rebuild later. If you don't know yet, say so — Forge will propose a sensible default and note the assumption.

The agent needs a model

An agent runs on an LLM, and that means an LLM connector with your provider's API key. If your application already has one, Forge uses it. If not, it asks you for the key through a masked credential card — the key never goes through the chat — then creates the connector and tests it.

Review the plan and the approvals

For a task like this, Forge writes a plan (open it from the list icon in the toolbar) and then shows one approval card for the whole build:

Awaiting your input — Create agentflow "Booking Support Agent" · LOW — with rows for the agent node, its system prompt, the database tool, and the links between them.

Creating and editing the agent are low-risk draft edits, so with the default approval mode you'll often see no card at all for the build itself — only for things like a new table or credential. You can follow the Agentflow agent group in the chat as it works.

When it's done, the Changes made summary lists everything that was created — click the agentflow name to open it on the canvas and see the graph Forge built, laid out neatly.

Forge tests the agent for you

Here's the part that's easy to miss: after building, Forge talks to the agent itself — it opens a test chat, asks realistic questions, and checks that the agent answers and its tools don't fail:

Forge: I ran a test conversation with the agent:
       — "What's the status of booking #1042?" → it queried the
         bookings table and answered correctly.
       — "Cancel my booking" → it politely declined, as we agreed
         it should be read-only.
       The agent is working. Want me to adjust its tone or add
       more capabilities?

If something fails during the test — a tool errors out, the agent misunderstands its role — Forge fixes the draft and tests again, telling you what it changed.

Iterate in the same conversation

The first version is a starting point. Keep going in plain language:

You:   Make the tone more formal, and add: if a customer asks about
       a refund, collect their booking number and email, and save
       the request to a "refund_requests" table.

Forge will notice that refund_requests doesn't exist yet and offer to create it — that's a database change, so expect an approval card for it. This is how bigger agents grow: capability by capability, each one tested before you move on.

Want the agent to answer from your documents, follow a written playbook, refuse off-topic questions, or hand customers over to a second agent? Those are agent features — same conversation, same style of request.

Going live

When the agent behaves, ask Forge to deploy it. A high-risk card appears; approve it, and the agent gets a versioned, live chat endpoint. Details in Deploying.

What Forge asks approval for

Next steps