AI Is the New Electricity, and the Application Layer Is Where It Pays Off

JD Trask opens his keynote with a big claim: AI is going to be bigger than electricity. He’s using it to set the scale. Electricity sat in a wire until someone put it to work in factories, homes, hospitals and machines built for a specific job. Trask puts AI in the same spot today. The models are the current running through the wall. Nobody gets paid for the current itself. The returns come from what gets plugged into it, and from the work that plugged-in thing then does.

The model providers get the headlines. The application layer gets the spending.

Most of the attention lands on a handful of frontier model providers. New releases make the news, benchmark scores get argued over, and the conversation about AI mostly stays at that layer. Trask argues that focus hides where the real commercial opportunity sits for everyone else. According to Menlo Ventures’ 2025 State of Generative AI in the Enterprise report, US$19 billion of 2025 enterprise generative AI spending went to the application layer.

The models still matter, obviously. But training one from scratch isn’t realistic for most businesses, and it was never the goal for most businesses either. Models are turning into shared infrastructure, much like the grid: something everyone draws on rather than something most people build. That shift changes where the competitive edge sits. It moves away from who has the biggest model and towards who has built the most useful thing with an available one.

What the application layer actually is

The application layer is the software, workflows, products and services that put a model to work on a real problem. It’s the gap between a general chat tool and a system that knows how a vineyard schedules picking, how a clinic handles referrals, or how a freight company chases down a late delivery.

A frontier model can write competent text about almost anything you ask it. What it doesn’t know is your customers, your pricing rules, your compliance obligations, or the messy exceptions your team deals with every single week. Ask it to draft a reply to an unhappy customer and it will produce something plausible. Ask it to draft a reply that matches your refund policy, your brand’s tone and the specific history you have with that customer, and it comes up short unless someone gives it that context first.

The application layer supplies that context. It wraps the model in knowledge, data, an interface and guardrails that turn raw capability into something a business can actually rely on day to day, not just something impressive in a demo.

What that looks like in practice

• Hospitality reputation management, where a venue keeps on top of reviews and drafts considered replies in its own voice.
• Farming operations, where an operator plans work around weather, stock and paddock conditions.
• Support triage, where incoming tickets get sorted, summarised and routed before a person picks them up.
• Sales research, where a rep gets an account briefing instead of building one by hand.
• Internal reporting, where scattered numbers get pulled into a draft a manager can edit.
• Compliance preparation, where a team assembles evidence and drafts responses ahead of an audit.
• Product engineering support, where a developer gets help against a specific codebase instead of generic snippets.

None of these need a smarter model than the ones already available. They need someone who understands the workflow well enough to wire the model into it properly, and who’s willing to do the unglamorous work of getting the data, the rules and the exceptions right.

Why good application companies are hard to copy

Defensibility comes from what a competitor can’t just download. The model itself is available to anyone with a credit card, which means it can’t be the moat. The moat is everything built around it: domain knowledge earned over years, customer relationships, workflow data that only accumulates through real use, an interface shaped around one job rather than every job, existing-system integrations that plug into what customers already use, and human review for the decisions that actually matter.

A competitor can copy your prompt in an afternoon. They can’t copy five years of knowing exactly how your customers work, or the specific data you’ve collected from solving the same problem for hundreds of them. That’s the part worth building.

The New Zealand angle

New Zealand is well placed to build locally informed products that travel. The 2025 TIN Report on New Zealand’s tech export earnings records NZ$15.31 billion in technology export revenue for FY2025. That figure covers the tech sector broadly, not AI specifically, but it shows the country already knows how to build software that sells beyond its own borders.

The industries New Zealand knows deeply are worth building for: agriculture, tourism, professional services, SaaS and export businesses. Stats NZ’s tourism satellite account for the year to March 2025 reports international visitor expenditure of NZ$18.1 billion. That’s a large base of real operators running real workflows, not a headline number sitting in a report.

Reuters’ report on Halter reaching unicorn status covers Halter, an Auckland-founded company building solar-powered virtual fencing collars for cattle, raising US$100 million. It’s a useful example of the same principle at work outside AI specifically: a product built around one industry’s genuine, specific needs, then taken to the rest of the world.

Infrastructure and sovereignty are a national question

Trask’s view is that where compute lives is a strategic question worth taking seriously. That’s his opinion, and it’s a policy question for government and infrastructure investors to work through, not something every individual business needs to solve on its own before it can get started.

NZTech’s report on New Zealand’s data centre investment projects more than NZ$10 billion in private-sector data centre investment over the coming decade, and notes New Zealand’s electricity grid is largely renewable. These are projections, not results already delivered.

Trask leans towards keeping meaningful compute and capability onshore where possible. Reasonable people can disagree on how far to take that, and it’s a longer conversation than one keynote can settle. Either way, the practical point for most businesses stands regardless of how that debate plays out: you can build valuable products today on models that already exist, wherever those models happen to run.

What to build next

Start with the workflows that are high-volume, high-cost, slow or just a poor experience for the people stuck doing them. These are usually easy to spot inside a business because someone complains about them regularly, or because they eat hours a week that could go somewhere more useful. Use an existing model where it fits the job rather than waiting for a better one. Then put the real effort into the context around it: domain knowledge, data, interface and checks that catch it when it gets something wrong.

The advantage comes from how well you solve the specific problem in front of you, not from owning the model underneath it.

A concrete example from the Autohive keynote demo

Trask’s hospitality demo was a keynote demonstration, not a customer case study. It showed an Autohive workflow that connects a Google Business Profile integration to list a venue’s reviews and reply to them. A system prompt and reference material guide the venue’s voice and its facts, so replies sound like the venue rather than a generic assistant. Human approval can pause a drafted reply before it goes out, which matters when the thing being published is public and permanent. The workflow itself can run on a schedule or be triggered manually, depending on how the business wants to work.

It’s a small example, but it’s the whole argument in miniature: a capable model, wrapped in the specific context of one business, doing one job well.

The takeaway

The models will keep getting better, and that trend line isn’t going anywhere. For most businesses, the opening sits elsewhere: in the application layer, applying a capable model to a job you understand better than anyone else does, in an industry you already know. Find the expensive workflow in your industry that generic AI tools still handle badly, then build for that gap. Our guide to building a custom agent is a good place to start.