How AI Agents Fit Inside a Virtual Delivery Center
There is a version of the AI future that sounds very clean.
A company has work to do. It deploys agents. The agents take care of research, coding, testing, analysis, customer support, reporting, maybe even parts of decision-making. Humans supervise where needed.
It sounds efficient.
It is also a little too neat.
Real work is not neatly divisible into “human work” and “AI work.” It is full of context, ambiguity, trust, judgment, exceptions, politics, urgency, emotion, history, and consequence.
That is why the interesting question is not whether AI agents can perform tasks.
They can.
The interesting question is where they belong inside the execution system.
A company can deploy hundreds of agents and still be badly organized. It can automate pieces of work and make the whole thing harder to govern. It can reduce human effort in one place and create more review, confusion, and risk somewhere else.
The future will not be won by the company with the most agents.
It will be won by the company that knows how to place humans and agents around an outcome in a way that actually works.
That is where the Virtual Delivery Center becomes interesting.
A VDC gives the enterprise a place to organize people, agents, systems, and external capability around one execution mandate. It is not a separate AI layer. It is the environment in which AI becomes part of real work.
That distinction matters.
An AI agent should not sit outside the operating model
A lot of companies are adopting AI the way they adopted SaaS.
Someone finds a useful tool.
A team starts using it.
Then another team discovers a different one.
Soon there are agents for research, sales, customer support, coding, analytics, documentation, and operations.
Everyone is experimenting.
Nobody is quite sure how the pieces fit together.
At first, this feels like innovation.
Later, it becomes architecture.
Who owns these agents?
Which business outcomes depend on them?
What can they access?
What happens if two agents produce conflicting recommendations?
What happens when an agent changes because the underlying model changes?
What happens when the employee who created it leaves?
The same problem happened with software sprawl.
But an unused software tool mostly wastes money.
An agent can act.
That makes the governance problem more serious.
An AI agent should not float around the enterprise as invisible automation. Once it participates in meaningful execution, it needs a place inside the operating model.
A VDC can provide that place.
Start with the outcome, not the agent
The worst way to introduce AI is to ask:
“What can we automate?”
That question almost guarantees a collection of disconnected use cases.
A better question is:
“What are we trying to make true, and where can machine capability help?”
This sounds like a subtle distinction, but it changes everything.
Suppose a company wants to reduce enterprise customer onboarding from eight weeks to three.
That is the outcome.
Inside that outcome are many different kinds of work.
There is discovery.
There is data mapping.
There is integration.
There is security review.
There is configuration.
There is testing.
There is training.
There is documentation.
There is customer communication.
There is exception handling.
There is final acceptance.
Now we can ask where agents fit.
An agent may summarize discovery calls.
Another may inspect data mappings.
Another may generate configuration documentation.
Another may run test cases.
Another may watch for missing customer inputs.
Another may draft weekly status updates.
None of these agents owns customer onboarding.
The customer onboarding VDC owns the mandate.
Humans and agents work inside it.
That is the difference between deploying agents and designing execution.
Humans should own outcomes. Agents should own bounded work.
This is one of the simplest principles we can use.
A human or institutional owner should remain responsible for the outcome.
The agent can own a clearly bounded task inside that outcome.
For example, imagine a customer implementation VDC.
The internal implementation leader owns whether the customer reaches production successfully.
A data agent may validate migration files.
A documentation agent may produce implementation guides.
A test agent may execute regression tests.
A support agent may classify incoming issues.
A human security specialist may review exceptions.
An external integration engineer may handle a difficult API dependency.
A customer success leader may manage the relationship.
The VDC brings these pieces together.
No single agent needs to understand the whole company.
No single external specialist needs permanent access.
No internal employee needs to perform every repetitive step manually.
The system works because the boundaries are clear.
This is closely related to the governance model described in VDC Governance: Borderless Execution Without Losing Control.
The point is not to make every participant equal.
The point is to make every participant visible.
Agents are capabilities, not employees
We should be careful with language.
It is tempting to talk about AI agents as “digital employees.”
Sometimes the phrase is useful.
But it can also confuse the operating model.
An agent does not have a career.
It does not build trust in the same way a person does.
It does not understand consequence in the human sense.
It does not carry institutional responsibility.
It does not feel embarrassment when it gets something wrong.
It does not sit across from an angry customer and absorb the emotional weight of a failure.
An agent is better understood as a productive capability.
Sometimes it is very powerful.
Sometimes it is narrow.
Sometimes it behaves more like software.
Sometimes it behaves more like an autonomous worker.
But it still needs a human institution around it.
That matters because the company should not design the agentic enterprise by copying HR structures too literally.
An agent does not need a manager in the emotional or developmental sense.
It needs an owner.
It needs an objective.
It needs permissions.
It needs a boundary.
It needs verification.
It needs someone who can turn it off.
Every agent needs a job, even if it does not need a job title
The easiest agents to govern are the ones whose purpose is obvious.
“This agent reviews pull requests for security issues.”
“This agent compares incoming invoices with purchase orders.”
“This agent monitors customer onboarding for missing dependencies.”
“This agent drafts implementation documentation from approved source material.”
The trouble begins when an agent’s purpose becomes vague.
“This is our operations AI.”
“This is our sales assistant.”
“This agent helps everyone.”
At that point, its access grows.
Its responsibilities blur.
Nobody knows exactly what it is allowed to do.
The VDC should define an agent’s role in practical terms.
What outcome does it support?
What can it see?
What can it change?
Which tools can it use?
What should it never do?
When should it stop and ask for help?
Who owns it?
How will its output be checked?
That is enough to turn an interesting experiment into a governable actor.
Some work should be machine-first
There are parts of execution where humans are simply not the best default anymore.
Repetitive checking is one.
Large-scale comparison is another.
Continuous monitoring is another.
An agent can watch thousands of records for anomalies without becoming tired.
It can compare current data with historical patterns.
It can generate the first draft of repetitive documentation.
It can test many scenarios.
It can scan logs continuously.
It can prepare structured summaries before a human meeting.
It can keep track of small dependencies people would otherwise forget.
These are not trivial improvements.
They remove a lot of invisible work.
The kind of work that consumes days without anyone feeling that real progress has happened.
This connects back to Time, the Timeless Oil.
The most useful agents may not be the ones replacing obvious jobs.
They may be the ones removing waiting, repetition, status chasing, context gathering, and coordination drag.
That is where a VDC can become dramatically faster without simply pushing humans harder.
Some work should remain human-first
There is also work where humans should remain at the center.
Customer conflict.
Ambiguous priorities.
Ethical trade-offs.
Leadership.
Negotiation.
Interpretation where context is incomplete.
Decisions where consequences are serious and hard to reverse.
Situations where trust matters as much as technical correctness.
A customer may not care that an AI-generated answer is technically accurate if it arrives at the wrong emotional moment.
An employee may not accept a major career decision simply because an algorithm reached a reasonable conclusion.
A regulator may want to know who actually exercised judgment.
The VDC should not push machine capability into these areas simply because it can.
Capability is not the same as authority.
Most interesting work will be shared work
The most common pattern will probably not be human-only or agent-only.
It will be collaboration.
A human defines the objective.
An agent researches.
The human reframes the problem.
An agent generates options.
The human chooses a direction.
Another agent builds.
A human reviews.
An automated test validates.
A specialist handles an exception.
The agent continues monitoring.
This is where traditional org charts become less useful.
The work moves across people and machines.
The execution graph becomes more important, as described in From Org Charts to Execution Graphs.
The VDC gives that graph a persistent home.
The actors can change.
The mandate remains.
One VDC may contain many kinds of agents
It helps to stop thinking of “AI agent” as one category.
Inside a VDC, agents may play very different roles.
Some are observers.
They watch systems, detect patterns, and alert people.
Some are researchers.
They gather information, compare sources, summarize, and prepare context.
Some are builders.
They write code, generate configurations, create documentation, or produce assets.
Some are coordinators.
They track dependencies, follow up on missing inputs, and route work.
Some are validators.
They test outputs against rules, policies, benchmarks, or expected states.
Some are operators.
They execute approved actions in live systems.
Some are assistants.
They help a human make a better decision without acting independently.
These distinctions matter.
A monitoring agent should not automatically receive the same authority as an operating agent.
A drafting agent should not automatically become a customer-facing agent.
The VDC should treat each one according to the consequence of its work.
The most powerful agents will probably be the least visible
People are naturally drawn to conversational agents because they are easy to see.
You ask.
They answer.
But the most valuable agents inside a VDC may operate quietly.
They may notice that a customer implementation has been waiting for an API key for three days.
They may detect that one module is about to miss a dependency.
They may identify that two teams are using different versions of the same policy.
They may notice that test coverage has fallen below an agreed threshold.
They may reconcile delivery evidence automatically.
They may warn that a specialist’s temporary access expires tomorrow.
They may see that a decision is stuck.
These agents are not trying to impress anyone.
They are keeping execution moving.
That is a much more interesting future than filling the company with chatbots.
Agents should reduce coordination overhead, not create another layer of it
There is a strange risk with AI.
We may automate the work and then create a new bureaucracy around supervising the automation.
People may spend their days reviewing AI output, managing agent settings, reading generated summaries, and resolving machine-created tasks.
We could end up with more activity than before.
The VDC should resist this.
An agent should exist because it removes friction or improves the outcome.
If the agent creates more review work than the task it replaces, something is wrong.
If people stop trusting its output and recheck everything manually, something is wrong.
If an agent generates dozens of tasks nobody asked for, something is wrong.
If three agents are monitoring one another because nobody trusts any of them, something is wrong.
The objective is not maximum automation.
It is minimum unnecessary effort.
Verification matters more as agent activity grows
One reason companies are comfortable with humans is that they have developed social and managerial mechanisms around human work.
Managers review.
Peers challenge.
Customers complain.
People learn.
With agents, that feedback loop can disappear.
An agent can produce a large volume of apparently correct work without anyone noticing subtle failure.
So verification becomes more important.
A coding agent can create a pull request.
Automated tests can verify basic correctness.
A security agent can run an independent review.
A human may only inspect high-risk changes.
A data agent can perform a migration.
Another mechanism can reconcile the source and destination.
A document agent can generate an implementation guide.
The customer or human owner can verify that it matches reality.
The important thing is that completion is proven somehow.
This is part of the Virtual Delivery Center Protocol.
The agent does not get credit because it says the task is complete.
The outcome needs evidence.
An agent should not always verify itself
This sounds obvious, but it will become an important design principle.
If the same model produces an output and then checks the output using essentially the same reasoning path, the verification may have the same blind spots.
Sometimes that is acceptable.
Sometimes it is not.
For important work, the VDC can separate production and verification.
One agent builds.
Another checks.
A deterministic test validates.
A human reviews the exception.
Different forms of intelligence can challenge one another.
The point is not distrust.
It is resilience.
Humans have used this pattern for years.
The person who prepares the financial statement is not always the only person who audits it.
The engineer who builds a system is not always the only person who security-tests it.
Machine work should not be treated more casually simply because it is fast.
Agents need scoped access, not general access
The moment an agent connects to enterprise tools, the governance problem changes.
Now it can potentially see or act on real systems.
That is where enthusiasm needs to slow down a little.
An agent supporting customer onboarding may need access to the customer configuration.
It probably does not need the entire CRM.
A coding agent may need one repository.
It does not need access to every product.
A billing agent may need specific transaction records.
It does not need employee payroll.
This is another reason VDCs are useful.
Access can be connected to the execution mandate.
A particular agent joins a particular VDC.
It receives the permissions required for that work.
When the work ends, the access ends.
This is much safer than creating broad corporate agents that gradually become omniscient.
Agents need an expiry date too
People leave projects.
Agents should leave too.
This sounds funny at first, because software does not get bored or resign.
But that is precisely why old agents can quietly remain forever.
A project ends.
The workflow changes.
The agent is no longer relevant.
Yet its credentials remain active.
Its connection still exists.
Nobody remembers who built it.
That is how technical debt becomes governance debt.
Every agent should have a lifecycle.
Created.
Tested.
Activated.
Monitored.
Changed.
Restricted if needed.
Retired.
A VDC should know which agents are still active and why.
This will become increasingly important as the number of agents grows.
The VDC should keep an agent registry
A mature VDC should be able to answer some basic questions.
Which agents are active?
What does each one do?
Which outcome does it support?
Who owns it?
What systems can it access?
What model does it use?
What can it execute independently?
How is it verified?
How much does it cost?
When was it last reviewed?
This should not become an enormous bureaucracy.
For simple low-risk agents, the record can be simple.
For high-risk agents, it should be richer.
The point is visibility.
If the company cannot list the agents participating in a critical workflow, it does not fully understand its own workforce anymore.
The economics of the VDC change when agents participate
This is where things get really interesting.
Traditional delivery economics are built around people.
Five engineers for six months.
Two analysts for a quarter.
A testing team of eight.
A project manager.
A blended hourly rate.
Once agents participate meaningfully, these measures begin to lose meaning.
Maybe the work that used to require five people now requires two people, three agents, a verification system, and occasional specialist input.
How should that be priced?
How should productivity be measured?
How should the benefit be shared?
The answer cannot always be to recreate the old labor model and pretend the agent is another cheap employee.
The VDC should move gradually toward the economics of outcomes.
What did it cost to produce a verified result?
How long did it take?
What human judgment was required?
What machine capacity was consumed?
How much rework occurred?
What risk was carried?
That is a more useful economic picture than simply counting hours.
This is also why the next stage of the VDC conversation has to move beyond timesheets.
AI may make the VDC smaller and more capable at the same time
There is an instinct to imagine scale as more people.
A larger VDC means more specialists.
More pods.
More coordination.
But agentic execution creates a different possibility.
A VDC may become more capable while involving fewer humans.
A small internal core might work with a few highly capable specialists and dozens of narrowly scoped agents.
The humans spend more time on:
Context.
Decisions.
Relationships.
Exceptions.
Architecture.
Quality.
The agents handle:
Monitoring.
Preparation.
Repetition.
Search.
Testing.
Routine production.
Coordination.
The organization becomes smaller in headcount but larger in execution capacity.
That is the deeper idea behind The Company After Headcount.
This does not mean the human becomes less important
In some ways, the opposite happens.
As machine production becomes abundant, human judgment becomes more valuable.
When agents can generate ten possible answers instantly, someone still needs to know which one matters.
When agents can create code quickly, someone needs to understand the architecture.
When agents can produce analysis, someone needs to understand the business consequence.
When agents can send customer communication, someone needs to understand the relationship.
When agents can take actions across systems, someone needs to be willing to accept responsibility.
The scarce human contribution moves upward.
Not necessarily upward in hierarchy.
Upward in consequence.
That is an important distinction.
The danger is turning humans into exception machines
There is also a downside.
If agents take all the routine work, humans may receive only the ugly parts.
The angry customer.
The difficult bug.
The uncertain legal question.
The unusual failure.
The emotionally charged situation.
The decision where there is no obviously correct answer.
That can make human work more meaningful.
It can also make it exhausting.
The VDC should be careful not to design a system where humans spend the entire day dealing with problems machines could not solve.
People still need rhythm.
They need opportunities to learn.
They need some work where they can build confidence rather than constantly firefight.
This is especially important for younger professionals.
If agents take every beginner task, we need another way for people to develop judgment.
That was one of the concerns in When AI Agents Outnumber Humans.
The VDC can help by turning learning into part of execution rather than assuming apprenticeship will happen automatically.
A junior professional may learn by governing agents
This may sound odd today.
In a few years, it may feel completely normal.
A junior engineer may not spend two years writing repetitive boilerplate code.
Instead, they may learn by reviewing agent-generated code, tracing failures, understanding why tests broke, investigating edge cases, and learning architecture from real outcomes.
A junior analyst may not spend all day assembling reports.
They may work with research agents, challenge assumptions, verify evidence, and learn how business decisions are made.
A junior marketer may not spend weeks creating first drafts.
They may learn by understanding customers, evaluating machine-generated ideas, and observing what actually moves people.
The apprenticeship changes.
It should not disappear.
The best VDCs will use agents to preserve human energy
There is a version of AI adoption that simply raises expectations.
Now that drafting is faster, write twice as many documents.
Now that coding is faster, ship twice as many features.
Now that analysis is faster, attend twice as many meetings with twice as much information.
That is not progress.
It is acceleration without thought.
A good VDC should use agents partly to protect human attention.
Let machines chase missing information.
Let them prepare the context before the meeting.
Let them monitor routine states.
Let them perform the repetitive test.
Let them maintain the documentation that always gets forgotten.
Then let people spend more time thinking.
Talking to customers.
Solving the strange problem.
Making the difficult choice.
Actually understanding what is happening.
If AI only makes everyone busier, we have designed the system badly.
A VDC can have a human core and an agent mesh
One useful way to imagine the future VDC is as two overlapping structures.
The human core contains the people who carry context, trust, judgment, and accountability.
The agent mesh surrounds that core.
Some agents are persistent.
Some appear for one module and disappear.
Some monitor.
Some build.
Some verify.
Some coordinate.
The human core does not need to control every machine action directly.
It defines the boundaries under which the mesh operates.
This creates a different kind of leverage.
A product leader does not need twenty people reporting to them to control a large execution system.
They may lead a small human team connected to a much larger machine capability layer.
That changes management.
It changes cost.
It changes the meaning of team size.
It changes what “capacity” even means.
The VDC should not care whether the capability is human or machine until it needs to
This may be one of the most useful principles.
Start with the work.
What needs to happen?
What quality is required?
What consequence exists if it goes wrong?
How much context is needed?
How quickly must it happen?
Then choose the right capability.
Sometimes that will be an employee.
Sometimes an external specialist.
Sometimes a delivery pod.
Sometimes an agent.
Sometimes a SaaS tool.
Sometimes a combination.
The VDC should be capable-agnostic at the beginning and governance-specific at the end.
It should not start with an ideology.
“AI first” can be just as limiting as “people first.”
Outcome first is better.
The VDC makes AI practical because it gives AI somewhere to belong
This may be the most important point.
Most AI conversations today are still about tools.
Which model?
Which agent framework?
Which copilot?
Which vendor?
Those questions matter, but they are temporary.
The models will change.
The tools will change.
The agents will change.
What persists is the execution mandate.
The company will still need to onboard customers.
Build products.
Run operations.
Serve markets.
Manage compliance.
Modernize systems.
The VDC gives these mandates a persistent operating home.
Agents can enter that home.
They can be replaced.
Improved.
Limited.
Retired.
The enterprise does not need to redesign itself every time AI technology moves forward.
The VDC absorbs the change.
What a mature human-agent VDC might look like
Imagine a product engineering VDC.
The internal product leader owns priorities and customer value.
The principal architect owns technical direction.
A small internal engineering core holds deep product context.
External specialists join when unusual capability is needed.
A coding agent generates routine implementation.
A testing agent continuously validates regression risk.
A documentation agent keeps technical documentation current.
A security agent scans changes before release.
A release agent prepares deployment steps.
A human engineer reviews consequential changes.
A specialist security reviewer joins when a major architectural shift occurs.
The composition changes over time.
The product does not need a permanently oversized team.
It does not become dependent on one outsourcing provider.
It does not hand accountability to AI.
The VDC remains the execution boundary.
Humans and machines move inside it according to the work.
That is a much more practical picture of the future than “AI will replace developers.”
What leaders should get right
Before putting agents inside a VDC, leaders should get a few things clear.
Start with the outcome. Do not deploy agents because the technology is interesting.
Give every agent a defined purpose. If nobody can explain what it is for in one paragraph, the scope is probably too broad.
Keep human accountability visible. Someone should always own the business consequence.
Grant narrow access. The agent should see and do only what the work requires.
Separate high-risk production from verification. Do not let speed remove independent checks where they matter.
Give agents a lifecycle. Review them, update them, limit them, and retire them.
Measure outcome contribution. Do not celebrate agent activity simply because it looks productive.
Protect human development. Do not automate away the apprenticeship path without replacing it.
Use AI to remove friction. Do not use it to create a faster version of organizational noise.
The future team will not look like a team
That may be the most uncomfortable part.
We are used to seeing a team.
Ten people.
One manager.
A set of roles.
A familiar hierarchy.
The future execution system may look different.
Three internal people.
Two external specialists.
Seven active agents.
One SaaS platform doing a job that once required a team.
A verification layer.
Several customer systems.
Nobody sitting in the same place.
Nobody belonging to exactly the same organizational category.
And yet the system can still have structure.
It can still have ownership.
It can still have boundaries.
It can still have trust.
It can still produce excellent work.
That is what the Virtual Delivery Center is really trying to solve.
Not remote work.
Not cheaper labor.
Not an AI workforce.
The harder problem is how to make many different forms of capability behave like one coherent execution system.
AI agents are going to become a large part of that system.
The important thing is not whether they outnumber us.
It is whether we know where they belong.
Inside a well-designed VDC, they are neither employees nor random tools.
They are governed participants in execution.
Humans continue to carry purpose, judgment, trust, and consequence.
Agents bring speed, scale, persistence, and machine capability.
When the two are designed around the same outcome, something much more interesting happens.
The team stops being a fixed group of people.
It becomes a living execution system.
And that may be the real shape of work ahead.