Agents – the virtual workforce

AI agents need management: clear assignments, bounded authority and tested releases. How organisations put their virtual workforce to productive use.

By Christian Fehrlin

Monday morning. A team lead opens her department's overview. Overnight, one agent has reconciled delivery dates, another has prepared enquiries, and a third has sorted outstanding documents. Much of the work is complete. Three cases await a decision. A fourth says: “Task stopped. Insufficient permission.”

It sounds unremarkable. That is precisely the progress. The work is visible, the boundaries are visible, and accountability is visible. The team lead does not have to search twenty chat histories to understand what happened.

This scene is a deliberately fictional vision. It illustrates what the next stage of automation brings: additional capacity to execute work. That creates a management responsibility. Companies that want to deploy agents as virtual employees must give them a defined place in the organisation.

My argument is this: An agent's value comes from a well-defined assignment, verifiable work and clear accountability. Model quality is a prerequisite. The organisation must design the rest.

A virtual employee has no common sense on demand

The employee metaphor is useful because it prompts the right questions. What is the agent's job? Who does it report to? What may it decide? When must it ask? The metaphor becomes dangerous when we infer human judgement, loyalty or an ability to bear responsibility.

An agent is a software system. A language model can select steps within a defined environment, invoke tools and respond to results. A conventional workflow follows a more predetermined sequence. Anthropic's “Building effective agents” describes this conceptual distinction. For a stable process whose steps can be fully specified, a workflow may remain the better choice.

An agent can choose a plausible next step and still overlook an important dependency. It does not bear responsibility for the commercial damage caused by an incorrect commitment. That responsibility remains with the people who decide to deploy it, set its authority and run the service.

I would therefore not launch an agent with “Take care of purchasing.” That is not workable delegation. It is an open-ended exposure wrapped in a friendly instruction.

Give the agent an assignment with an observable finish

Consider a fictional medium-sized company. Every day, an employee checks which deliveries put open customer orders at risk. She combines purchase orders, confirmed dates and supplier updates. An agent will take over part of that preparation.

A workable assignment might read: “By eight o'clock, check all open purchase-order lines due within the next seven days. Compare the confirmed date with the latest approved supplier update. For discrepancies, prepare a clarification case containing the source, affected orders and a proposed action. Do not change dates or send messages.”

This defines scope, timing, sources, output and boundaries. Crucially, it describes completion: relevant lines have been checked, discrepancies documented with evidence, and lines that could not be checked explicitly identified. An empty report must not automatically mean “no problems.” The connection may simply have been unavailable.

For the first agent, I would require a short mandate that business and IT can both understand:

The mandate must be implemented technically. Write access is actually removed, spending capped and available tools restricted. A prohibition in a prompt alone does not replace those controls.

An agent needs a manager with time in the calendar

An “owner” named in a spreadsheet is not enough. Someone must examine poor results, resolve outstanding exceptions and refine the assignment. That takes capacity. Otherwise, accountability remains on paper while unfinished cases accumulate in daily operations.

In this example, the planning function manages the agent's business behaviour: Which discrepancy matters? Which enquiry would help? A technical team owns access, failures and versions. The responsible manager approves any significant extension of authority. In a small company, a few people may hold several roles. The decisions must still remain distinguishable.

Employees also need clarity. Who takes an escalated case? Which preparation can be treated as checked? How should an incorrect recommendation be reported? An agent that hands work off without knowing its recipient and return path creates another queue.

The weekly management question is therefore: Where did this agent genuinely complete work, where did it merely pass it along, and where did it create additional work? The answer tells us more than the number of messages it produced.

Sprawl begins with a good intention

The planning team is pleased. Sales copies the agent, adds a different scheduling rule and allows reply drafts. A third team connects its copy to a mailbox. A few weeks later, three systems have almost the same name, different knowledge and different operating rules.

Nobody planned this situation. Everyone wanted a small improvement. That is precisely why the organisation needs a straightforward route from experimentation to accountable operation.

A centrally accessible agent register should show purpose, business owner, technical support, current version, data sources, tools, authority, cost centre, user group and retirement date or next review date. Status matters just as much: experiment, test, limited pilot, production or retired. An experiment must not quietly become a business-critical service.

This aligns with the Govern function in the NIST AI RMF Playbook, which covers AI system inventories, responsibilities and change management, among other topics. Our particular agent register is a design proposal, not a claim that NIST requires this exact form.

The approved operating route should be easy to use: prepared access, traceable records and a manageable approval process. If the official route blocks every small improvement for months, teams will look for shortcuts again.

Why a changed prompt can be a release

A sentence is added to the delivery agent: “Treat long delays in receiving a reply as urgent.” No conventional software function has changed. Yet the agent may now escalate more cases, set different priorities or, if its authority is later extended, prepare different messages.

A changed instruction is therefore a potential change in behaviour. The same applies to a new model, an additional data source, a different tool description or changed permissions. The production version consists of these elements working together.

A release should record which combination was tested and approved: code, model configuration, instructions, tool contracts, permissions and rules for knowledge sources. Dynamic business data remains dynamic; its origin and timestamp must be traceable for each decision. A new purchase order does not require a release. A new rule for interpreting purchase orders does.

The effort should reflect the possible consequences. A purely editorial correction can follow a short review path. New write access, external communication or financial authority requires substantially stronger scrutiny. This classification is an operational decision, not a universal risk category.

From a good demo to an approved contributor

For our delivery agent, I would use six steps. They make the route into production predictable and can remain lightweight for small changes.

First: Explain the change. What problem does it solve? Which cases should work better afterwards? A release with no expected improvement is difficult to assess meaningfully.

Second: Test known cases. Use suitable, sanitised test data containing ordinary cases, contradictory updates, missing permissions and unavailable interfaces. Define acceptable outcomes beforehand. An elegantly written report is not sufficient if it concerns the wrong purchase order.

Third: Test behaviour at the boundaries. What happens after a timeout? Does the agent recognise a line already processed? Can a supplier message induce it to follow instructions from an external source? What happens when a tool call leaves it unclear whether a change was executed? A retry must not trigger an uncontrolled second action.

Fourth: Run without real-world effects. Where the process permits, the team compares the new version's proposals with the existing way of working. External actions remain disabled. This shadow operation reveals whether the test cases adequately represent everyday work.

Fifth: Approve a limited rollout. Start with a defined user group, case type or volume. The accountable person confirms the version, boundaries and stop conditions. Only then does the scope of authority grow.

Sixth: Observe and decide. Compare outcome quality, interventions, waiting time and costs against the baseline. Stop or revert if important boundaries are breached. The rollback decision must not be invented during the incident.

These tests are often called evals. Anthropic's article on evaluating agents emphasises repeated trials and the distinction between an execution record and the actual outcome. In our example, that means checking whether the correct clarification case was created. The agent's statement alone is not proof of success.

The emergency stop must reach work already in progress

An agent can be stopped technically. That does not undo its previous actions. A sent message remains with the recipient. A changed purchase order may already have triggered downstream processes. Rolling back the software does not automatically repair those business transactions.

The operating plan must distinguish three things: stopping new assignments, bringing ongoing work to a controlled halt, and resolving changes already made. Open cases need a list containing the last confirmed action, the accountable person and the next step. Restarting means examining those states rather than executing every assignment from the beginning again.

Deputy arrangements belong here too. When the responsible person is absent, the agent must not produce an unlimited collection of urgent cases. Either a named deputy takes over, or the permitted operating mode is reduced.

The Manage function in the NIST Playbook addresses post-deployment monitoring, incidents, recovery and retirement. The practical implication is simple: a production agent needs an operating model that covers the bad Tuesday too.

Promote an agent on the strength of its results

Initially, our agent gathers information. Later, it may create internal clarification cases. After further testing, perhaps it will be allowed to send standardised enquiries. Each extension is a fresh decision about authority. It follows from credible results within a clearly bounded set of cases.

A single favourable aggregate result is not enough. Examine which cases succeed, which fail and how serious the failures are. A rare but incorrect binding commitment may matter more than many correctly sorted documents. Missing data and justified escalations must not automatically count as poor performance. Otherwise, you optimise the system to conceal uncertainty.

The measures should complement each other: correctly completed cases, human handling time including rework, time to outcome, avoidable escalations, breaches of authority boundaries and cost per accepted result. Also ask whether users still trust the system and actually report errors.

We described the technical foundation in our article on agentic infrastructure. Management turns those capabilities into an accountable way of working.

Virtual employees also incur management costs

The licence is rarely the whole bill. Integration, ongoing review, adaptation, operations and exception handling add to it. Ignoring those costs produces a workforce that is cheaper on paper than in daily operations.

Consider an explicitly hypothetical monthly example. Previously, 1,200 cases each required eight minutes of human work: 160 hours. With an agent, an average of three minutes per case remains, including review and case-related rework: 60 hours. Another 20 hours go into supervision, testing and maintenance. The remaining reduction is 80 hours.

At an assumed CHF 90 per hour, that represents CHF 7,200 in valued capacity. Deduct assumed additional technical costs of CHF 2,400 per month, and the calculated balance is CHF 4,800 before one-off implementation costs. This is not a measured customer saving or an automatic cash saving. It assumes comparable volume and quality.

If case-related human handling doubles to six minutes, the reduction after supervision falls to 20 hours. Its capacity value of CHF 1,800 is below the assumed additional technical costs. That is exactly why management and rework belong in the business case. Leadership must also decide how the released capacity will be used: fewer backlogs, better service or additional volume.

The organisation becomes the commissioner of its software's work

The compelling future is a company where people no longer have to carry work laboriously through every application. They formulate an objective, provide the necessary context and delegate appropriate steps. Agents work within those boundaries, make progress visible and return decisions to the people able to take responsibility for them.

Leadership changes along with it. Good task descriptions, clear feedback and reliable handovers become capabilities that directly influence software performance. Domain expertise does not become redundant. It is needed to recognise whether a result solves the right problem at all.

Start with one agent and one important process. Write its mandate. Name its manager and deputy. Test a version against real requirements. Decide on a limited release and reserve time to review the results. Multiplication becomes worthwhile once this cycle works.

The key question for the next leadership meeting is: If ten agents start working for us tomorrow, who will give them good assignments, who will assess their performance, and who may change their authority?

An organisation with a clear answer can use additional capacity responsibly. Leaving the question open means automating its organisational ambiguities too.

Would you like to launch your first agent with a robust management and release model? We work with you to define assignments, authority, evaluation and operational ownership.

Context: This article proposes a management approach. The company scene, mandate and all figures are illustrative examples, not a description of a customer deployment. Sources checked on 12 November 2026.