Custom AI solutions

AI solutions for business are systems that apply AI models to a specific commercial workflow, from answering customer enquiries to reconciling invoices. The category splits on one line: off-the-shelf tools that a team logs into, and built solutions that are wired into a company's own systems and data. Off-the-shelf wins when the workflow is generic. A built solution wins when the value depends on the company's specific stack, rules, and records, which is where most operational work lives.

Stack Integration and Native Connectors

A business AI solution is only as useful as its connections. For Australian businesses the stack it must reach is predictable: Xero or MYOB on the accounting side, a CRM or ERP such as HubSpot, Salesforce, or NetSuite for customer and order data, and Microsoft 365 or Google Workspace for mail and documents. The bar for each connection is direct read and write through the platform's supported API, so an accounting event can trigger a workflow and the result lands back in the system of record. A standalone chat window that answers questions about the business without touching its systems is an assistant, not a solution, because every answer still requires a person to act on it.

The pattern across our client base isn't an industry. It's a shape: knowledge-rich, process-heavy, and AI can't help until it understands the domain. That's the real reason stack integration matters more than model choice. The connectors get the agent to the data, but the build only works once the system understands what the business knows, its rules, its documents, its way of doing things. Which is also why Michael's line about this holds: AI can assemble information brilliantly, but it can't yet simulate what a founder knows a client will ask. The custom in custom AI is domain understanding, encoded. The integrations are how it reaches the systems. Buy both, in that order.

Governance, Security, and Control

Control of a business AI system rests on three mechanisms. Audit trails record every action and API call an agent makes and on whose behalf, which is what makes an autonomous system inspectable after the fact. Data sovereignty defines where company and customer data is processed and stored, which matters because personal information remains governed by the Privacy Act 1988 wherever the model behind the system runs. Escalation logic draws the boundary of autonomy: rules that force the system to hand an edge case, a low-confidence extraction, or a high-consequence action to a human operator. A solution missing any of the three can still work in a demo. It cannot be defended in production.

Security comes up in the first twenty minutes of nearly every regulated-industry conversation we have, finance especially. Founders raise data security as a gating concern before they ask about capability. So we learned to arrive with the security-first framing already done: data isolation, anonymisation, what runs where, which device logic applies. Having those answers ready doesn't just de-risk the build, it removes the objection that stalls deals and projects alike. My advice cuts both ways. If you're buying: raise security first and watch whether the provider has real answers or improvises them. If their governance story is assembled live in the meeting, so was their governance.

Implementation and ROI Metrics

The reliable implementation pattern is a fixed-scope pilot: one workflow, one integration set, a defined success measure, and a short build. That structure exists because the alternative, a broad transformation program, spends its budget before any workflow proves itself. Return is counted in operational terms: hours of manual handling removed per week, error rate against the human baseline, and cycle time from input to completed record. Multi-step handoffs are where the measurable gains concentrate, because each handoff a person no longer performs removes both the labour and the retyping errors that come with it. A solution that cannot state its before-and-after numbers has not been measured, and an unmeasured automation cannot be distinguished from a cost.

One correction to how this section usually gets read: ROI does not arrive until after adoption, and chasing it too early is a failure mode. We've watched it inside real engagements. The build lands, the metrics dashboard is ready, and the numbers disappoint for a month, not because the automation is wrong but because the team hasn't changed how it works yet. Measure from adoption, not from launch, and fund the adoption work as part of the build.

The other economics lever worth knowing: the model layer is now a cost dial, not a fixed fact. Open-source and cheaper models handle bulk work at a fraction of frontier pricing, and we actively pitch that mix because owning the unit economics is the maturity move in this market. A custom solution priced only against the premium model tier is leaving most of its own ROI on the table.

Related reading

• AI agent development services
• Workflow management software
• AI lead generation software
• AI agent vs chatbot

References

• Privacy Act 1988 (Cth), Federal Register of Legislation - https://www.legislation.gov.au/C2004A03712/latest/text
• Internal systems named on this page (triage, monitoring, dashboards, pipelines) are Hourglass internal tooling, not public. Class-b author-authority links (third-party press/podcast for Batko/Fin): OPEN - source at Pass 5.