How to Build a Custom AI Agent (No Code, Step by Step)

Most 'how to build an AI agent' tutorials hand you a Python framework and a weekend. This is not that. On an all-in-one platform where your business already lives, building a custom AI agent is a form you fill out, and you can have a working one before lunch.

Here is the whole flow in one breath: name the agent and write its role and instructions, choose which of your apps it can use, set what it is allowed to do with each one on a per-tool permission grid, set the guardrails that force it to ask before anything risky, pick where it runs, and test it. Six steps, no code, no APIs to wire, because the tools are already attached. This guide walks each step in order. If you want the deploy-it-to-your-website version specifically, how to add an AI agent to your website covers that channel end to end -- this guide is about configuring the brain behind it.

Do not build a do-everything agent. The agents that work are narrow: one job, one clear owner, one small set of tools. 'Answer booking questions and schedule appointments' is a good agent. 'Run my business' is not an agent, it is a wish.

So start by naming the job in a sentence. What should this agent do, for whom, and what does 'done' look like? Write that down before you touch the builder, because every choice that follows -- which apps, which permissions, how much autonomy -- falls out of that one sentence. If you have not yet, what a custom AI agent is frames the category; come back here when you know the job.

Open the agent builder in the AI Assistant and start a new agent. Give it a name and a role -- 'Front Desk Booking Agent,' 'Overdue Invoice Follow-Up,' 'Lead Qualifier.' The name is not cosmetic; it sets the agent's job in its own head.

Then write the instructions. This is the agent's brain, in plain English: what it does, the tone it uses, the facts it should rely on, and the hard rules it must never break ('never quote a price not on our list,' 'always offer a human for anything about a refund'). Think of it as onboarding a sharp new hire who is fast but takes you literally -- specifics beat vibes. If you would rather not start from a blank page, pick a shipped template like the Sales or Support agent; it arrives pre-briefed with sensible instructions and app access you can edit. Writing this well is its own skill, and a dedicated system-prompt guide in this cluster goes deeper.

Now give the agent its hands. A Deelo agent can reach the same roughly 597 tools across 49 apps the interactive Assistant uses, but a good agent gets a fraction of them. Select only the apps this job needs.

A booking agent needs Bookings and probably your CRM, and nothing else. An invoice-chaser needs invoicing and maybe accounting. Handing an agent every app 'just in case' is the most common mistake -- it widens the blast radius for no benefit and makes the agent's behavior harder to predict. You can also connect integrations here, like a Gmail, Outlook, or Calendar account, if the job reaches outside the platform. Narrow is safe and, usually, smarter.

This is the step that separates a real agent builder from a toy, and the one worth slowing down for. For each tool the agent can reach, you set what it may do, broken down by verb -- read, write, delete, send, receive -- and for each you choose one of three settings: off, allow, or allow-with-approval.

Read the customer record? Allow. Update a deal stage? Allow. Delete a contact? Off, or approval-only. Send an email to a customer? Allow-with-approval, so a draft lands in front of you before it goes out. This is the same permission model your human team members get, extended with send and receive for the things an agent does that a person clicks through manually. Set it deliberately per tool -- this grid is the difference between an agent you trust unattended and one you have to babysit. The companion guide on AI agent permissions and guardrails walks the full grid with worked examples.

The grid says what the agent can touch. Guardrails decide how freely it moves and what happens at the edges. Three settings do the heavy lifting.

Autonomy level. Assisted means it confirms every action with you -- good for the first week. Semi-autonomous means it handles routine actions on its own but stops to confirm anything destructive. Autonomous means it runs freely up to its limits. Start assisted, watch it, then loosen.

Destructive-action policy. A separate deny / confirm / allow switch specifically for the dangerous verbs, so even a mostly-autonomous agent still asks before it deletes or overwrites.

Max iterations. A cap, from 1 to 100, on how many steps the agent can take in a single run. It is a circuit breaker: even a confused agent cannot loop forever or run up a surprise bill.

And there is a floor you cannot switch off, on purpose. Moving money, writing financial records, touching employee or health data, changing security or credentials, integration writes, bulk changes, and external sends stay approval-required no matter how much autonomy you grant. An unknown tool defaults to require-approval. You cannot accidentally build an agent that wires money on its own -- the platform will not let you.

An agent is only useful where people can reach it. Decide the channel. Keep it inside your workspace as an internal coworker you chat with and assign tasks. Put it on a schedule so it runs recurring work -- every morning, every Monday, or one time at a set moment -- and reports the results back in its own chat thread. Or deploy it to a customer-facing channel: phone and SMS (on the Communications add-on) or a public, shareable web link (priced like regular AI Assistant chats).

One rule holds on any public channel: an anonymous visitor cannot approve high-risk actions, and a public web agent defaults to read-only until you deliberately open it up. That is not a limitation to work around; it is the reason you can safely hand a stranger a link to your agent at all.

Before it goes live, run it. Give it the happy-path task and watch it work -- 'book me Thursday at 2' should end in a real appointment, not a promise. Give it an out-of-bounds request -- 'refund the last order' -- and confirm it declines or defers instead of guessing. Give it something ambiguous and see whether it asks a smart clarifying question or barrels ahead.

If the risky test does anything but stop and check with you, tighten the grid before anyone else touches the agent. Then loosen autonomy gradually as it earns trust. Building the agent takes an afternoon; tuning it is a habit -- read its runs weekly, sharpen the instructions, and it gets sharper with it.