Why a working AI agent goes unused.

Ask why an AI project disappointed and the first guess is usually the model: it got things wrong, it could not handle the edge cases. Sometimes that is true. More often the agent works. It passed testing, it handles the cases it was built for, and three months after go-live the team has quietly gone back to doing the job the old way.

That is the most common way an AI agent fails in an Australian organisation, and it is the cheapest one to prevent, because it is decided in the design, not in the code. This piece sets out why a working agent goes unused, what adoption work looks like when it is done properly, and what to ask an AI consulting firm about it before you sign.

Five reasons a working agent goes unused.

None of these is a technical fault. Each is a choice someone made, usually without noticing they were making it.

• It was built for the manager, not the person doing the work. The brief came from the people who wanted a report. The people who would have to feed and check the agent every day were consulted once, if at all.
• It adds a step instead of removing one. Another screen, another login, or an output that lands in a mailbox nobody reads. If using the agent takes longer than ignoring it, it will be ignored.
• Nobody knows what it is allowed to get wrong. Without a clear rule for which outputs need checking, careful people check all of them. Then the agent saves nothing, and they are right to stop using it.
• The old way is still there, and still rewarded. The spreadsheet still works, the sign-off still asks for it, and nobody's targets changed. People follow what they are measured on.
• Trust broke early and nobody rebuilt it. One visibly wrong answer in the first week travels further than a hundred right ones. If no one explains what went wrong and what changed, the team draws its own conclusion.

Adoption is designed, not announced.

Training sessions and a launch email do not make an agent part of the job. Design does. Most of that design happens before anything is built.

• Watch the work first. Spend time with the people who do the task, at their desks or on their phones, before writing a line of the design. The workarounds they use today are the requirements nobody wrote down.
• Put the output where the work happens. If the team lives in the rostering system, the agent's suggestion belongs in the rostering system, not in a new portal.
• Make correction easy, and visible. A person who disagrees with the agent should be able to say so in one step, and should later see that the correction changed something. That is how trust is rebuilt after the first mistake.
• Agree what needs checking. Set out, with the team, which outputs are checked every time, which are sampled, and which are trusted. Revisit it as the numbers come in.
• Retire the old path on a date. Run both for a short, agreed period, then switch the old one off. An indefinite parallel run is a decision not to adopt.
• Name an owner on your side. One person who answers for the agent after the consultants leave, with the time to do it written into their role.

Use is also the first thing to measure. Our guide on how to measure an AI consulting engagement puts the 30-day question first for that reason: if the people meant to use it have gone back to the old way, nothing else in the results means much yet.

What this looks like in a care provider.

Care providers show the problem clearly, because the people an agent depends on are support workers and coordinators, not office staff. They work across sites, on phones, between shifts, and their time is already accounted for to the minute. An agent that drafts progress notes or checks claims only helps if it fits into that day.

In practice that means the agent drafts the note inside the tool the worker already uses at the end of a shift, a coordinator can reject a claim flag with a reason in one tap, and the coordinator's manager can see which flags were rejected and why. It also means agreeing up front which outputs a person must always check, which in care is a longer list than in most industries. Our pieces on AI for NDIS providers and AI for home care providers describe the work itself.

What to ask an AI consulting firm about adoption.

Most proposals describe what will be built. Few describe how it will be used. These questions tell you quickly whether a firm has thought about the second part.

• Whose work will you watch before you design anything? A good answer names roles on your side, not "stakeholders".
• Where will the output appear? The answer should be a system your people already use, or a reason why it cannot be.
• What happens when someone disagrees with the agent? Listen for a correction path and a named person who reviews corrections.
• How will you know, at 30 days, whether it is being used? If the firm cannot say how use will be counted, it will not be counted.
• What does the handover include? Documentation is the minimum. You also want your owner trained, the correction process running, and the measures reporting without the consultants in the room.

Put the answers in the brief and the statement of work. Our guides on how to write an AI consulting brief and what an AI consulting engagement looks like cover the rest of what both should say.

Signs adoption is already failing.

If an agent is live, these are worth looking for. Each is easy to check and none needs a survey.

• A spreadsheet that shadows the agent. Someone is keeping the old record "just in case". Find out what case.
• Overrides with no reasons. People are correcting the agent but not saying why, so nothing improves and the override rate stays where it is.
• Use concentrated in one person. The champion uses it and nobody else does. When the champion goes on leave, so does the agent.
• "I just check it anyway." Said once, it is caution. Said by the whole team, it means the checking rule was never agreed.

None of these means the agent was a mistake. Some agents should not have been built at all, and our piece on where AI agents do not work yet covers those. Most of the time, though, an unused agent can be recovered by doing the adoption work that was skipped.

Why RUBIX.

RUBIX is an independent Australian data and AI consultancy, founded in 2011. For 15 years a large part of our work has been reporting and analytics for Australian organisations, and the lesson from that work carries straight over to AI: a dashboard nobody opens fails the same way an agent nobody uses does, and for the same reasons. Three things follow for how we run an engagement.

• We work alongside the people who will use it. Our forward deployed engineers sit with your team, so the design starts from the work as it is done, not as it is described in a meeting. That is how our AI consulting in Australia is set up.
• We build for each role, not for the top. For a leading NDIS provider we worked alongside the operations, finance and compliance leads to join six disconnected systems into one governed data foundation, with a live role-based dashboard and security from support worker to director, inside eight weeks. Read the NDIS provider case study.
• Data first, so the agent can be trusted. Most early mistakes that break trust come from records that disagree with each other. We build the data foundation first so the agent works from one governed source.

If you are planning an AI agent, or have one that is not being used, start with a conversation about whose work it changes. That conversation usually tells you more than the demo.

Frequently asked questions.

General information only, not legal, financial or regulatory advice. Current as at October 2026.