I have two AI agent roles working around my VCF 9.1 lab. One handles architecture and the other handles implementation. I provide requirements and constraints, decide when changes can proceed, and step in when I want to understand or challenge a decision.

Both agents have their own context and responsibilities. The implementation agent also has access to tools for inspecting and changing the lab. When implementation raises a design question, the profiles can pass the question and the relevant environment data between them without me relaying it.

I wanted to see how that works in practice, so I gave them a simple VPC design and implementation task.

The two agent roles

The architect runs as a Hermes Agent profile called vcf-expert and turns requirements and constraints into a design and expected result. The implementation role runs as a separate sysadmin profile and works against the actual VCF environment.

There is no technical requirement for these to be separate agents. A single agent could switch between architect and implementation roles. I split them so that each role has its own context, responsibilities and tool access, and so that design and implementation meet through an explicit handoff instead of one agent continuing from its own previous reasoning. I am testing whether that separation is actually useful.

The profiles are not a fixed pipeline. Sysadmin can ask VCF Expert for clarification, and it can return findings from the running environment that challenge an assumption in the design. VCF Expert can then refine the design or explain which requirement should take priority. I can still step into either loop, but I do not have to relay every technical question between the two roles.

How the setup is wired

The diagram below shows the components around the agents and how they connect. It is the architecture of the setup itself, separate from the three-tier scenario used later in the article.

The setup is built around Hermes Agent. Hermes Agent Desktop runs on my laptop and is the control surface I use to interact with the profiles. The Hermes Agent backend runs separately on Debian 13 and coordinates the agents, models, memory and tools.

The language model provides the reasoning capability, but it has no direct path into the VCF environment. Hindsight provides persistent memory across sessions. Documentation is stored as version-controlled Markdown, with Obsidian as my desktop client and a local checkout available to the agents on the Hermes backend.

The VCF 9.1 lab is the external system the agents work against. Sysadmin reaches it through the tools and APIs I have exposed for inspection and authorized changes. VCF Expert works from requirements, context and the findings Sysadmin returns rather than having its own direct path into the environment.

Requirements first, topology later

For the worked example, I started with requirements and constraints rather than handing the architect a topology:

Design a VPC-based network architecture for a three-tier application in my VCF 9.1 lab.

- Internet-facing workloads must be separated from internal application services and backend data services.
- The external tier must reach the application tier, and the application tier must reach the data tier. Unnecessary east-west communication should be prevented.
- Shared services such as DNS and logging must remain reachable where required.

Do not implement anything yet. Focus on the architecture, connectivity intent, and any decisions that still need clarification.

The request deliberately does not prescribe the VPC topology. It does not say “create a DMZ VPC, an application VPC, a data VPC and a shared-services VPC.” I want the architect agent to derive the VPC structure, connectivity and firewall rules from the requirements rather than echo a topology I have already chosen.

VCF Expert did not choose one VPC per tier. It proposed one dedicated application VPC attached to the lab’s existing Transit Gateway, with three gateway-connected Private-VPC subnets for the web, application and data tiers. Tier separation would be enforced with workload-level firewall policy. Its reasoning was that separate VPCs would add routing, policy and address-management complexity without providing meaningful extra isolation in this lab; it would reserve separate VPCs for cases with different owners, different lifecycles or clearly different security requirements.

The implementation agent meets the real environment

The implementation agent operates much closer to reality. It can inspect the lab, see what is actually there, perform the work I have allowed and then check the result.

For the VPC scenario, that means inspecting what actually exists before making assumptions: current VPCs, transit-gateway and external-connectivity state, available connectivity policies, IP addressing, network spans, clusters, shared services and any other objects the proposed design depends on.

Some gaps are just implementation details. Others mean that the design is still incomplete. For example, the design may say that the external tier must be isolated from the data tier without identifying which firewall or policy should enforce it.

Sysadmin pulled the design directly from VCF Expert and inspected tenant-blue without changing anything. The project, Supervisor and Tier-0/Edge foundation were already there. The existing VPC, however, was in use by a Kubernetes workload and had only one subnet, so it was not a good fit for the three-tier application. Sysadmin therefore treated the architect’s “dedicated application VPC” as a new VPC inside tenant-blue. A few details around external connectivity, ingress and firewall capability still needed to be worked out.

When the agents talk to each other

Sysadmin passed its findings from tenant-blue directly to VCF Expert. VCF Expert then refined the design using the state Sysadmin had found in the lab. I did not need to relay the questions or the environment data between them.

Hermes does not expose that exchange as a clean chat transcript, but the result is visible in what came back from VCF Expert.

The updated design was now concrete: three conventional VMs, a new dedicated VPC inside tenant-blue, and a new 192.168.21.0/24 address space split into separate /27 subnets for the web, application and data tiers.

Agreement between the agents is not validation. I still review the design, but I no longer need to carry every technical question from one role to the other.

Based on what had been verified so far, VCF Expert did not need another design decision from me. The remaining decision was mine: whether Sysadmin should go ahead and build it.

I let Sysadmin proceed with the refined design in tenant-blue, with one important constraint: the existing Kubernetes VPC and subnet were off limits. If anything came up that changed the design or touched existing workloads, Sysadmin was to stop and come back to me. Within those boundaries, it could resolve the implementation details on its own.

When the design meets reality

Sysadmin could build the network part of the design: the new application VPC and its web, application and data subnets. But the implementation could not be completed as designed. My lab does not have an NSX vDefend license, so the intended workload-level firewall policy for enforcing tier separation could not be implemented. In retrospect, that is something Sysadmin should have established during the initial inspection. It had already identified firewall capability as an open question, but the licensing constraint was not resolved before implementation started.

• the new application VPC exists under tenant-blue;
• the separate web, application and data Private-VPC subnets were created as planned;
• the existing Kubernetes VPC and subnet were left untouched;
• the workload-level firewall policy could not be implemented because the lab lacks NSX vDefend licensing;
• that limitation needs to be reported back to VCF Expert rather than silently worked around.

Sysadmin should report the licensing constraint back to VCF Expert rather than inventing a substitute security model. VCF Expert can then decide whether to revise the lab design or leave the missing control as an explicit limitation.

What changed in the workflow

In the usual AI-assisted workflow, I ask a question, evaluate the answer and then carry the context, sequencing, execution and validation myself.

Here, the agents keep their own roles and context. They can inspect state, make decisions within their scope, hand questions to another profile and continue from the result.

In this test, Sysadmin discovered that the design could not be built as written in the current lab. That constraint now needs to go back into the design loop.

This is still a lab. It does not have customer SLAs, formal separation of duties, production change control or the security and audit requirements of a large enterprise. Doing the same thing in production would require much tighter controls around identity, permissions, credentials, approvals, audit, rollback and accountability.

Where the engineer fits

The human role changes as more of the design and implementation loop is delegated. I still set the goal, provide the context and tools, define the limits and decide when the agents can proceed.

That still requires deep infrastructure knowledge. Giving an agent permission to make real changes makes weak assumptions more dangerous. Someone has to judge whether the design makes sense, whether the agents have the right level of access and whether the validation actually proves what it is supposed to prove.

What I want to test next is how much of that loop can be delegated before I only need to step in for decisions that genuinely require human judgement.