Ask around any AI conference this year and the enthusiasm sits in exactly one place: the agent. What it can reason through, what tools it can call, how many steps it can chain together before it needs a human to step in. Almost nobody at the same conference wants to talk about what the agent actually runs on, and that gap is quietly where most AI projects go to die.

We spent a chunk of this month building exactly that unglamorous layer for a client, an Azure AI Foundry Landing Zone, and watching the scope shift under us in real time taught us more about where AI value actually lives than any agent demo has this year.

The part nobody puts in the deck

MIT's NANDA initiative found that 95% of enterprise generative AI pilots deliver no measurable financial return, and the researchers were explicit that this wasn't a model quality problem [1]. It was an integration and workflow problem, tools that were technically impressive and operationally homeless.

Australia isn't immune to the same pattern. SAP's Value of AI Report 2026 found 42% of Australian businesses admit they're deploying AI agents faster than they can standardise or govern them [2]. Deloitte's most recent Australian research found only 28% of organisations have actually moved 40% or more of their AI pilots into production [3]. Different surveys, same underlying story: the agent is rarely the thing that stalls. The ground it's meant to stand on usually is.

What we thought we were building

The brief started simply enough. One client, one production agent, a straightforward Azure AI Foundry Landing Zone: private endpoints, isolated data planes, identity through Entra ID rather than static API keys sitting in a config file [4]. Clean scope, clear deliverable, the kind of build that looks entirely finished on a slide before anyone's actually opened a subnet.

Where the ground shifted

Then the real context surfaced. This wasn't going to be one agent forever. Several AI initiatives were already in flight, and the client wanted the platform to support a second and third agent without anyone re-architecting it from scratch each time. That single requirement is the difference between a Foundry Landing Zone and a Foundry Landing Zone with an AI Gateway sitting in front of it, and it reshapes the entire build. It isn't a checkbox you tick on the way past.

Two gates, not one

Here's the mistake that nearly made it into a client deliverable. Agents feeding into a gateway, the gateway feeding into the AI platform, one clean line on a diagram. Except a user talking to an agent and an agent talking to a model are two completely different journeys, and they need two completely different front doors. A web application firewall protects the thing an actual person interacts with. A separate AI gateway, invisible to any user, sits further back and governs how agents call into shared models, throttling, authenticating, and logging every call. Collapse the two into one node on a diagram, as we very nearly did, and you've designed the wrong security boundary before a single line of infrastructure code gets written.

What it actually cost to get right

Once the Gateway was properly scoped in, alongside the firewall it genuinely needed, the effort estimate moved by roughly a quarter. Not because the work got harder in any technically difficult sense, but because governance touches everything once you add it properly. Every agent needs authentication. Every call needs logging. Every model deployment needs a policy decision made about it before it ships.

Gartner's own research says this is the norm, not the exception. Their forecasting puts it plainly: through 2028, at least half of generative AI projects will overrun their budgeted costs, and the cause isn't unpredictable technology; it's poor architectural choices made early, before anyone understood what production-grade governance actually requires [5]. We would rather find that number during scoping than have a client find it during a change request six months in.

The actual question worth asking

None of this means agents aren't worth building. It means the excitement and the actual risk live in two different places, and most organisations are currently budgeting for the first while quietly ignoring the second.

If you're planning your first production agent, the useful question isn't "which model." It's "who's designed the platform underneath it, and does that design account for agent two before agent two exists?, " For most organisations right now, the honest answer sits somewhere between "not sure" and "we'll figure it out later." Later is precisely when it gets expensive.

PerData works with Australian mid-market organisations to answer that question properly, before the first agent gets built, not after the second one shows up. That's exactly what an AI Landing Zone Assessment is for. Curious? Let's chat!

Sources

[1] MIT NANDA, The GenAI Divide: State of AI in Business 2025, July 2025 — https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf

[2] SAP, Australia's AI report card: "Improving… but could do better", 20 July 2026 — https://news.sap.com/australia/2026/07/20/australias-ai-report-card-improving-but-could-do-better/

[3] Deloitte Australia, The State of AI in the Enterprise, 2026 — https://www.deloitte.com/au/en/issues/generative-ai/state-of-ai-in-enterprise.html  

[4] Azure/AI-Landing-Zones reference architecture, Microsoft — https://github.com/Azure/AI-Landing-Zones

[5] Gartner, 2026 Gartner Hype Cycle for Generative AI — https://www.gartner.com/en/articles/hype-cycle-for-genai