vCAC was actually preparing me for this

I was deep in a context-engineering session last week, sketching out how a planner agent should hand work to a set of specialist agents, where the policy checks should live, what the retry semantics needed to look like, and somewhere around the fourth box on the whiteboard I stopped and laughed out loud. Because I had drawn this diagram before. About fifteen years ago. In a different conference room, with different acronyms, for a product that most people under thirty have never heard of.

vCAC. vCloud Automation Center. Later renamed vRealize Automation, and known to a generation of infrastructure engineers as the thing you used when you wanted to give developers a self-service portal to spin up VMs without filing a ticket and waiting four days.

I spent a chunk of my career on and around that product, building blueprints, wiring up vRealize Orchestrator workflows behind those blueprints, arguing with people about where approvals should live, debugging the seam between the catalog and the underlying provisioning engines. At the time it felt like deeply unsexy plumbing. The cool people were doing public cloud; the cooler people were doing Kubernetes; I was over here trying to get a templated workflow to not deadlock on its own approval step.

And the thing I keep realizing, with more and more force, is that vCAC was preparing me for exactly what I do now.

What vCAC actually was

For anyone who missed that era: vCAC was an orchestration and self-service platform. You'd model "things a user can request" as catalog items, a VM of a certain shape, a multi-tier app, a database, whatever. Behind each catalog item was a blueprint that defined what to provision. Behind the blueprint was a workflow engine (vRO, vRealize Orchestrator) that actually went and did the work: call vCenter, call the network layer, call the storage layer, run some custom scripts, register the result in the CMDB, send an email.

Around all of that there was a policy layer. Approvals. Quotas. Entitlements, who's allowed to request what. Cost models. Lease lengths, with automatic reclamation when leases expired. RBAC. Tenancy boundaries so finance's stuff didn't show up next to engineering's stuff.

And underneath it all was an integration foundation, a way to write reusable workflow components that called other workflows, that called external systems, that could be composed and recomposed into new catalog items without rewriting the underlying pieces every time.

You can already see where I'm going with this.

The diagram I drew last week

Here's what I was sketching out for the AI agent system:

A planner that takes a user request and decomposes it into a sequence of steps. A library of specialist agents, each one good at a specific thing, with a defined input contract and a defined output contract. A policy layer that decides whether a given user is allowed to invoke a given agent on a given resource. An approvals path for the consequential actions. A retry-and-fallback story for when an agent fails partway through. A logging layer that captures every step so you can reconstruct what happened. A budget (in tokens, in API calls, in dollars) with reclamation when the budget is exceeded.

I started drawing the boxes and the arrows and at some point I realized I was redrawing the vCAC architecture diagram. Different nouns. Same shapes.

What carries over, and what doesn't

The carry-over is real and it goes deeper than the picture.

Workflows that call workflows. The single most important pattern in vRO was that a workflow was just a callable unit with typed inputs and typed outputs, and you composed bigger workflows out of smaller ones. Agents are workflows that call workflows. The composition pattern is identical. What changed is that the inner steps can now be probabilistic instead of deterministic, but the wrapping discipline is the same, and the discipline is the part that's load-bearing.

Idempotency. In vCAC, if a workflow failed halfway through provisioning a VM, you needed to know what got created and what didn't, so you could either resume or roll back. We argued about idempotency constantly. We wrote workflows that assumed they might be re-run and had to converge on the right state regardless. Every single one of those arguments applies to agents. An agent that does the right thing the first time but the wrong thing on retry is broken. The vCAC people knew this. The agent people are learning it.

Policy at the orchestration layer, not in the worker. The thing vCAC got right (and it took the industry a while to internalize) was that the rules about what can happen and who can authorize what should live in the orchestrator, not inside each individual workflow step. Move it down into the worker and you end up enforcing the same policy fifteen different ways, badly. The same applies to agents. The guardrails belong at the orchestration layer. The specialist agents should be able to assume the call is authorized by the time it reaches them.

Approvals as a first-class step. vCAC treated "wait for a human to approve this" as a real workflow construct, not as an afterthought. It had state for it. It had timeouts. It had escalation. The mature agent systems I've seen all end up rebuilding this, and the ones that don't, regret it. Human-in-the-loop is not a feature you bolt on at the end; it's a primitive.

The catalog metaphor. The thing the user requests is not the underlying workflow; it's a curated catalog item that the platform team has vouched for. That's the same shape as a well-designed agent surface. Users don't talk to raw model APIs; they talk to a curated set of capabilities that the platform team has wrapped, policy-checked, tested, and put their name on.

What doesn't carry over is the determinism. vRO workflows were deterministic, same input, same output, modulo the state of the underlying systems. Agents aren't. The probabilistic layer at the bottom of the stack is genuinely new, and a lot of the disciplines I'm bringing over from vCAC have to be adapted to that. Retries are different when the retry might produce a different answer. Idempotency is harder when the worker is creative. Logging matters more, not less, when the underlying step doesn't always do the same thing twice.

Why the apprenticeship matters now

I've written before about what cloud automation taught me about agents and about the framework for thinking about an AI workforce. This piece is the autobiographical version of that same observation: the patterns I'm using to think about agent systems weren't invented for agents. They were invented for the prior generation of orchestration problems, and a lot of us spent ten or fifteen years sharpening them on workflows that look, in retrospect, like rehearsal for this.

The reason it matters is that the AI agent discourse keeps treating the orchestration question as if it's brand new. It's not. The shape of the problem, how to compose units of work safely, where policy lives, how to handle partial failure, how to keep a human-in-the-loop on the consequential decisions, how to log enough that you can debug something that touched seven systems, these are problems with twenty years of accumulated practice behind them. The infrastructure-automation generation already paid the tuition for a lot of the lessons the agent generation is currently re-learning at full price.

I'm not saying vCAC was secretly an AI platform. It wasn't. The underlying execution layer is genuinely different, and the differences matter. But the wrapping, the orchestration discipline, the policy layer, the catalog metaphor, the approvals, the audit trail, the reclamation, that part transfers cleanly. And the engineers who internalized that discipline in the 2010s are well positioned to apply it now.

What I tell the younger engineers

When I'm talking to people who came up after the cloud-automation era, who started their careers in Kubernetes-and-Terraform world and never touched a vCO workflow. I try to communicate that the orchestration discipline is the actual skill. Not the specific tool. Not the specific syntax. The discipline.

The discipline is: think in composable units with clear contracts. Put the policy in the orchestrator. Treat approvals as workflow state. Assume things will fail partway through and design for resumption. Log everything. Make the catalog the user-facing surface and keep the underlying primitives clean and reusable. Be paranoid about idempotency. Reclaim resources you've stopped needing. Hold the platform team accountable for the surface the user sees.

That list reads like an agent-systems checklist now. It read like a cloud-automation checklist in 2014. It probably read like a mainframe-job-scheduling checklist before I was born. The shape is older than any of the systems built on top of it.

Looking back

There's a particular pleasure in realizing that the boring work you did a decade ago is the foundation for the work that feels current now. I spent years on a product that doesn't even exist under that name anymore. The systems I worked on have been replaced two or three times over. The blueprints have been migrated, rewritten, lifted-and-shifted, retired. If you measured my vCAC-era output by what's still running in production today, the number is close to zero.

But the patterns are still running. They're running in my head, every time I sketch an agent diagram. They're running through the conversations I see in the community, every time the argument flares up about where the policy layer should live. They're running in the way I instinctively reach for "what's the catalog surface" before I reach for "what's the underlying API."

vCAC was preparing me for this. I didn't know it at the time, and the version of me sitting in those 2012 design reviews would have found it absurd to be told that the discipline he was learning would, fifteen years later, be the thing he reached for to think about machines that talk back. But the apprenticeship was real, and I'm grateful for it. The boring plumbing turned out to be the curriculum.