Blog #3 | AI Agents in the Modern Workplace: The Future of Digital Work
For a good ten years, the Modern Workplace meant managed devices, secure identities, and data in the cloud. That is exactly what most of my posts have been about. Now a fourth layer is being added, and it is changing the other three. Now we will explore what a workplace with AI agents looks like, what that means for IT, and the steps I would take to get there.
The new Layer in a Modern Workplace with AI Agents.
It is important to understand the order of things. The agent layer is not separate from the modern workplace. It is above it. Without Entra ID, conditional access, and device compliance, you cannot operate agents in a controlled manner. You must first answer the question, «Who is allowed to do what?». The good news is that if you have your endpoint stack under control, you have already done half the work.
How a digital, modern Workday in 2026 looks like.
To make this more concrete, here is a day as I already see parts of it happening with clients:
-
7.30 am | Overnight, a workflow agent pre-sorted the new tickets, merged duplicates, and prepared responses for six cases. Four of these were automatically closed, and two are awaiting approval.
-
8.15 am | A research agent retrieved the documents for a tender, compared them to previous bids, and identified a gap: a certification is missing. This exception was escalated because it should have been.
-
10.00 am | A new colleague starts. The onboarding agent has prepared the device, groups, licenses, and initial tasks. IT reviews a summary instead of seven different portals.
- 2.00 pm | During a client meeting, someone asks for figures from three systems. The agent answers in a Microsoft Teams window, citing the sources – not because they know everything, but because they have access to the right tools.
- 5.00 pm | The reporter submits the weekly report. Nobody builds it by hand anymore.
What a Modern Workplace means for IT today.
For endpoint and identity teams, this is good news because the underlying mindsets remain the same. From an IT perspective, an agent is a new type of account with some very peculiar characteristics: It works at night, does not have a device, and can accomplish a great deal in seconds.
-
Lifecycle: Agents need to be created, modified, and deleted just like user accounts. An agent whose department has finished a project must be deactivated. Otherwise, you will have inactive accounts with inactive permissions in a year.
-
Less Privilege: One tool per task, not a generic set «for all eventualities.»
-
Tool Permissions: Which integrations, commands, and browser targets are actually allowed? This is the new version of «Which apps are allowed on the corporate network?»
- Traceability: Every tool call is logged, every permission is traceable. Without this, the first data privacy question becomes uncomfortable.
- Costs: Make resource consumption per agent visible and limit it. Agents do not have cost centers in mind.
What happens to the Endpoint.
Because this is my core topic, I will dedicate a separate section to it: The device is not disappearing. It is simply losing its special status. For ten years, the endpoint was the place where work happened. In the future, it will be one of several locations alongside agents that work without a device and without a logged-in user. In practical terms, this changes three things in endpoint management:
-
Compliance becomes the entry ticket, not the goal: An AI agent accessing company data on behalf of a user must be bound by the same conditions as that user's device. Those with a solid Conditional Access setup can extend this. Those without now have two problems to deal with.
-
Troubleshooting shifts: Some errors will no longer be device errors, but tool errors: missing permissions, an integration that is not responding. For this, you need logs at the agent level, not just at the device level.
- The inventory grows: In addition to the device inventory, there will be an agent inventory. Both require owners, lifecycle records, and documentation. The mindset is identical, and that's precisely why endpoint engineers are well-prepared for this task.
The AI Agent in the Command Line.
The place where agents are most productive today is not a chat window. It is the terminal. That might sound like a step backward, but it is quite the opposite: In the command line, an AI agent has access to the repository, scripts, logs, tests – everything that truly defines a task. That this is not just a developer hobby is demonstrated by a study conducted by Microsoft itself. At the beginning of 2026, Microsoft released two command-line agents to its own development team and evaluated their adoption across tens of thousands of engineers. I find three findings relevant for planning:
-
Approximately 24% more merged pull requests from users compared to what would have been expected without the tool.
-
The adoption occurred through social networks within the company, not through directives. And whether someone stuck with it depended on their individual work style, not their role or experience.
What does this mean for the Introduction of AI Agents?
For implementation, this means something inconvenient: A rollout by directive works less effectively than a rollout driven by people who voluntarily use it and spread the word. So, find the four or five colleagues who are already trying it out, give them time, and make it easy for everyone else to join in.
The second part of the picture is crucial. A command-line agent can also run without human intervention – started by a schedule, a ticket, or a commit, without a prompt, with a fixed task. This is the mode of operation in which a tool becomes a colleague: The nightly run that updates dependencies and leaves a pull request. The agent that compiles compliance deviations every Monday.
And this is precisely where the question shifts from productivity to security. Interactively, a human observes and intervenes. Headless does not. That is why every headless agent requires the same package: its own identity, the strictest set of permissions, a log, time and cost limits, and a sandbox.
Why do AI Agents need a Sandbox?
An AI agent that executes code, writes files, or launches commands is something fundamentally new from a security perspective: a process whose next action no one knows in advance – not even the manufacturer. The most common mistake I see is simply running it with the rights of the logged-in user. This gives it everything that person has access to: network drives, saved login credentials, database connections. The technical term for this is «ambient authority,» and it is the root cause of most agent-related incidents.
The options shown in the diagram represent a decision based on trust, not budget:
-
Container: fast and sufficient for most cases, as long as the agent only executes your own code. The kernel is shared with the host. This trade-off should be made consciously and not overlooked.
-
Syscall filtering (e.g., gVisor): Container speed, but system calls are routed through an intermediary layer. For me, this is the pragmatic middle ground.
-
MicroVM: Dedicated kernel for each run, slightly slower to start. The right choice as soon as the agent executes code that neither you nor the user wrote. This applies to anything originating from the internet, customer data, or a support ticket.
Four things are often overlooked when it comes to isolation: an allowlist instead of open network access, explicitly authorized tools instead of «everything that is available,» secrets outside the sandbox (the agent's environment only sees a placeholder, the real key is only used during the outgoing call), and a log of every tool call.
Important: A sandbox does not prevent prompt injection. It prevents a successful injection from causing significant damage. Anyone who sells the sandbox as protection against manipulation will be disappointed. Those who use it for damage control are on the right track. Both require additional input validation, tool allowlists, and output analysis.
And a phrase I have adopted: If you cannot explain the worst-case scenario for the AI agent, it is not yet ready for production. Not because an error is likely, but because the answer to this question determines the sandbox level.
How Support and Service Desks are changing.
For me, the service desk is almost always the first area where AI agents really make a difference and the most honest test. What I observe there:
The number of tickets hardly decreases. What does decrease is the time until the first meaningful answer.
The easy cases become more boring, the difficult ones remain difficult. For team planning, this means: less quantity, more depth, different skills.
Documentation suddenly becomes more valuable because an agent is only as good as its knowledge base. I have seen teams that cleaned up their knowledge base for the first time thanks to agents.
Measurability increases. When an agent triages, they log the process, and you finally know how often each case occurs.
Humans are becoming Agent Bosses.
For me, the most interesting metric from the Work Trend Index is the human-agent ratio: the relationship between human oversight and agent efficiency. It cannot be defined globally. It depends on the task. It can be high for research, but must remain low for anything with external impact or financial flow. My rule of thumb: the greater the potential damage from an error, the more stringent the oversight needs to be, regardless of how good the model is. For humans, this means three new skills, none of which are prompt engineering:
-
Writing tasks: formulating a goal in such a way that success is measurable. Anyone who can write good tickets already has this skill.
-
Checking results: randomly, systematically, and with knowledge of where this agent typically goes wrong.
-
Defining escalation: predetermining what the agent never decides alone. This is leadership, not technology.
What often goes wrong in Practice.
-
Shadow agents: Departments assemble their own AI agents in the store, and no one has an overview. Therefore, inventory management takes priority.
-
Agent sprawl: Forty AI agents, of which only six are used. Without usage data, this goes unnoticed for months.
-
Nothing measured: «People like it» does not survive any budget round. Time per case, error rate, and throughput time must be defined in advance.
-
Automated flawed processes: If the process was already unclear, an agent will only make it even more so.
- Costs spiraling out of control: The most expensive AI agent is the one that runs hourly and whose results no one reads.
Recommendation: Sequence for the next twelve Months.
-
In months 1–2, you first build a complete agent inventory, activate the control layer, and define data classes and restricted zones. Success here means that you can always say which AI agents exist and who is responsible for them.
-
In months 3–4, exactly two use cases go live. Each receives its own agent identity and defined metrics. You recognize success by a measurable time saving and the absence of security vulnerabilities.
- In months 5–8, the pilot becomes a platform. For this, you establish approval processes and schedules, make the costs per agent transparent, and manage the handover of operations. The goal: The AI agents run reliably without your constant intervention, and you can track the cost of each agent at any time.
- Finally, in months 9–12, the focus shifts to the organization itself. Responsibilities are redistributed, and a clear agent boss account is established. Employees are trained and processes are redesigned. The real success is demonstrated by the fact that processes ultimately look faster and different than before.
Am I ready? The Questions that matter.
-
Do I know which AI agents are running in my tenant? → Build an inventory before you build anything.
-
Does each AI agent have its own identity? → Correct the permissions model, then proceed.
-
Is device compliance and conditional access in place? → Finish the modern workplace infrastructure first.
-
Is there a business owner for each AI agent? → Do not deploy any agent without an owner.
-
Can I see usage and costs per agent? → Add tracking, otherwise your budget will be wasted.
-
Does the business unit know what the AI agent is never allowed to do on its own? → Document escalation rules.
Conclusion.
Usually I do not write much about what I consider exaggerated, but this topic warrants it:
-
I do not believe that AI agents will be making complex, externally impactful decisions on their own in the coming years. Not because they are technically incapable, but because no one wants to assume liability, and that's understandable.
-
I do not believe in the «»X% productivity gain» figure from vendor slides. In the projects I measure, we see measurable benefits, but rarely the value shown in the slides.
- I do not believe that prompt training is the key. The key is to restructure work processes. This is also supported by the figures from the Microsoft Work Trends Index 2026, where organizational factors explain the impact far more strongly than individual ones.
- And I do not believe it is enough to keep the topic solely within IT. An AI agent that takes over a business process needs an owner in the business department. Otherwise, IT will be responsible for results it cannot assess from a business perspective.
FAQ: Frequently asked Questions about AI Agents.
A fourth layer is added. Identity, device, and data remain the foundation. An agent layer will sit on top of this, and a control and auditing layer is needed below. Those who have their endpoint stack under control have already completed half the preparatory work.
Yes. An agent that takes action cannot run under the account of the person who launched it. Otherwise, you cannot later determine who did what, and it inherits all of that person's rights. Microsoft introduced Entra Agent ID for this purpose, and Agent 365 uses this as its foundation.
A sandbox is an isolated environment in which AI agents operate. It does not prevent manipulation through prompt injection, but it limits the potential damage. A simple container is usually sufficient for your own code, but for external code, stronger isolation is necessary.
In four phases: first, inventory and rules; then, precisely two measured use cases; then, the step from pilot to platform with approval processes and cost transparency; and in the final third, the restructuring of roles. The most frequent cause of failed projects is the reverse order.
In our experience, no. What shrinks is the amount of searching, transferring, compiling, and following up. What remains is more decision-making and more responsibility per person. And a new role to lead these AI agents.
Want to learn more? Discover your potential?
Get in touch. Together we will figure out what makes sense for your business.
%20-%20Teams%20Logo.png?width=576&height=182&name=Logo%20in%20standard%20arrangement%202%20(RGB)%20-%20Teams%20Logo.png)