Fair questions.

ASCENTI is an Australian AI consultancy based in Helensvale on the Gold Coast. We map how a business actually runs, then design and build AI agents and automation that read documents, apply your rules and take action across the systems you already use, with approval gates you control and logging designed so you can see what happened. Six services: AI strategy, workflow automation, agentic AI design, AI architecture and custom builds, AI security and governance, and AI training.

Most AI fails because it gets bolted onto a broken process and judged on impressions. We start with the process and the economics, fix the workflow before automating it, ship real software to production, and agree upfront what would count as it working, so the result gets argued about on evidence rather than on how it felt. What that evidence is differs by workflow. If the honest finding is that a process is not worth automating, you get that answer instead of a build.

It will, sometimes; anyone who tells you otherwise is selling something. The difference is what happens next. We design for it: confidence thresholds, approval gates for anything consequential, logging of what the system did, and escalation to a person when it is not sure. Which controls a given build needs, and how tight they are set, is agreed with you during design. The aim is a system you can see into and stop rather than one that claims it will not err.

Humans stay in the loop where it matters, systems are designed with guardrails and an audit trail, and we work to the Voluntary AI Safety Standard published by Australia's National AI Centre and to the Essential Eight where your posture calls for it. We build on enterprise rather than consumer platforms, and we check each one's terms on training, retention and hosting against your obligations rather than assuming them. Your data and the business information you put into a system stay yours, and what happens to them is set out in writing for the system we build.

Cleanly. We come from the managed services world ourselves, so we work with your existing IT provider rather than around them. We design and build the AI layer; your provider keeps running the infrastructure. Where it helps, we brief them directly so nothing lands on them as a surprise.

We are not locked to one model. Anthropic's Claude is the usual default, accessed through enterprise rather than consumer platforms, with OpenAI's GPT models, xAI's Grok and open-source models used where they are the better fit for a specific task, or where hosting the model yourself is the right answer. Where your data goes depends on the architecture, and it is a design decision rather than a fixed company answer: hosting location, retention, training terms and logging are worked out against your obligations and written down for the system we build. If a workload has to leave the country, we say so and explain why.

Discovery first, scoped and priced to the size of the question and agreed before it starts. Whatever it recommends is then priced as its own defined piece of work: a build is quoted as a fixed scope, while advice, a process change or training is a smaller commitment. Ongoing support is optional and monthly. No open-ended hourly arrangements.

Not at all. Translating between the business and the technology is our job. You bring the domain knowledge (how the work actually happens, where it stalls, which exceptions matter) and we bring the AI. The people we most need access to during discovery are the ones doing the work, not the ones who understand the systems.

Typically five to two hundred staff. Below five, off-the-shelf tools usually solve the problem more cheaply and we will say so. Above two hundred the work fits well, there are simply more stakeholders in the room and discovery takes longer.

Our office is at 15–17 Millennium Circuit, Helensvale, on the northern Gold Coast. We work on site across the Gold Coast, Brisbane and South East Queensland, and remotely with clients right around Australia, on Australian time and with Australian context.

Discovery is usually days to a couple of weeks depending on how much operation there is to understand. Where a build follows, it is commonly four to twelve weeks depending on scope and how many systems it touches. Where the answer is a process change or training instead, it is faster than that.

Your data is yours, and so is the business knowledge behind the process: how your operation runs does not become ours because we automated part of it. The system itself normally runs as a hosted service, under an ongoing agreement covering hosting, model usage, third-party subscriptions and support, because a production system has running costs regardless of who manages it. You get plain-English documentation and a runbook, so what the system does and why is never opaque to you. Commercial terms, including anything about the code itself, are set out per engagement rather than by a blanket policy: raise it early and we will put the answer for your build in writing.

Discovery is usually days to a couple of weeks depending on how much operation there is to understand. Where a build follows, it is commonly four to twelve weeks depending on scope and how many systems it touches. Engagements that end in advice, a process change or training are shorter than that, and a fair number do.

In practice, yes, and it is a deliberate constraint rather than an upsell. Recommending or quoting anything without understanding the process produces either a padded estimate or a scope that changes three weeks in. What discovery looks like varies with the size of the question; that it happens does not.

Then that is the recommendation, and it is a reasonably common one. A surprising share of what we map is better fixed with a process change, an integration, a deleted approval step or a configuration change in software you already pay for. Saying so is the point of hiring someone who does not sell licences.

That is a legitimate outcome and everything is written to support it. You get the picture of the process, the shortlist and the recommendation regardless of who does the work. We would rather you use it than pay us to build something you had the capability to do internally.

Optionally. Some clients take full handover and run it themselves, some take a support retainer, and some keep us on to extend the system. All three are normal and the handover documentation is the same in every case.

It is scaled to the question. A single process in a small business is usually a few days of close attention; an operation spanning several teams and a decade of systems takes longer. We agree the scope and the cost before it starts, so the answer is a real number for your situation rather than a package length.

It depends on how much operation there is to understand, and we agree the number before any work begins. It is deliberately sized to be a decision rather than a project, so a business of five to two hundred people can commit to it without a business case.

A few hours a week from the people who run the process, plus one decision-maker available for the conversation about priorities at the end. We work around your operation rather than pulling people into rooms for days.

Yes, and we do regularly for clients outside South East Queensland. Observation over video works better than people expect, particularly for screen-based processes. For Gold Coast and Brisbane clients we do it on site because being in the room is better.

In practice, yes, and it is a deliberate constraint rather than an upsell. Recommending or quoting anything without understanding the process produces either a padded estimate or a scope that changes three weeks in. What discovery looks like varies a great deal; that it happens does not.

That is a legitimate and reasonably common outcome, and everything is written to support it. You get the picture of the process, the shortlist and the recommendation regardless of who does the work. We would rather you use it than pay us to build something you had the capability to do internally.

It varies enormously with scope, so any single number quoted without a conversation is marketing. What we can be specific about is the structure: discovery is scoped and priced to the size of the question and agreed before it starts, and whatever follows is priced as its own defined piece of work once we know what it should be. You get a real number before each commitment rather than an indicative range.

Because the work is not a product with tiers. Understanding one process at a twenty-person business and understanding an operation spanning four systems and three teams differ by an order of magnitude, and so do the things we might recommend afterwards. A published number would be either misleadingly low or unhelpfully high. Discovery exists precisely so the next number is real rather than indicative.

No. The first conversation is thirty minutes about a process that frustrates you, and it costs nothing. If the honest answer is that there is nothing worth doing, that is a shorter conversation and it still costs nothing.

That is our risk rather than your invoice. A fixed scope means a fixed price against the agreed specification. If you want something added mid-build it goes through a change process with its own price, agreed before it is done.

Discovery is a defined piece of work and whatever follows is another one. Where a system needs running afterwards, that is a monthly arrangement rather than a multi-year commitment. Your data and the business knowledge behind the process stay yours throughout, and the commercial terms for a given build are set out in writing before it starts rather than left to be discovered later.

Software that is given a goal rather than a set of instructions. It decides its own next step, uses tools to act on real systems, and keeps going until the task is finished or it hits a boundary you set. A chatbot answers questions; an agent completes work.

Automation follows a path someone drew in advance and is completely predictable. An agent works out the path from the specifics of the case, which makes it far better at variable inputs and harder to make predictable. Most good systems use both: deterministic automation for the spine of the process, agents at the two or three points where genuine interpretation is needed.

They are as safe as their tool scope, guardrails and approval design make them. An agent with read-only access to one mailbox carries almost no risk. An agent with write access to your finance system and no gates is a serious one. The safety is in the engineering around the model, not in the model.

In the work we do they remove the administrative layer around jobs (re-keying, chasing, document assembly, status reporting) rather than the jobs themselves. The realistic outcome is a team handling materially more volume while spending its time on the parts that need a person.

Running cost is model usage plus hosting, and it scales with volume rather than headcount. The per-run economics should be measured during design, before you commit to a build, and the workflow should be structured so the expensive reasoning only happens at the steps that require it.

We are not locked to one model. Anthropic's Claude is the usual default, accessed through enterprise rather than consumer platforms, with OpenAI's GPT models, xAI's Grok and open-source models used where they are the better fit for a specific task, or where hosting the model yourself is the right answer. Systems should be designed so the model layer is replaceable. Capability, price and availability in this field have moved substantially every year it has existed.

Most run two to four weeks, and the length is set by how much operation there is to understand rather than by a package. A single business unit with a handful of processes sits at the shorter end; several business units with a decade of accumulated systems sit at the longer one. We scope it before it starts.

Usually not, and the belief that you do is one of the most expensive delays in this field. Plenty of high-value automation reads unstructured input (emails, PDFs, forms) and never touches a warehouse. Where a genuine data problem blocks an opportunity, we say so and rank it accordingly rather than quietly assuming it away.

Then that is the recommendation, and it happens. A surprising share of the work we map is better fixed with an integration, a form, a deleted approval step or a configuration change in software you already pay for. Saying so is the point of hiring someone who does not sell licences.

Yes, and we usually do. We come from the managed services world ourselves. We design and build the AI layer; your provider keeps running the infrastructure. Where it helps, we brief them directly so nothing lands on them as a surprise.

Those tools are good, and where one of them solves your problem we will tell you to use it rather than sell you a build. What they struggle with is judgement on unstructured input, real exception handling, and processes with more than a handful of branches, the point where a flow becomes a wall of connected boxes nobody dares change. We build systems that read messy input, apply your rules explicitly, and carry an audit trail.

It will, sometimes. We design for that rather than against it: confidence thresholds, approval gates before anything consequential, logging of what the system did and why, and escalation to a person when it is not sure. Which of those controls a given build needs, and how tight they are set, is a decision we make with you during design. The aim is a system you can see into and stop, not one that claims it will not err.

A single well-scoped process is typically live in weeks, not quarters. The mapping and redesign is usually a larger share of the elapsed time than the build, which surprises people, and is exactly why we do not skip it.

Less than you would expect. Good automation slots into the existing shape of the work: the same inbox, the same system, the same approval going to the same person. What changes is that they are approving a completed draft instead of producing one.

Your data and the business knowledge behind the process are yours and stay yours. The automation itself normally runs as a hosted service: we build it, we run it, and you use it under an ongoing agreement covering hosting, model usage, any third-party subscriptions the workflow needs and our support, because a production AI system has running costs whoever manages it. How it works is documented in plain English so it is never a black box to you. Commercial terms, including anything about the code itself, are set out per engagement rather than by a blanket policy, so raise it early and we will put the answer for your build in writing.

A chatbot answers. An agent acts. A chatbot can tell you the status of an order; an agent can check the order, find the delay, draft the customer email, apply the credit within policy and update the CRM, then stop at a gate if the credit exceeds your threshold. The difference is tools and permission to use them.

Three layers. The agent only has the tools we give it, so there is no path to an action we did not scope. Guardrails constrain how those tools may be used: spend limits, policy checks, data boundaries. And approval gates stop anything consequential until a person says yes. Actions are logged with their inputs, at a level of detail agreed during design, so what happened can be reconstructed afterwards.

It will, sometimes; anyone who tells you otherwise is selling something. The design assumption is that it will. Confidence thresholds catch the cases where it is uncertain, evaluation suites catch systematic drift, gates catch the consequential mistakes before they land, and logs let you trace what happened. The goal is a system whose errors are caught, visible and cheap, rather than one that never errs.

In the work we do, they remove the administrative layer around people's jobs (the re-keying, the chasing, the document assembly) rather than the jobs themselves. The realistic outcome is that the same team handles materially more volume, and spends its time on the parts of the work that need a person.

Ongoing cost is model usage plus hosting, and it scales with volume rather than headcount. We size it during design so you know the per-run economics before you commit to a build, and we design the workflow so the expensive reasoning only happens at the steps that need it.

Buy, wherever a product fits. It will almost always be cheaper and better supported. Build when the off-the-shelf option would require you to change how the business works, when the process is the actual differentiator, or when the annual licence cost across your team exceeds what owning it outright would have been. We will tell you which of those applies, including when the answer costs us the build.

Mainstream, well-supported, boring-on-purpose choices: TypeScript, Python, React and Next.js, Postgres, and the major cloud platforms. We build primarily on Anthropic's Claude for model work. The test we apply is whether another competent engineer could pick the system up in a week.

Yes. A good share of the work is extending or integrating with systems that already exist rather than starting from nothing. We will review what is there and be straight with you about whether extending or replacing is the better economics.

You choose. Full handover and you run it, an optional support retainer, or an ongoing arrangement where we keep extending it. All three are normal, and the handover documentation is the same in every case.

It depends entirely on which AI and how it is configured, which is the point of this service. Consumer tools on free tiers generally reserve broad rights over what you submit. Enterprise platforms typically offer materially better terms on training, retention, hosting location and access logging, but the terms differ by vendor, tier and configuration, and whether yours are set that way is a question worth answering rather than assuming. The gap between those two positions is where almost all real exposure lives.

We would advise against it, and we say that as people from the security side. Blanket blocks push usage onto personal devices and personal accounts, where you have no visibility and no logs at all. A sanctioned, governed alternative plus a clear policy gives you far better control than a ban that quietly does not hold.

Typically one to two weeks depending on the size of the environment and how much telemetry is already available. You get the discovery report and the exposure assessment at the end of it, and the decisions about controls follow from there.

Possibly not for the controls, but usually yes for the assessment. Most Australian MSPs are excellent at endpoint and identity and have not yet built a practice around AI-specific exposure: which tool is seeing what data under whose terms. We work alongside your provider and hand the enforcement to them where that is the sensible split.

Directly. Enterprise clients and government buyers have started adding AI-specific questions to their vendor assessments: which tools you use, what data goes to them, what your policy is, whether AI-assisted work is reviewed. A completed governance engagement answers those questions with evidence instead of assurances.

Both, plus the AI features inside your existing business systems. We train on what you are licensed for. If you have not decided yet, we will help you pick first. Training a team on a tool you do not end up buying is worse than no training.

Hands-on sessions work best at twelve to twenty. Beyond that people stop practising and start watching, which defeats the point. Executive briefings scale further because they are a conversation rather than an exercise.

Yes, and a good share of our sessions are remote. We are on the Gold Coast and run in-person sessions across South East Queensland; anywhere else in Australia, remote works well provided the group is small enough for everyone to participate.

Yes. You get a short internal guide, the prompt and pattern library built during the session, and the safe-use policy. All of it is yours to circulate, adapt and use for onboarding new staff.

Yes. We integrate through supported APIs where the platform provides them, and design a defensible boundary where it does not. We will confirm exactly what is possible with your specific version and licence tier during discovery, before you commit to anything.

Every quote being different is why we do not try to automate the estimator away. What is highly repeatable is everything around the judgement: reading the request, extracting the scope, matching known items to the price list, checking stock and supplier pricing, and assembling the document. The estimator still prices the job. They just stop spending two hours getting to the point where they can.

Notifiable incidents carry statutory notification windows that vary by jurisdiction, and getting one wrong is serious. We build these workflows so the system does the assembly (classification against the rules, the register entry, the drafted notification, the deadline clock) and a qualified person always approves before anything is submitted.

Often it is a better fit at your size. Smaller businesses do not have a dedicated contracts administrator absorbing the paperwork, so it lands on the owner or the one person holding the office together, which means the hours returned go somewhere that matters immediately.

Yes. These are the systems we see most often in Australian RTOs, and each provides an API we can work with. The specifics depend on your version and licence tier, which we confirm during discovery before anything is committed.

It can, and we would not build it. Competency decisions are trainer judgements with regulatory consequences attached, and the risk of an automated marking decision failing an audit, or failing a student, is not worth the saving. We automate everything around assessment instead, which is where most of the time goes anyway.

By making audit time less of an event. Evidence is captured against the relevant clause continuously, so the pre-audit task becomes a review of a current evidence map rather than a reconstruction exercise. Gaps surface months earlier, when they are still cheap to fix.

The economics usually work better at small scale, because at two administrators there is no slack. Every hour absorbed by document chasing is an hour not spent on students or on growth. We scope to a single process first so the investment is proportionate and the return is visible before you commit to more.

It can be, and the architecture is the whole answer. That means enterprise rather than consumer platforms, the training, retention and hosting terms confirmed in writing rather than assumed, role-scoped access, de-identification where identity is not required, and audit logging. Which of those a given design needs, and what your obligations require, is worked out before anything is built. Consumer AI tools handling participant data would be a serious problem, which is exactly why a sanctioned governed option matters.

The obligation is that records are accurate, complete and made by the responsible person, not that they were typed by hand. A worker reviewing and confirming a note generated from their own voice record satisfies that; a system generating notes with no human confirmation would not. We build to the former.

That is the design constraint that matters most, and it is why the intake is a voice note rather than a form. If a system asks a support worker to learn an interface at the end of a twelve-hour shift, it will not be used, and no amount of capability compensates for that.

Prevention first. Validating service delivery against the plan and the price guide before submission catches most of what would be rejected. For the remainder, rejections are triaged automatically with the likely cause identified, so the person picking it up starts from a diagnosis rather than a code.

Accurate enough to be useful only if it is designed to know when it is not. The important number is not raw extraction accuracy but how reliably the system identifies its own uncertainty and stops. We build to per-field confidence thresholds and measure against a set of your real historical orders during the build, so you see the actual figures on your own documents before it goes live.

Most mid-market ERPs (MYOB Advanced, Netsuite, Pronto, Cin7, Unleashed) provide APIs we can create orders through. Older or heavily customised systems sometimes need a different approach, which we assess during discovery and tell you about before you commit.

Handled through a mapping you own and can inspect. The system learns from the corrections your team makes, so mappings improve over time, but they remain visible data rather than something inferred invisibly on each order, which matters when a mapping is wrong and you need to find out why.

You need fewer people typing and the same people applying product knowledge. In practice the role shifts to handling exceptions, managing the customer relationships behind them, and the work that was always being deferred because order entry consumed the day.

Into a consumer AI tool, no. Into an enterprise platform configured properly, with the training and retention terms confirmed, the hosting location known, matter-scoped access and logging in place, it becomes a reasonable proposition. Those terms differ by vendor and tier, so they are worth confirming rather than assuming. Either way it is a materially better position than the current reality of staff using personal accounts because nothing sanctioned exists. That gap is why our governance work and our automation work usually arrive together.

It replaces the work juniors currently learn on, which is a real problem worth naming rather than glossing over. The firms handling this well are moving juniors onto analytical and client-facing work earlier with more supervision, rather than hiring fewer of them. That is a deliberate decision about how the firm develops people, and it is better made on purpose.

It depends on your professional obligations, your engagement terms and the client. The trend across enterprise and government clients is clearly toward asking, and increasingly toward requiring disclosure in the engagement. We would rather help you write clear language into your terms now than have the question arrive in a tender response.

For administrative automation the honest measure is elapsed time and hours returned, not billable recovery. The hours come back as capacity, and what you do with that capacity is a management decision. We agree the metric before the build and instrument the system to report it, so the answer is measured rather than asserted.

The company name is new; the people are not. We have built and commercialised enterprise software for over fifteen years: ERP, e-signature platforms, systems Australian businesses run their operations on. We worked inside the Australian IT channel throughout. What is new is the label. Judge us on the work: the first engagement is tightly scoped and you will see exactly how we think before committing to anything bigger.

Deliberately small. Small enough that the senior engineers who scope your work stay involved in building it, and that we can start an engagement at a single process rather than needing a programme to cover overhead. If you need a large delivery team mobilised quickly, we are the wrong fit and will say so.

Born and based here, in Helensvale on the Gold Coast. We work remote-first with clients right across Australia, on Australian time and with Australian context. No offshore delivery team and no overnight hand-off.

On site across the Gold Coast, Brisbane and South East Queensland, and remotely Australia-wide. Distance changes the opening stretch of an engagement, so for clients outside SEQ we structure discovery differently rather than pretending it makes no difference.