AI for the AU mid-market. Not the keynote case study.

The keynote stage is not the mid-market. The AI case studies that circulate at conferences and in vendor marketing involve organisations whose names a mid-market Australian business would not find in their competitive set: major banks, national retailers, government agencies, global insurers. The deployments in those case studies involve data teams, integration infrastructure, multi-year implementation timelines, and change management budgets that the mid-market does not have and was not planning to have.

The mid-market is not the enterprise with a smaller budget. It is a different kind of organisation, with different constraints, different relationships with technology, and a different definition of what a successful AI deployment looks like.

What the AU mid-market actually is

The mid-market in Australia covers businesses with roughly 50 to 500 employees and annual revenues in the tens to hundreds of millions. They are large enough to have complex operational problems and specialised functions. They are not large enough to have a dedicated AI team, a data science capability, or the integration infrastructure that enterprise AI vendors assume as a baseline.

The sectors that define the AU mid-market are specific: mining and resources, construction and civil infrastructure, health and aged care, industrial services, transport and logistics. These are not the sectors that appear in AI conference presentations. They do not have the brand recognition of the case studies that get showcased. They represent a substantial part of the Australian economy and a small fraction of the AI deployment examples that circulate in industry conversation.

The mid-market in these sectors has real operational problems that AI can address. Scheduling and resource allocation in construction and civil works. Clinical documentation and care coordination in health and aged care. Equipment monitoring and maintenance planning in mining and industrial services. Safety documentation and compliance tracking across all of these. These are not aspirational use cases. They are problems the people running these businesses are trying to solve today.

Why enterprise AI does not fit

The enterprise AI product is built for the enterprise. It assumes data infrastructure at scale, an IT function capable of managing the integration, procurement cycles measured in months, and a change management process to roll out new tools across large teams. The enterprise AI product often requires a partner implementation to deploy.

The mid-market does not have these resources. More importantly, the mid-market does not have these resources because it does not need them for the rest of its operations. A construction company with 200 employees does not have a data team, because a construction company with 200 employees does not need a data team to run a construction company. Adding an AI tool that requires a data team to operate is not a solution. It is a new problem.

The mid-market has also been exposed to the keynote version of AI long enough to have calibrated expectations. The case studies are compelling. The implementations at mid-market scale frequently are not. The gap between the keynote and the deployment is a trust problem, and it is a trust problem the vendors have created by presenting enterprise-scale results to mid-market buyers without adequate context.

The keynote case study is always an enterprise deployment. The mid-market is not the enterprise.

The mid-market does not need a scaled-down version of the enterprise AI platform. It needs a different product form: something that can be engaged at the level of a specific operational problem, by a specific person or team, without requiring the data infrastructure or IT capability that the enterprise product assumes.

The co-worker as the right product form

A co-worker holds a brief. They know a specific domain well enough to produce professional-quality work in that domain without detailed instruction. They can be engaged for a specific project or a continuing operational need. They do not require a full integration into the organisation's data infrastructure to be useful. They work on what they are given.

This is the right product form for the mid-market because it matches the way the mid-market actually engages with specialist capability. A construction company does not hire a full-time safety documentation specialist. It engages a contractor when the project requires one, or it uses a service that provides the specialist capability on an as-needed basis. The co-worker model is the AI version of that engagement pattern.

The mid-market is already comfortable with the idea of engaging specialist capability as a service. What it is less comfortable with is the AI version of that capability, because the AI versions it has been offered are either general-purpose tools that require configuration work the mid-market does not have the capability to do, or enterprise platforms that require infrastructure the mid-market does not have.

The co-worker line is built for the mid-market because it provides specialist capability in a form the mid-market can engage with: specific, sector-relevant, operational-problem-focused, without the integration requirements of the enterprise product.

A co-worker holds a brief. At mid-market scale, that is the right unit of AI engagement.

What implementation actually looks like

Enterprise AI implementations are described in case studies. Mid-market AI deployments need to be described in operational terms, because the people making the decision are the people who will be using the product, not a procurement team evaluating a proposal.

An implementation of a Graaft Digital Worker at mid-market scale starts with domain construction: building the co-worker's working knowledge of the specific sector, the specific organisation's context, and the specific role the co-worker is filling. This is not configuration in the sense of filling out a settings form. It is the work of documenting how the organisation's operational environment works, what standards apply, what language the domain uses, and where the co-worker's scope begins and ends.

Once the domain is constructed, the co-worker connects to the data and systems it will work with. For a construction project controls co-worker, this means read access to the project scheduling tools and the document management system. For a clinical reporting co-worker, it means access to the patient management system and the compliance documentation environment. The integration is typically lightweight by enterprise standards: the co-worker is connected to the specific systems it needs, not to the organisation's entire data infrastructure.

The co-worker then enters a review period: briefs come in, output is produced, and that output is reviewed by the person it reports to in the organisation. The review period surfaces gaps in the domain construction and the integration, and those gaps are closed. Then routine operation: the co-worker runs, the output is reviewed, and the person responsible for the role can spend their time on the work that requires judgment rather than the work that requires documentation, scheduling coordination, or data analysis at scale.

The implementation is not a software rollout. It does not require a change management programme or a training curriculum. The co-worker is introduced to the team as a named specialist, the team is briefed on what the co-worker does and what it does not do, and the work begins. The mid-market can absorb this at the pace of a new team member starting, because that is the closest analogue to what it is.

The trust problem the market has

The AU mid-market in 2026 has a specific relationship with AI vendors that is worth naming, because it shapes what kind of introduction a new AI product needs to make.

The trust problem is not that the mid-market is sceptical of technology. These are organisations that run complex operations with significant technology dependencies. They use project management software, maintenance planning systems, clinical management platforms, and productivity infrastructure that would have been unrecognisable fifteen years ago. They are not technology-averse.

The trust problem is that the AI pitch they have been receiving does not match the deployment experience they have had or heard about. The pitch promises transformation at scale. The deployment produces a tool that requires more configuration than expected, produces more errors than the demo suggested, and requires ongoing management that the organisation did not budget for. The trust problem is a calibration problem: the vendor's language about AI does not map to the product's actual behaviour in the customer's environment.

The trust problem is not scepticism of technology. It is the gap between the pitch and the deployment, experienced at scale across the category.

The co-worker line is designed for a different first conversation. Not "this AI will transform your operations," but "here is the specific operational problem, here is what the co-worker does to address it, here is what it does not do, here is what the review process looks like." That conversation produces a different kind of engagement than the transformation pitch. It also produces a different kind of customer: one who knows what they are getting, which is a more durable relationship than one who was sold something they did not fully understand.

The sectors and what they need

The sectors the studio has built for are the sectors where the gap between the keynote and the mid-market reality is sharpest.

In construction and civil infrastructure, the operational problems are scheduling, safety documentation, compliance tracking, and the management of information across distributed project teams. A construction company with 150 people across five active sites has information management problems that AI can help with, but has no capacity to implement an enterprise document management platform with an AI layer. What it needs is a co-worker that can handle specific documentation tasks, assist with safety compliance checking, and produce reports that the project manager can review without specialised software training.

In health and aged care, the operational problems are clinical documentation, care coordination, and the administrative load that takes clinical staff away from direct care. A residential aged care facility with 80 residents and 60 staff has real AI use cases, but cannot deploy the clinical AI platforms that appear in hospital case studies. It needs tools that fit its scale, its regulatory environment, and its staff's technical comfort level.

In mining and industrial services, the operational problems are equipment monitoring, maintenance planning, and the management of safety-critical information in environments where documentation errors have serious consequences. A mid-sized mining services company does not have a sensor data team. It has operational engineers who need better tools for specific tasks.

The co-workers built for these sectors are sector-specialist: they hold the brief for their domain, they understand the regulatory and operational context of the industry, and they can engage at the level of specific tasks without requiring the mid-market business to invest in the infrastructure an enterprise deployment would require.

In mining and resources, Marcus handles procurement and inventory analysis. Priya handles HSE systems coordination. Mia handles mine production data analysis. Blake handles fleet operations analysis. Each has been configured for the vocabulary, the regulatory environment, the data systems (SAP S/4HANA, TechnologyOne, Power BI, FleetWave), and the operational decision rhythms of the mining sector. A co-worker connected to a SAP S/4HANA instance can produce a materials procurement report that accounts for current lead times, flag anomalies in inventory levels against forecast consumption, and surface the purchase orders that are at risk of delay before the delay becomes visible to the operations team. That is not AI in general. That is a specific specialist doing a specific job in a specific environment.

In health and aged care, Sophie handles clinical reporting analysis and connects to Civica Carefirst and RiskMan. Anika handles workforce planning analysis. In construction and civil, Jordan handles project controls coordination with Procore and Oracle Primavera P6. Leila handles contracts administration with DocuSign and Procore. Caden handles commercial finance analysis. Eli handles operations intelligence analysis. These are the roles the AU mid-market has struggled to fill consistently, because the combination of sector knowledge and analytical capability the roles require is not easily found at mid-market scale. The co-workers fill them by construction.

What the mid-market actually gets

The mid-market gets specialist capability it could not otherwise access at the scale it needs.

A construction company with 200 employees cannot hire a full-time safety documentation specialist, a full-time scheduling analyst, and a full-time compliance coordinator. It can engage AI co-workers that hold those specialisms, work on the specific tasks that come up, and produce output that a manager reviews and signs off. The cost structure is different from the enterprise AI deployment. The capability the business can access is genuinely specialist.

The mid-market also gets clarity about what it is getting. The co-worker holds a specific brief. The brief is legible: this is the domain, this is what the co-worker does, this is what it does not do. The mid-market buyer knows what they are engaging, which is a significant improvement over the "general-purpose AI platform that can do anything" pitch that has left a lot of mid-market buyers sceptical.

Sector-specialist AI built for mid-market scale is not a premium feature. It is the product that actually fits the context.

The mid-market also gets the on-premises commitment: the client's data stays in the client's environment. The co-worker is not a third-party service receiving a stream of operational data. It is a specialist running on the client's infrastructure, with the same data governance the client applies to everything else.

The combination of operational specificity, on-premises data handling, sector-relevant domain construction, and a review structure that matches how the mid-market already engages specialist capability is the product form the mid-market has not had access to. Until now, the choice was between enterprise platforms that required enterprise infrastructure and general-purpose tools that required in-house expertise to configure and maintain. The co-worker line is a third option: sector-specialist, operationally grounded, built for the scale and context of the organisations that have been left out of the AI deployment conversation. The keynote case study is not the target. The under-served mid-market business solving a real operational problem in a sector the AI conference has not featured is the target. Building for that customer, from inside the markets where those customers actually operate, without the data infrastructure requirements of the enterprise product and without the general-purpose limitations of the assistant-class tool, is what the co-worker line is designed to do.

The on-premises commitment

The mid-market's relationship with its data is different from the enterprise's relationship with its data, in a way that matters for how AI products need to be designed and delivered.

An enterprise organisation has a data governance function, a cloud infrastructure team, and legal and compliance capacity for managing third-party data sharing agreements. It can negotiate data processing agreements with AI vendors, maintain visibility over what data is being sent where, and enforce compliance with internal data policies at the tool level.

A mid-market organisation in mining, construction, or aged care has none of this. It has operational data that is sensitive: health records, safety documentation, project financials, maintenance histories. It has regulatory obligations around that data. It does not have the infrastructure to manage complex third-party data sharing relationships with AI vendors.

The co-worker line addresses this with a simple commitment: the client's data does not leave the client's building. The co-worker runs on the client's data, in the client's environment, behind the client's firewall. The integration connects to the client's systems. The output stays within the client's operational context.

This is not a feature that needs to be sold. It is the minimum viable trust architecture for the mid-market. An AI product that requires the mid-market client to send operational data to a third-party vendor for processing is asking the client to accept a risk that the client does not have the infrastructure to manage. The on-premises commitment removes that ask.

The practical consequence is that the co-worker deployment is not a SaaS subscription that routes data through a vendor's infrastructure. It is a deployment within the client's existing environment, with the same data governance that the client applies to its other operational tools. The client does not need to trust the vendor with the data. The client needs to trust the vendor's ability to build and configure the co-worker correctly, which is a different and more manageable form of trust.

What the co-worker is not

The co-worker is not a general-purpose AI assistant repackaged for a specific sector.

A general-purpose AI assistant given a prompt about mining project controls produces a response that is technically informed but not operationally grounded. It does not know that this site is in the Pilbara. It does not know that the regulatory context for this project is Western Australian mining legislation. It does not know that the naming conventions in this organisation's project documentation differ from the conventions the general model was trained on. It produces a plausible response to a general prompt, not a specific response to a specific operational situation.

The sector-specific co-worker was built for the Pilbara context, the Western Australian regulatory environment, and the naming conventions of the specific organisation's documents. That is what construction means in this context: not configuring a general model to answer mining questions, but building a model of the mining domain that includes the specific operational and regulatory context the co-worker will work in.

This distinction is the reason the deployment includes the domain construction stage described above. The domain construction is where the co-worker goes from general model to sector-specific co-worker. Without it, the product is a general-purpose assistant with a mining-focused system prompt. With it, the product is a specialist who knows the room.

The mid-market buyer who has been disappointed by general-purpose AI tools repurposed for their sector is not wrong to be sceptical of the next AI product that claims to be different. The correct response to that scepticism is to describe the domain construction process and what it produces, specifically, for their sector. Not to claim the product is fundamentally different without explaining how, which is what the keynote version of the pitch does.