An agent goes a step further. It decides which steps and tools to use to finish a task: check an order, book a slot, file a ticket. Put the two together and you get an assistant that answers accurately and gets things done.

It also gets you a new class of failure. A RAG bot that hallucinates gives a wrong answer. A RAG agent that hallucinates can do a wrong thing. Here is the checklist we use at Dzimark when we build these.

Retrieval: get the right passages to the model

Clean before you chunk. Help articles, policies, manuals and contracts come with navigation text, repeated headers and stale copies. Strip that out first, or it ends up in every search result.

Split by meaning, search by meaning. Passages should be searchable by what they say, not only by keywords, so "can I send it back?" finds the returns policy.

Answer only from what was retrieved. The instruction to the model is explicit: answer from these passages, cite them, and say "I don't know" when the answer isn't there. Then offer another route, such as contacting the team, rather than guessing.

Show your sources. Linking each answer to the passage it came from lets people check, and it makes your own reviews much faster.

Agent tools: give it as little as possible

One tool per job. check_order_status(order_id) is better than query_database(sql). Narrow tools are easier to test and harder to misuse.

Limits inside the tool, not only in the prompt. If the agent may only look up orders for the signed-in customer, the tool enforces that. Prompts are guidance; code is a rule.

Human approval for anything sensitive. Refunds, account changes and anything that costs money wait for a person. Many teams start with every action needing approval and relax that gradually as the logs prove the agent reliable.

Log every action. Which tool, which arguments, which conversation, what came back. When something goes wrong, the log is the only witness.

Memory: enough context, not a diary

Conversation memory lets the agent follow a multi-step request without asking the same questions twice. Keep it to what the task needs. The more an agent remembers, the more personal data you are storing, and the more you have to protect and eventually delete.

Data: keep it where it belongs

Follow least-access principles: the assistant reads the documents it needs and nothing else. Keep data in your own accounts where possible, and where it must not leave your servers, use private or self-hosted models.

Keeping it accurate after launch

An assistant is only as good as the information behind it, and that information changes.

• A simple content process. Someone owns adding, updating and removing documents, without needing a developer, so answers don't drift when products, prices or procedures change.
• Regular conversation reviews. Look at the questions it couldn't answer, the answers people marked unhelpful and the actions that failed. These usually point to missing or unclear documents, and fixing them improves your help centre for human readers too.
• Adjust limits from evidence. Loosen an approval rule only when the logs show the tool behaving.

Start small

The pattern that works: one team, one type of request, one set of approved documents. Prove the value there, then add sources and actions in phases. Because the assistant answers only from approved content, adding a new area is mostly a matter of adding the right documents.

Checklist

• Documents cleaned, split into passages, searchable by meaning
• Model answers only from retrieved passages, with citations, and admits when it doesn't know
• Narrow tools, limits enforced in code
• Human approval for refunds, account changes and anything costly
• Every action logged
• Memory limited to what the task needs
• Least-access data; private or self-hosted models where data must stay in-house
• An owner for the content and a regular review of failed questions and actions

The business-side overview, with use cases for help centres, staff procedures and support, is on the Dzimark site: AI agents in RAG chatbots.

Rendering: own pixels vs native views

Flutter draws everything itself. It bypasses the platform's UI widget libraries, compiles the painting code to native code and renders through Impeller, an engine shipped inside your app. You get Material and Cupertino widget sets, or your own design system.

React Native maps to native views. At runtime it creates the matching Android and iOS views for your components, so a button is backed by the platform's own view.

What that means for the product: Flutter makes a pixel-identical UI across devices easy, because one engine draws it all. React Native picks up platform conventions more naturally. Decide which one your brand needs before you decide anything else.

Performance: architecture, not hype

• Flutter's argument: frameworks layered on native UI libraries add overhead, so it paints its own widgets in compiled code.
• React Native's New Architecture (default since 0.76) replaces the async bridge with JSI, so JavaScript can call native methods without serialisation. Its own docs say this won't automatically speed up every app.

For a typical MVP both are fast enough; code quality matters more. If your core feature is heavy real-time work (camera processing, complex animation), prototype that one screen in both before committing.

Languages and hiring

• React Native: JavaScript, with new projects targeting TypeScript by default, running on the Hermes engine. If you already have React developers or a React web app, people and logic can move between web and mobile.
• Flutter: Dart, AOT-compiled for release, with stateful hot reload in development. You'll usually hire Flutter developers specifically, but the whole app lives in one language and one toolkit.

Whichever you pick, ask candidates for apps that are live in the App Store and Google Play.

Reaching native APIs

• Flutter: platform channels to Kotlin/Swift, dart:ffi for C APIs, and platform views for complex native controls such as maps (with some overhead).
• React Native: Turbo Native Modules. You describe the interface in TypeScript or Flow, Codegen generates the platform glue, and your Kotlin/Java/Swift/Objective-C implementation plugs in.

Both can be added to an existing native app screen by screen (Flutter's add-to-app; React Native's integration with existing apps).

Beyond mobile

Flutter officially targets Android, iOS, web, Windows, macOS and Linux, though its own FAQ says Flutter web suits app-like experiences, not text-heavy pages that need search indexing. React Native targets Android and iOS; macOS, Windows and web (via React Native Web) are out-of-tree platforms, and the team recommends starting with a framework such as Expo.

When to skip both

Go native (Swift/SwiftUI, Kotlin/Jetpack Compose) when you're building for one platform only, need new OS features on day one, do demanding graphics, audio or background work, or already have iOS and Android engineers. The cost is two codebases.

A decision rule for the MVP

• React Native if you have React/TypeScript people or a React web app to share with.
• Flutter if you want one tightly controlled design across platforms, or desktop later from the same code.
• Native if you're single-platform or your core feature lives deep in the OS.

Then list the MVP's must-have features and check a maintained package exists for each, and agree up front who owns the code and the store accounts.

The full guide, with links to every source, is on the Dzimark blog: Flutter vs React Native: which is right for your startup app?

Does the client even need to comply?

The APPs apply to "APP entities": Australian Government agencies and organisations covered by the Privacy Act. Many small businesses are exempt because of an annual turnover threshold, but some are covered whatever their size, for example private health service providers and businesses that buy or sell personal information. The OAIC has a tool to check. Even when a client is exempt, building to the APPs is a sensible default: it is what customers expect, and the business may become covered as it grows.

The principles that touch your code

• APP 1, transparency: a clear, current privacy policy, linked from every page (usually the footer).
• APP 3, collection: collect only what is reasonably necessary. Every extra form field needs a reason.
• APP 5, notification: tell people, at or before collection, who is collecting, why, and where to find the privacy policy. A short notice next to the form's submit button does this well.
• APP 8, cross-border disclosure: if form data, CRM records or backups go to providers outside Australia, the privacy policy should say so, and the client stays accountable for how those providers handle it.
• APP 11, security: take reasonable steps to protect the data, and delete or de-identify it when it is no longer needed.

A practical checklist

1. Forms: remove fields nobody uses; add a one-line collection notice and a link to the privacy policy; send submissions over HTTPS only.
2. Analytics, cookies and pixels: list every tag on the site and what it sends. Session-replay and ad pixels deserve particular care, because they can capture far more than intended.
3. Hosting and third parties: note where the server, email provider, CRM and backups are located, so the privacy policy can be accurate about overseas disclosure.
4. Security basics: keep the CMS and plugins updated, use strong admin authentication, limit who can export form data, and set a retention period for old enquiries.
5. Breach readiness: the Notifiable Data Breaches scheme requires covered organisations to notify affected people and the OAIC about eligible data breaches. Agree in advance who decides and how they are reached.

Read more

The full guide covers each principle in more detail, with links to the OAIC sources: Getting a website ready for the Australian Privacy Principles.

Written by the team at Dzimark, a website, app and AI development company working with businesses in Australia, the USA, the UK and Canada.

What should your chatbot do, and what should it not do?

Start with one or two clear jobs. Good first jobs for a small business are:

• answering questions about products, services, opening hours, delivery and returns;

• collecting enquiry details and passing them to your team;

• booking a call or an appointment;

• finding the right page on your website.

Write down what the chatbot must not do as well. For most businesses that list includes giving legal, medical or financial advice, promising prices or delivery dates it cannot check, and discussing topics that have nothing to do with your business. These limits become instructions for the chatbot and test cases later.

Which content will it answer from?

A general-purpose AI model knows a lot about the world and nothing about your business. To answer correctly, a business chatbot needs your own content: service pages, FAQs, policies, product data and opening hours. The usual approach is called retrieval-augmented generation (RAG): when a question comes in, the system finds the most relevant passages from your content and asks the model to answer from those passages only.

Before you build, check your content:

• Is it up to date? A chatbot repeats old information as confidently as new information.

• Is it complete? If your returns policy is only in someone's head, the chatbot cannot know it.

• Does it contradict itself? Two pages with different delivery times will produce inconsistent answers.

• Who will keep it current, and how will changes reach the chatbot?

Our page on RAG AI agents explains this approach in more detail.

When should the chatbot hand over to a person?

A chatbot should know when to stop. Plan the hand-off before launch:

• When it does not know. If the answer is not in your content, it should say so and offer to pass the question on, not guess.

• When the customer asks. "Can I talk to someone?" should always work.

• When the topic is sensitive. Complaints, refunds and anything involving health or money are often better handled by people.

• Outside your hours. Decide what the chatbot promises when nobody is available: a call back the next working day, an email reply, or a booking link.

Make sure every hand-off reaches a real inbox or dashboard that someone checks. A chatbot that collects enquiries nobody reads is worse than a contact form.

How will it handle personal data?

Customers will type names, phone numbers, email addresses and sometimes much more sensitive details into a chat box. Decide in advance:

• what the chatbot asks for, and why you need it;

• where conversations are stored, for how long and who can read them;

• which AI provider processes the messages, in which country, and whether that provider may use the data to train its models;

• how a customer can ask you to delete their conversation.

Update your privacy policy to describe the chatbot. Privacy laws differ by country, so check the rules where your customers live, and tell people clearly that they are talking to an AI system. In the European Union, for example, the AI Act includes a transparency duty to inform people when they are interacting with an AI system.

Who is responsible for what it says?

You are. In 2024 a Canadian tribunal decided that Air Canada was responsible for incorrect information its website chatbot gave a customer about a fare policy, and rejected the argument that the chatbot was a separate entity. Treat chatbot answers like any other content on your website: if it says something, your business has said it. That is why the content checks, the limits and the hand-off rules above matter.

Which model and channels should you choose?

Most business chatbots use a model from one of the large providers, such as OpenAI, Anthropic or Google, or an open-weight model that can run on your own servers. The right choice depends on answer quality in your language, speed, data-handling terms and running costs, which are usually charged by usage. You do not need to decide this alone: a developer should be able to test two or three models on your real questions and show you the results side by side.

Think about where customers already talk to you. A chat window on your website is the usual start. Many businesses also connect the same assistant to WhatsApp through the WhatsApp Business Platform, or to their help desk.

How do you test it before launch?

Collect 50 to 100 real questions from your emails, calls and messages, including awkward ones. Then check:

• Does it answer correctly from your content, and link to the right page?

• Does it refuse politely when the question is outside its limits?

• Does it hand over when asked, and does the enquiry arrive?

• Does it behave when someone tries to make it ignore its instructions?

• Does it work on a phone, with a keyboard and with a screen reader?

Fix the content and the instructions, then test again. Keep the question list: it becomes your regression test every time you change the chatbot.

What should you watch after launch?

Read a sample of conversations every week for the first month. Track a few simple numbers: how many conversations end with an answer, how many need a person, which questions it could not answer, and how many enquiries or bookings it produced. The unanswered questions are the most useful list you will get: each one points to a gap in your website content as well as in the chatbot.

If you want a chatbot planned and built this way, see our AI chatbot development service or our wider AI solutions. We are also happy to review a plan you already have: get in touch.

FAQ

Can an AI chatbot replace my customer service team?

For most small businesses, no. It can answer routine questions and collect enquiries at any hour, which frees your team for the conversations that need a person. Plan for a clear hand-off from the start.

Why does a chatbot sometimes make up answers?

Language models generate likely-sounding text. If the answer is not in the content they are given, they may guess. Answering only from your own content, and telling the chatbot to say when it does not know, greatly reduces this.

Do I need to tell customers they are talking to a bot?

Yes, it is good practice everywhere and a legal requirement in some places, such as the European Union under the AI Act. A short line at the start of the chat is usually enough.

How long does it take to set up a business chatbot?

It depends mostly on your content and integrations. A chatbot that answers from a few well-written pages is much quicker than one that books appointments, checks orders and connects to several systems.

Originally published on the Dzimark blog.