Building AI agents with Base44: a practical architecture guide

What an AI agent actually is

An AI agent isn't a chatbot. A chatbot answers questions. An agent reads your data, makes decisions, runs workflows, and takes actions on your behalf — within boundaries you define.

On Base44, an agent is a configuration file that combines:

• Entity access — which database records the agent can read, create, update, or delete
• Backend function tools — specific server-side functions the agent can invoke (API calls, data transforms, external integrations)
• Channel deployment — where the agent lives (in-app, WhatsApp, Telegram)
• Workflow triggers — what starts the agent's work (a scheduled time, an entity change, a user message)

The architecture layers

Layer 1: Data and permissions

Start with your entities. The agent needs to read your data to be useful, but you should grant the minimum necessary. If the agent only needs to read customer records and create task records, don't give it update or delete on either.

Row-level security applies to agents too. Use user_condition rules to scope what the agent can see — for example, only records in a specific status or category.

Layer 2: Tools (backend functions)

Tools are the agent's hands. Each tool is a backend function that does one specific thing: fetch data from an external API, send an email, transform a document, generate an image.

Keep tools narrow. A tool that does "send an email" is better than a tool that does "handle all communications." The agent chooses between tools; if a tool tries to do everything, the agent can't reason about which one to call.

Layer 3: Triggers and workflows

Workflows connect your agent to the real world. A scheduled workflow can run your agent every morning to review new records and flag anomalies. An entity-triggered workflow can fire when a record is created, letting the agent process it automatically.

The key insight: the agent doesn't need to be always-on. It can be triggered, do its work, and hand the result back to a workflow that stores it, notifies a human, or kicks off the next step.

Layer 4: Channels

For in-app agents, you need a conversation UI. For external channels like WhatsApp or Telegram, the platform handles the messaging layer — you just configure the agent and connect the channel.

A real example

On a salvage vehicle calculator build, the agent architecture was:

• Entity access: read vehicle listings, read auction fee schedules, create evaluation records
• Tool 1: a backend function that parses listing descriptions into structured damage estimates using InvokeLLM
• Tool 2: a backend function that calculates total repair cost from parsed damage data and fee schedules
• Trigger: an entity workflow — when a new listing record is created, the agent runs the evaluation pipeline
• Output: an evaluation record with repair cost, profit estimate, and risk score, plus an email notification to the buyer

The agent never touches the UI. It does its work in the background, writes results to the database, and the frontend reads them.

Common mistakes

1. Too many tools. Five focused tools beat twenty vague ones. The agent can reason about five.
2. Too much entity access. Grant read on what the agent needs, not everything. An agent with full write access to your entire database is a liability.
3. No trigger strategy. An agent without triggers is just a chatbot. Decide what starts the agent's work before you build the agent.
4. Trying to do everything in one agent. If you have two distinct workflows (e.g., data processing and customer support), build two agents with different permissions and tools.

The bottom line

Agent architecture on Base44 is about boundaries: what the agent can see, what it can do, and what starts it working. Get those three right, and the agent becomes a reliable member of your workflow. Get them wrong, and you have an expensive chatbot.