TL;DR
Unleashing AI agents with raw administrative access creates severe risks of configuration drift, technical debt and even catastrophic incidents. Infrastructure vending solves this by replacing unreliable prompt-based approaches with an operational framework of codified rules, parameters, gates and pipelines that we can plug into agentic workflows.
Fast and Furious: Managing configuration drift in agents
Agents can read thousands of lines and write hundreds before their human has returned from ordering their Magic coffee. They are also equally fast at jumping to conclusions, rightly or wrongly. Giving the agent free rein in the wrong area is a recipe for a pretty nasty spill when back at our desks.
If you’re not concerned about giving your agents highly privileged powers to your software or cloud infrastructure, you should be. It’s not that they are bad at decision making or unreliable, far from it. It’s already the day where arguably they are better at both than we are.
But your agent is not you, it cannot reliably make the decisions that your enterprise needs and if it gets it wrong because of its speed and power the ceiling for disaster can make the evening news (just ask OpenAI about Medicare 🤦♂️).
It’s like a race car. Because of its speed and power, if you hop in and weave through traffic recklessly you can definitely get there faster on most days, but on the one day you get it wrong you might not get to your destination at all.
Catch-22 Slow or Steady: The Agentic IT Control Dilemma
The need for control creates a nasty operational catch-22 that traps IT engineering teams in a tight pincer movement.
On one side of the pincer, we slow or banish agentic processes down to steady the ship. We ensure that all AI work is human initiated and supervised and true agentic processes are highly restricted or only live in POC-land.
On the other side of the pincer, we sacrifice speed and progress. This approach is safe but has a low ceiling as we miss out on the capability of agents to become autonomous delegates of routine infrastructure work and DevOps.
Generally, organisations that take this approach rely on manual point in time prompting. Sure, they can augment this with elaborate prompt templates and steward them diligently, but that kind of misses the forest for the trees. LLMs are fundamentally non-deterministic systems. If you rely on humans to manually prompt an agent for every single environment, over sufficient time and iterations, the law of large numbers (which btw is the OG law of computer science 😁) dictates that you end up with variance across core areas that demand consistency like software architecture patterns, platform conventions, network topologies, pipeline templates etc.
What is infrastructure vending
So, you might rightly respond that all this setup is just so we slow ourselves down further by adding some glorified middleware that we market as “vending”, not buying it.
When you can ask for what you want using natural language, i.e. just write a prompt and ask for the changes that you require, and then review and amend accordingly, why do we need more middle layers? What is vending anyway?
To understand infrastructure vending, forget tech for a moment and think about the vending machines at the train station. Melburnians, picture the heaps of vending machines at Southern Cross. Non-Melburnians, come to Melbourne ☺️
A vending machine isn’t just a box with snacks and drinks (or MTG booster packs) in it. There are certain mechanics and rules that are non-negotiable.
- Security: Vending machines are unattended, so if the box is easily broken into then the whole idea is moot. Effective vending machines depend on the ability to secure the contents offered be it snacks or infrastructure.
- Prerequisites (“The Price”): The machine demands explicit inputs before it vends, such as your credit card details or some authorised code. In techie terms, the “price” is the organisation authorisation and technical prerequisites such as cost-center tags, managerial approvals, infrastructure details like non-overlapping network ranges.
- Service Offering (“The Menu”): A typical vending machine offers a finite menu of pre-approved, standardized products e.g. Row A1 Coke Zero, Row B4 Solo, Row C2 Bottled Water. Note also that people hit the vending machine for instant gratification and convenience. Everyone hates (and sometimes hits) the vending machine that malfunctions. For platform teams, this means a service offering of pre-governed blueprints that have immediate value to the business e.g. an isolated dev sandbox, an AI testing landing zone, Kubernetes namespace or selection of enterprise approved architectural patterns etc.
N.B. The vending machine menu is also an interface where the user can see and select their desired product. This is often a critical consideration in vending and potentially one of the places where gen AI can come in. - Deployment (“The Drop”): When you press B4 to get a refreshing can of Solo, the mechanical coil turns, and a can drops into the tray. It happens identically every single time. The machine never misinterprets your input, negotiates, or accidentally drops Coke Zero because it was feeling funky. In engineering terms, this drop mechanism is the way you deploy the selected offering. Generally this is some kind of CI/CD pipeline(s), consisting of Infrastructure-as-Code (IaC) pipeline and Policy-as-Code (PaC) evaluations.
Microsoft’s Cloud Adoption Framework defines vending as “a process that allows application and service teams to request and receive” their requirements, such as subscriptions, “with minimal friction”.
Why do agents need vending
Now, your initial reaction might be: “Wait a minute! Agents don’t need a self-service web portal with shiny buttons to click.”
And you’d be completely right. If infrastructure vending were merely a web form with dropdown menus for humans to choose from, building one for an autonomous agent would be an exercise in pointlessness.
The self-service portal is just the public facade, that’s what we might remember, but the real value of infrastructure vending is what sits behind the screen: the codified rules, blueprinted offerings, approval and policy gates, and deterministic deployment pipelines. The security, price, menu and drop that we talked about.
Vending is important to you in the age of AI because it helps provide your autonomous / semi-autonomous AI with an operational framework.
When you refactor infrastructure vending for agentic workflows, the agent stops being a dangerous administrative actor and becomes the orchestrator of your vending rules.
How you do so depends on the vending machine that you installed in your particular office, but also on your AI strategy and the level of autonomy that your risk appetite allows. Here are some examples from beginner to advanced, so to speak.
- The Agent Replaces the UI: This is the typical use case. Instead of a human clicking through a form, the agent parses messy natural language prompts (“I need a PCI-compliant sandbox for analytics project with vWAN peering in Australia East”) and translates that intent into the correct API calls into the vending layer.
- The “Menu” Becomes the Grounding Boundary: The pre-governed vending templates, your service offerings, architecture patterns, approved blueprints, serve as strict system prompts or context boundaries. You use soft measures such as skills, spec-driven AI or a fuller system such as RAG to ground your AI in the offering that can be provided back to the user as response. So when the user asks for their PCI sandbox, your agent can respond that it can offer a sandbox offering with public internet but it won’t be vWAN connected or vice versa.
- The “Drop” Mechanism Becomes an Agent Tool: A possibly higher risk approach sees autonomous agents replacing deterministic deployment pipelines where the approved and templated menu item is given to an agent to fulfil within the guidance of your enterprise agent harness e.g. via Model Context Protocol tool definitions and/or API wrappers for your pipelines. This can even be end-to-end where the UI chatbot supplies the required “price” (validated pre-reqs as parameters), invokes the deployment agent which has access to the tools and permissions to deploy.
The more autonomy we give to the agent, the more we return to higher risk. The good news, however, is that the groundwork you laid in designing vending guidelines serves as a rules-based safety boundary for the agent.
Agentic vending example in action
Here is a quick example based on a real customer VM vending repos.
In this example we have a Terraform repository that takes a JSON definition of a Windows VM, the frontend for the Vending is a GitHub Issue template form.
We can easily create a simple Copilot Studio agent to replace that form with a chatbot frontend as follows:
Because the agent has my Azure conventions and the rules and reference contract for my VM vending, it can push back and provide advice. See above where it requires the RG naming and provides the available SKUs. Once done, it can insert the file directly into my vending repos.
The agent then uses a GitHub MCP server call to insert the file directly into the repos in a feature branch for the engineer to review and PR or amend as needed.
Key Takeaway
Vending as rule formalisation: The primary value of infrastructure vending for AI agents is in the processes and pipelines that you design. Vending provides the codified rules, parameters, blueprints, and policy gates that when done well turns ambiguous natural language requests into safe, deterministic execution.
Conclusion
Autonomous agents give IT operations unprecedented speed, but raw speed without structured guardrails and enforced alignment to enterprise conventions is just a faster way to incur tech debt or worse trigger a P1. Going through the exercise of building infrastructure vending is well worthwhile because it provides you with assurance.
Reassurance that your operational framework, as opposed to hoping that prompts staying reliable in an ever changing org and LLM landscape, is what bridges the gap between non-deterministic AI reasoning and deterministic cloud and application APIs.
