I have been building agents that can do things in my lab: inspect workloads, call APIs, and carry out infrastructure tasks. Once an agent can change a system, the question gets bigger than which model gives the best answer. Where does it run? Where does the data go? What does a completed task cost? And who decides what it is allowed to do?
That is the connection I wanted to make after VMware Explore 2026. VMware AI Factory and models as a service address how an organization provides AI capacity. AgentMinder addresses the authority of agents consuming services and invoking tools. vDefend and Avi address the network and application paths around those workloads. Tanzu adds the application-platform side of building and operating agents.
My AgentMinder lab is one part of that story. It is not a complete VMware AI Factory deployment. But watching a useful operation succeed and a destructive request get denied made the broader architecture much easier to explain.
Start with the workload: a model answers, an agent acts
A model is the engine that generates a response from its input. Running an already-trained model to answer a request is inference. You can host an appropriate model on your infrastructure without training a frontier model from scratch. Those are very different infrastructure projects.
An agent is an application around that engine. It supplies instructions and context, asks the model what to do, invokes permitted tools, and may repeat the process until a task is complete. A tool can read a document, query an API, or restart a service. MCP provides a standard way for an application to discover and invoke exposed tools; using that interface does not by itself decide who should be allowed to use them.
Take an incident assistant. It might read an alert, retrieve a runbook, check application health, ask the model to interpret the evidence, and request a restart. That single user request can generate multiple model calls and multiple interactions with enterprise systems. Serving the model is one job. Controlling the restart is another.
What VMware AI Factory means—and what “token factory” means
The official name is VMware AI Factory. Broadcom describes it as the software-defined foundation of VMware Private AI Cloud, using VCF to simplify the path from infrastructure provisioning to model inference and ongoing operations. The announcement includes shared GPU resources, model management, and infrastructure automation. MetalSoft integration and the AMD collaboration are part of the announced direction; a specific deployment still needs a supported hardware and software configuration.
Source: VMware AI Factory announcement.
Calling it a token factory can help describe the economics, but it is not the product name. Tokens are units a model processes and generates—pieces of text or other model-specific representations. An inference service turns compute, memory, power, and software into useful responses. The factory idea asks whether that service can deliver enough useful output, at the right quality and latency, for the resources it consumes.
Models as a service: give teams an endpoint, not another GPU project
Models as a service means the platform team runs approved models and exposes them through an API. Applications consume an endpoint with appropriate credentials. They do not each need to own a separate server, a separate model installation, and a separate maintenance process. This is a service-delivery pattern; it does not mean that every tenant gets unrestricted access or that the model is necessarily hosted by an external provider.
VCF 9.1.1 made multi-tenant model sharing generally available. Broadcom describes a shared Model Runtime serving teams in separate namespaces, reducing the need for redundant model deployments. The September 3 release blog explicitly separates that delivered capability from future AI Gateway features, the Secure Agent Framework, and model autoscaling.
Source: Delivered and future VCF Private AI Services capabilities.
The consumption model is concrete: the Private AI Services API documents authenticated requests for model discovery, embeddings, and chat completions through an OpenAI-compatible interface. API compatibility can make an application easier to connect, but does not guarantee that switching models preserves its quality, tool behavior, or performance. Those still need evaluation.
Source: Private AI Services API.
Why bring these workloads on premises?
The strongest reason is often the relationship between the workload and its data. An assistant working with internal engineering documents or operational systems may benefit from inference near those resources, with access rules and operating procedures the organization controls. An on-premises model endpoint can be one component of that design.
But location has to be traced across the whole request. A local agent that sends its prompt to a hosted model is still using external inference. A local model that calls a public search service or exports telemetry creates other data paths. “Private” needs to be demonstrated through the actual model, retrieval, tools, logging, backups, and network configuration—not inferred from where the agent’s container runs.
My own build illustrates the distinction. AgentMinder and the demo tools run in the lab, while the agent runner calls a hosted NVIDIA model endpoint. It demonstrates local control of tool actions with external inference. Moving that model call to a suitable internal service would be a further integration and evaluation, not a change I have already completed.
There is also no requirement to move every AI workload back on premises. Some tasks may justify a hosted model for capability or variable demand. Others may fit local inference because of data control, utilization, or operating requirements. The platform should make those choices deliberate. Broadcom’s published model-strategy discussion likewise describes a hybrid approach across local and cloud models.
Source: Broadcom’s flexible AI model strategy.
Token economics: measure useful work, not just output volume
On-premises inference changes the cost structure; it does not remove cost. A service still consumes hardware capacity, power, storage, networking, licenses where applicable, and operator time. Paying for idle capacity can erase an apparent advantage over a metered API. Higher utilization can improve the comparison, but only if quality and response times stay acceptable.
For an agent, I would measure the cost of completing the task successfully. Repeated reasoning, large context, retries, failed tool calls, and human correction all count. A model that produces cheaper tokens but needs several attempts may be the more expensive option for the workflow.
Cost per successful task = total attributable operating cost ÷ tasks that meet the agreed quality and completion criteria.
For a private deployment, include allocated infrastructure and operating costs. For a hosted service, include model charges and the surrounding application costs. Use the same workload and evaluation criteria for both.
Model sharing is relevant because it can reduce duplicate deployments and improve use of scarce capacity. It is not an automatic savings percentage. I would compare input and output volume, time to first response, completion latency, concurrency, success rate, and monthly demand. Then I would test whether the smaller or more specialized model can meet the same task requirements.
Where Tanzu and AgentMinder meet
In a platform design, Tanzu can provide the place to build, deploy, and operate applications and agents, along with their service connections. AgentMinder supplies agent identity and runtime authorization for governed actions. The two responsibilities are complementary: supplying a connection does not remove the need to check whether a particular agent may perform a particular operation.
Explore’s new Tanzu agent and AI-ready data capabilities were announced with a target of general availability in fall 2026. They include sandboxes, prepared enterprise data, and an agent development environment. That is product direction to evaluate against the eventual release, not evidence that I deployed those new capabilities as part of my AgentMinder demonstration.
Source: Tanzu’s Explore announcement and availability target.
AgentMinder itself was announced as generally available on August 31. Its launch describes mission-bound agent identities, authorization of tool calls at a cloud-native gateway, and OpenTelemetry-based observability. That is the part of the wider story I explored directly.
Source: AgentMinder launch.
What I actually put together
The build started with Kubernetes on a vSphere-based homelab using RKE2. I also prepared a VKS deployment guide, but that guide is a deployment adaptation—not evidence that this particular demo ran on VKS. Keeping those two things separate makes the setup easier to understand and reproduce.
AgentMinder’s services live in a dedicated namespace. The environment includes the authorization server, AI gateway, OPA policy engine, administrative console, and Observe services. A custom Python runner supplies the agent loop and calls a hosted NVIDIA model endpoint. The governance components are local; this build is not a claim that inference stayed entirely inside the lab.
A detail that turned out to be useful: the tool names and their intent tags form a contract. My real-tool adapters retained that contract while replacing mock responses with calls to application backends. The project includes adapters for Gitea, PostgreSQL, Chatwoot, and InvenTree. Those are additional lab scenarios, not a claim that every connector is production-qualified or healthy at the same time.
The demonstration: read, restart, then stop
The infrastructure agent’s mission permits reading workload information and restarting a service. Deletion sits outside that mission. The documented walkthrough uses three requests in sequence: list the workloads, restart payments-api, then try to delete redis-cache.
The walkthrough records the restart succeeding and the delete request being rejected at the gateway. It then checks that redis-cache still exists and shows the decision in Agentic Activity. During the read-only check for this article, payments-api, redis-cache, and web-frontend all had ready replicas. That confirms the workloads are present now; it is not a fresh execution of the earlier test.
This is the behavior I wanted to showcase: the same agent can remain useful while a more destructive operation is unavailable to it. The model does not have to voluntarily refuse the request for the boundary to work. The authorization decision is made on the governed path before the backend operation proceeds.
Identity, intent, and evidence each do a different job
Identity tells the system which agent is making a request. In this build, the infrastructure agent uses an autonomous identity and an OAuth client-credentials flow. That gives the policy system a specific caller to evaluate instead of attributing unrelated agents’ activity to one shared identity.
Intent connects a tool to the kind of action it represents. The infrastructure adapter distinguishes read, restart, destroy, and security-modification operations. A mission defines the permitted scope, while authorization policy determines whether the requested action is allowed. A tool being discoverable is not the same thing as the agent being permitted to execute it.
Auditability closes the loop. A console screenshot is more useful when it can be tied to an agent, an action, and a decision. The deployment work included the telemetry and event-storage components needed by Observe. Getting the gateway working without checking that the decision appears afterward would leave half the demonstration unfinished.
Where vDefend fits: constrain the paths around the gateway
A successful gateway denial immediately raises a harder question: could the agent reach the same backend another way? If its runtime has a direct network route, another credential, or an unrestricted shell, a protected MCP endpoint may cover only one of several paths.
That is the architectural reason to bring lateral security into the discussion. In a VCF design, I would use vDefend to constrain communication between the agent runtime, approved gateways, tool services, and sensitive workloads. The objective is to make the approved route meaningful and limit movement if an agent host or adjacent service is compromised. This is a proposed design for extending the lab, not a firewall policy I am claiming to have validated here.
The Explore announcement describes planned vDefend enhancements for discovering agentic components, detecting shadow AI usage, and producing AI-generated IDPS signatures for distributed virtual patching. Those capabilities address visibility and workload threats around the agent environment; they do not replace the need to define which business actions an agent is authorized to take.
Source: Broadcom’s Explore security announcement. The new vDefend capabilities are described in future tense.
Where Avi fits: protect and deliver the application path
The application endpoint needs its own controls. A request may come from a recognized agent and target an allowed service while still carrying a malicious payload, abusing an API, or causing operational trouble. Authorization and application protection answer different questions.
Avi belongs in this part of the design: delivering the application or gateway endpoint and applying web and API protection where configured. Broadcom’s August release announcement introduced native API protection alongside WAF and identified Avi 32.1.4 among the delivered releases. The same announcement covered vDefend SSP 5.2 and vDefend 9.1.1, including on-premises malware prevention, air-gapped support, and operational improvements.
Source: Broadcom’s August 6 release announcement. These release-specific updates precede the Explore roadmap announcements.
At Explore, Broadcom described further Avi enhancements for restricting unauthorized MCP-tool access, detecting anomalous agentic traffic, and protecting sensitive data. The accompanying technical announcement explicitly frames this as product direction. I would evaluate those features when supported releases and deployment requirements are available, rather than treating a roadmap diagram as a completed security control.
Source: Agentic Zero Trust and Threat Defense announcement.
Putting Avi in front of an endpoint does not automatically apply protection to every tool call. Traffic placement, TLS handling, policies, protocol support, and alternate routes all affect coverage. The integration needs a testable request path, with clear ownership of each decision.
What is available, and what still needs delivery or validation?
| Piece | Position as of September 10, 2026 |
|---|---|
| AgentMinder | Generally available at Explore. My lab demonstrates a configured governance path. |
| Multi-tenant model sharing | Generally available with VCF 9.1.1. |
| VCF AI Gateway enhancements, Secure Agent Framework, model autoscaling | Listed as future capabilities in the September 3 Private AI Services release blog. |
| New Tanzu agent and data foundations | Targeting general availability in fall 2026. |
| New agent-specific vDefend and Avi protections | Announced product direction; confirm delivery in the applicable supported release. |
There are two similarly named gateways to keep straight. The VCF AI Gateway roadmap concerns model consumption, including routing, token limits, and application authorization. AgentMinder’s AI gateway in this article governs the agent’s tool actions. A model-access policy and permission to restart an application answer different questions.
My next step would be to connect a suitable internal model endpoint, measure the same workflow, and test the controls surrounding it. I would verify the direct backend path is blocked, revoke an agent’s authority during a session, test unavailable policy services, and correlate the identity, application, and network evidence. A successful deny on one route is valuable; the broader architecture needs evidence that the route cannot simply be bypassed.
Why this belongs in the VMware AI conversation
The opportunity is to turn AI into an operated enterprise service. Infrastructure teams provide capacity and lifecycle management. Shared model services give applications a supported way to consume inference. The application platform runs the agents. Identity and security controls define their authority and protect the systems they reach.
That is the connection between AI Factory and AgentMinder that matters to me. Bringing models closer to enterprise data is the beginning. Making the resulting workloads useful, affordable, and controllable is the operating job that follows.
Build and source notes. This is a personal lab retrospective supported by the implementation and documented walkthrough. AgentMinder services and demo workloads were inspected on September 10, 2026; the destructive sequence was not rerun for this article. Inference in this build uses a hosted endpoint. vDefend, Avi, shared VCF model services, and Tanzu are discussed as the wider architecture, not as a completed integration in this lab. For the broader announcements, see my Explore field guide.