From chatbot to AI employee. Ten years, five versions.

Jack and I started Rebotify in Melbourne in July 2016. Ten years this winter.

In that decade we have built, more or less, five different things and called them all "the product." Every one of them was, in hindsight, a step toward a question we did not yet know how to ask. The question, we now think, is the only one that matters: what outcome is the AI accountable for?

I want to walk through those five versions, because the history says something useful to anyone trying to make AI work inside a real business.

2016 — The rule-based chatbot.

We launched Rebotify as a no-code chatbot builder for Facebook Messenger, Slack, WeChat, and the web. You drew a decision tree and trained it on twenty ways someone might ask a question. The bot identified the likely question and gave the scripted reply. We thought we were selling automation. In practice, when the script ran out, the bot said “I’ll get a human” and the work landed back on a person’s desk. The bot took the easy part. The team still owned the hard part.

We targeted small businesses, then pivoted to enterprise in 2017 after the Melbourne Accelerator Program. AGL, Tiffany & Co, BUPA, Open Universities. Real contracts. Real volume. And — quietly — a real ceiling. The bots answered. They did not do.

2018–2019 — Connecting to business tools.

The fix was obvious: connect the bot to the systems where the work lived. Customer records, support tickets, calendars, and internal tools. We added APIs, the interfaces software uses to exchange information, so a chatbot could create a ticket, look up an account, book a meeting, or pass a case to the right team. Now it could do some of the steps a human would have done.

This was the first version that felt as though work was getting done. But the bot still followed the exact order we gave it. Every unusual case needed a new branch; every new system needed a connection we built by hand. The team spent less time teaching it questions and more time maintaining connections. The question remained: who owned the result when the bot missed a step?

2022–2023 — Chatbots powered by language models.

ChatGPT changed what a conversation could do. We replaced much of the hand-built question sorting with large language models (LLMs). The bot could now understand wording, tone, and ambiguity that the rule-based version would have passed to a human. The amount of scripting fell roughly tenfold.

But a better conversation did not automatically mean a completed task. A chatbot could give a convincing answer while leaving the customer’s problem unresolved. We had made the conversation better. We still needed to make the work better.

2024–2025 — AI agents.

Agents let us plan and carry out several steps, recover from a failure, and return a result. We rebuilt the core around that way of working: research a lead, draft the reply, record the deal, prepare a report, watch the inbox, and follow up tomorrow.

This is when we started using the word "employee" internally. Because the agent was no longer doing one trick. It was holding a small piece of someone’s role.

And this is also when we hit the next ceiling, the one that finally told us where we had been wrong all ten years.

We had been measuring the wrong thing.

Every version of the product, all the way back to 2016, was sold and measured on the technology inside it. Number of bots. Number of integrations. Number of agents. Tokens. Workflows. Coverage. The slide always had a count on it.

But no operator we have ever met cares about the count. They care about whether a thing got done. Whether the reply went out before the customer churned. Whether the deal moved. Whether Monday morning is calmer than last Monday. The number of bots doing the work is the vendor’s problem. The customer’s problem is the work.

Once we decided to sell and measure completed work rather than agents, the other decisions changed. Pricing stopped being per-token and became per-task, per-month, or per-result. We defined a role instead of delivering a dashboard. Success became “did the work arrive on time, at the right quality, in the customer’s tone?” rather than simply whether the agent was running.

This is also where we disagree with the argument that AI agents should not be called employees. The technical point is right: an agent is software. We use “employee” to describe how a buyer defines, prices, and reviews a role. It is a way to make the responsibility clear, not a claim that the model is a person.

2026 — AI employees.

This is what we are doing now: one named role responsible for a defined task. It keeps a customer-owned record of guidance and corrections while the model underneath can change. The service is organised around that job and its results.

Where the ten years were heading.

For ten years we kept building more capable AI: decision trees, tool connections, language models, agents, and managed roles. For nine of those years, the customer’s question stayed much the same: “Looks great. Where does it actually fit in our business?”

The answer that question wanted, all along, was: "Pick a job that needs an owner. Give me the outcome. I will give you back a teammate." Not a tool. Not a model. Not a fleet. A worker, with a name, accountable for a piece of work.

We could not have started here in 2016. The technology could not reliably carry out that work. Even at the start of 2024, agents struggled to finish multi-step tasks in a customer’s real systems. So we built and shipped five versions, and listened to the question customers kept asking.

What the customer kept rephrasing was always the same sentence, dressed differently each year: make this responsible for an outcome.

In 2026, we can put those pieces together: a model that plans, connections that let it use business tools, saved guidance, and human review. We can organise the service around the work, rather than the number of tokens or bots.

That makes the starting question much clearer: what result does the business need, and which part can AI prepare safely? Defining the job well matters as much as choosing the technology.

If you do not know where to start using AI, choose one recurring job and one result the team can review. You do not need a company-wide strategy before trying useful work. Let that experience guide what comes next.

Helping the team learn how to use AI is part of the service. Start with one managed task, review real output, and expand only when the work has earned the team’s trust.

It took us ten years to reach this way of working. Your first task starts smaller: first work ready for review within 48 hours of the setup meeting, once one recurring task is agreed and the required tool access is ready.