How is this different from a chatbot with a long prompt?

A prompt gives the model everything at once. Here the conversation is built as steps, and each step exposes only the tools and knowledge it needs. Consequential actions are scoped to where they belong and can require confirmation, so the agent's reach is defined by the design rather than by how well the instruction was written.

Can the AI be talked into doing something it should not?

Required inputs are validated in code before a tool runs, not judged by the model, so a malformed order number or an out-of-range amount is rejected regardless of how the request was phrased. Gated steps add a confirmation requirement on top for anything that moves money or changes a record.

Can I connect my own systems as tools?

Yes. Any API-enabled system can be added as a custom tool with its own required inputs and validation rules, alongside built-in tools for stores, CRMs, sheets and payments.

AI & Automation

Advanced AI Agent

An agent you can actually put in front of customers.

Most AI builders give you a prompt box and hope. This one gives you a canvas. You lay out the steps a conversation moves through, decide which tools exist inside each step, and put checks in code around anything that matters — so the agent is useful without being trusted further than it should be.

Get Started Book a Demo

Agent builder

Orders & Bookingslive v7 Test Publish

Building blocks

Step

What to do, which tools

Automation

Call tools, no AI

Decision

Branch on saved info

Wait

Pick it up later

Talk to a human

Hand over with a summary

Ending

Success or not

Main

Agent, personality & rules

Answer from the knowledge base. Keep replies short. Never quote a price that is not in the catalogue.

collect order

start

2 tools · uses knowledge base

get_order_status

1when order is found → stage 2

2when not found → handoff

3when refund asked → refund step

stage 2

conversation only

refund step

gated tool

handoff

Talk to a human

done

Ending · Success

Safety netif stuck too long

Fires from every step

Knowledge base · 3 sources Ready to publish

A prompt is not a system

One long instruction has no boundaries: every tool is reachable at every moment, the model decides what counts as a valid order number, and a determined customer can talk it into things. The failure is rarely a wrong sentence — it is a refund issued on a number nobody checked, or a booking made against a slot that was never free.

What you get

A canvas, not a prompt box

Build the conversation as steps with paths between them, each step carrying its own instructions, tools and knowledge. Add decisions, waits, webhook triggers, human handoff and endings as blocks.

Tools scoped to the step

A tool only exists where you place it. Lookup helpers can be available everywhere, while anything that moves money or changes a record lives in the one step where it belongs — and can be gated behind confirmation.

Inputs checked in code

Tools declare their required inputs, and those inputs are validated mechanically before the tool runs. Format, range and conditional rules are enforced outside the model, so no amount of persuasion gets past them.

Custom tools and a safety net

Expose any API-enabled system as a tool of your own. A safety net catches conversations that stall or go off-script from any step, and hands them to a person with the context intact.

Tool scope

Available in every step

search_knowledgeread

get_order_statusread

Only in · refund step

check_refund_eligibilityread

issue_refundwrite Gated

issue_refund · required inputs

order_idstring

^ORD-[0-9]{5}$

amountnumber

≤ order.total

reasonenum

one of 6 values

A tool will not run until every required input passes its rule.

A tool only exists where you put it

Scope is the difference between an assistant and a liability. Read-only lookups can sit in every step, because the worst case is a wasted call. Anything that issues a refund, changes an address or takes a payment belongs to one step and nowhere else — and can be gated so it waits for a confirmation before it runs.

Global tools for lookups, step-scoped tools for actions
Gates require confirmation before a write executes
Any API-enabled system can be added as a custom tool

Input validation

Same tool, two attempts

Customer said"Refund order 12, it was 900 dirhams"

order_id formatamount ≤ order.totalTool blocked · agent re-asks

Customer said"Refund ORD-48210, AED 249"

order_id formatamount ≤ order.totalwithin 14 daysPassed to gate

The agent still judges tone, intent and what to say next. It never judges whether an order number is real, whether an amount is allowed, or whether a policy window has closed.

The checks that matter do not run on the model

When a tool declares an input, that input is validated mechanically before the tool is allowed to execute. A format rule, a numeric range, a condition compared against data you already hold — all of it enforced in code. The model can be persuaded; a regular expression cannot.

Format, range and conditional rules enforced outside the model
Conditions can compare against stored values, not just literals
The model still decides what to say — it just cannot skip the check

Runtimes

Orders & Bookings

One definition · steps, tools, guardrails

Chat

Answers customers directly across your channels.

Voice

Takes and makes WhatsApp calls with the same tools.

Copilot

Drafts in the inbox sidebar for an agent to approve.

Change the agent once and every runtime follows.

One agent, three places it works

The same definition — steps, tools, validation, guardrails — runs wherever you point it. It answers on chat, it picks up the phone, and it sits beside your team as a copilot in the inbox, drafting replies a human approves before they send.

Chat agent across WhatsApp and your other channels
Voice agent on WhatsApp calls, with the same tools
Copilot in the team inbox sidebar, suggesting rather than sending

How it works

1
Lay out the steps
Map the conversation on the canvas and give each step its instructions, its tools and its knowledge.
2
Set the boundaries
Declare required inputs, add mechanical validation, and gate anything consequential behind confirmation.
3
Test, publish, version
Run it against real cases, publish when it holds up, and roll back to a previous version if it does not.

Frequently asked questions

Related features

Keep reading — these work closely with this one.

Build an agent with boundaries

Map the steps, scope the tools, validate the inputs — then let it work on chat, voice and alongside your team.

Get Started See pricing