Your PowerShell scripts are about to become a liability.
This isn't because PowerShell is dying
or because your code is bad.
The problem is that the assumptions you used to build them
no longer match how modern enterprises actually function.
You design those scripts for a world
that doesn't exist anymore, where problems were predictable,
inputs were clean, and every decision tree could fit
on a single whiteboard.
By the end of this video,
you will understand how to evolve your entire script library
into something completely different.
We aren't talking about a replacement,
but an evolution into a fleet of thinking workers.
These agents authenticate themselves,
reason about their environment,
and execute tasks autonomously using Microsoft Graph
as their single source of truth.
You will see why semantic kernel is much more than a wrapper
for PowerShell, acting instead as an orchestration engine
that teaches models when and why to use your tools.
The stakes are very real for your career and your organization.
Companies that fail to operationalize this shift by 2026
will find themselves at a massive disadvantage.
While they are still writing manual conditional logic,
their competitors will be deploying agents
that adapt to variations without a single code change.
One team will be stuck managing permanent service accounts
with dangerous tenant-wide access,
while the other users just in time
identity scope to specific tasks.
This is not a theoretical exercise or a vision
of the distant future.
We are taking the CMD-LEDs you already use every day,
like GetMuser and UpdateMuser mailbox settings,
and plugging them into a reasoning layer.
This layer decides when to call them,
determines the correct sequence,
and figures out how to recover when things go sideways.
The assumption that broke,
the assumption that is currently breaking your automation
is that your enterprise environment is predictable
and unchanging.
Think about how you build a script today.
You start by defining the happy path,
which is the perfect scenario
where everything goes exactly as planned.
The user exists, the license is available,
and there are no strange edge cases to worry about.
You write your steps in a linear order,
so step one checks the account status,
step two applies the license,
and step three sends a notification.
You test it and deploy it,
and it works perfectly until a user has special characters
in their name or Microsoft Changes and API response format.
When those failures happen,
you start adding conditional branches to handle the mess.
You add error handling to catch missing users,
or log license failures,
and your logic begins to accumulate.
The script grows longer and more complex,
making it harder to follow, test, and maintain over time.
But here's the thing that nobody wants to admit.
You aren't actually solving the core problem
by adding more code.
You're just building a massive pile of if-then-else blocks
that represent one person's guess about what might go wrong.
Tomorrow, something you never predicted will happen,
like a mailbox migration getting stuck
in a state you've never seen before.
Maybe the graph API throttles your requests
because they are hitting the limit too fast,
or an error message comes back in a format
your rejects can't read.
Every time this happens,
someone has to open the script,
remember how it works,
add another branch, and redeploy it.
That is a massive amount of maintenance debt
that most teams never bother to track.
Every new scenario requires a full cycle of revision and testing,
creating constant friction for the smallest changes.
Real enterprises are messy and unpredictable.
User requests vary wildly from one day to the next,
and error conditions branch out in ways you can't foresee.
Business logic shifts the moment an organization
reorganizes or adopts a new tool.
A simple ticket about shared drive access
could mean 15 different things,
and each one requires a different diagnostic path to fix.
The failing assumption is that you can predict
every single one of these variations
and encode them into a script.
You can't do it profitably,
and you certainly can't do it in a way that scales.
The real issue isn't the script itself,
but the architecture behind it.
Scripts are deterministic engines that follow a set sequence,
and they are excellent at doing exactly what they are told.
However, they have no ability to reason about what they are doing.
They can't look at a ticket and realize
it's a licensing issue rather than an access problem.
They can't read an error and decide to wait 30 seconds
before trying again.
That gap between what the script is programmed to do
and what the situation actually requires
is where the friction lives.
This gap is growing wider,
as environments become more complex and less predictable.
This is where the architecture breaks,
and it's why we need a new approach.
Where automation hits its ceiling.
Automation is powerful, but it has a hard limit.
That limit is exactly where scripts start to break.
We know that automation works brilliantly
when three specific things are true.
First, the input has to be structured,
meaning you know exactly what you are going to receive
and what format it will be in.
Second, the decision tree must be finite,
so you can map out every possible path
and turn it into code.
Third, the outcomes have to be deterministic.
The same input should always produce the same output.
If you run a script to set up a user with a specific name,
that user gets created the same way every single time.
But in reality, IT tickets do not arrive
in a structured format.
They show up as messy, natural language
with a lot of hidden context.
Someone sends an email saying their email is not
syncing on their laptop, they cannot access the shared folder,
and for some reason this only happens on Tuesdays.
That is one single ticket, but it contains
at least three separate problems.
The person writing it does not understand
how those issues relate to each other,
and the ticket does not tell you if it is a network issue,
a device problem, or a permission error.
The real context is buried deep inside the description.
Here is what actually happens today.
The ticket lands in your queue and you read it
and then you have to stop and think.
You ask yourself, what is actually happening here,
whether this is a networking problem or an identity problem,
and if you should check the device or the cloud first.
You have to figure out which questions will narrow down
the cause so you run diagnostics and look at error messages
to build a mental model of the problem.
Only after all that thinking do you know which script to run,
or if a script will even help at all.
That entire middle part is the thinking part,
and that is where the real bottleneck lives in your organization.
The delay is not in the execution of the fix,
it is in the diagnosis, the triage, and the decision making.
This is why traditional automation
has hit a ceiling in IT operations.
Scripts handle the execution phase beautifully,
but they cannot handle the reasoning
that has to happen before the execution starts.
A script cannot read a ticket and realize
that because a mailbox and a device are both involved,
it needs to check Azure AD health
before looking at device compliance.
It cannot see an error message
and suggest that it looks like a caching issue
that should be cleared before escalating to support.
It cannot ask a user for more details
when a ticket is too vague to understand.
What organizations do instead is keep a human in the loop
to act as the brain.
The script handles the predictable steps,
but the human has to handle the reasoning
by reading the ticket and deciding what to do next.
The human is the reasoning engine,
while the script is just the executor,
and this makes the human the bottleneck
because people are slower than code.
Humans get tired, they miss small details,
and they are incredibly expensive to scale
as the workload grows.
You have probably noticed this in your own work,
the fastest part of closing a ticket
is not running the actual fix,
but rather understanding what the problem is in the first place.
You spend 90% of your cognitive effort
figuring out which tool to use or which assumption to test
while the actual command only takes a second.
That fast part is the only thing scripts currently handle,
so the ceiling we are hitting is not a limitation
of power shell or any other language.
It is a limitation of the architecture itself.
Scripts are designed to be deterministic executors,
which means they are not built to understand context
or handle the ambiguity of a human request.
They are not designed to look at a complex situation
and ask what is actually going on.
This is where the issue stops being about technology
and starts being about architecture.
You need a reasoning layer that can read
an unstructured ticket, understand the context,
and decide which diagnostics to run.
You need something that can interpret results
and decide on the next execution steps,
even if that involves branching or backtracking
when things go wrong.
You need something that can think,
and that is exactly where autonomous agents
change the game as soon as the authentication paradox.
There is a massive security problem
that nobody is talking about,
and it is baked directly into how
power shell automation works right now.
When you write a script, the very first thing you do
is authenticate by running a command
like connect migraph with a service principle.
The script gets a token,
and that token stays active for the entire time
the script is running.
If the process takes an hour to finish,
that token remains valid and usable for that entire hour,
even if the script needs to call the Microsoft Graph
50 different times.
On the surface, this seems fine because it is efficient.
There is no obvious reason to authenticate
multiple times when you can just do it once at the start,
but here is the paradox.
You have essentially created a permanent access key
to your entire tenant.
The moment that script starts,
it has broad access to everything
it was granted permission to do,
and it keeps that access until it finishes.
If something goes wrong in the middle of the run,
or if an error causes the script to behave
in a way you did not intend,
that token is still live.
That is still full unrestricted access.
Now consider what happens if that script gets compromised.
If someone injects malicious code into your script
or hacks your code repository,
they can add a single line to steal your data.
The attacker now owns that token,
and they have access to your entire tenant
for the rest of the tokens life.
By default, that gives them 60 minutes to do whatever they want
inside your Microsoft 365 environment,
and here is the kicker.
In most companies, that service principle
has incredibly broad permissions.
It might have the power to reset passwords, manage groups,
and read every mailbox in the organization
all at the same time.
One compromised script means an attacker
gets all of those permissions at once across the whole tenant,
which makes your automation service account
a high-value target for any hacker.
This is the standard practice today,
and it usually works because the threats
that actually exploit these gaps are still relatively rare.
But this is a ticking clock,
and as automation becomes more common,
and more people have access to scripts,
the surface area for an attack grows,
eventually something is going to break.
The security model for 2026
inverts this logic completely.
Instead of using one permanent token with broad permissions,
you get a unique token for every single individual task.
The token is issued just in time, right when you need it,
and it is scope to do exactly one thing.
It might allow you to reset a password for one specific user
or get the settings for one mailbox,
but it cannot do anything else.
Once that specific task is finished,
the token expires immediately.
Think about how much this changes your risk profile.
If a script is compromised, an attacker might get a token,
but that token was only issued for one tiny operation.
It cannot be used to look at every user in your directory,
it cannot be used to read other mailboxes,
and it definitely cannot be used to create new admin accounts.
The blast radius shrinks from the entire tenant
down to just one single task.
The architectural shift here moves us away
from permanent admin keys and to a just in time
identity scope to a single operation.
An external policy engine decides if an agent is
allowed to do a task right now by checking the risk and the context.
It issues a token that is only valid for 30 or 60 seconds,
which is just long enough to get the job done
before it is revoked automatically.
This is vital for autonomous agents
because those agents will be running constantly.
They will be processing tickets and executing workflows all day long,
and the old security model simply cannot scale to meet that demand.
You cannot give an agent a permanent tenant-wide key
and expect your environment to stay secure.
Autonomous reasoning requires autonomous authentication,
which means using a different identity
for every single decision the system makes.
Semantic kernel as the reasoning layer.
We need to talk about how you actually build this reasoning layer.
This is where semantic kernel comes in,
but I want to be clear about what this tool actually is
because most people get it wrong.
Semantic kernel isn't just a wrapper,
it isn't a library that makes it easier to call PowerShell from your code.
It's something fundamentally different.
It's an orchestration engine designed to teach large language models how to use tools.
The kernel sits directly between the LLM and your PowerShell functions.
It manages the conversation, it interprets what the model decides to do.
It executes those decisions,
and it feeds the results back to the model
so the AI can decide what to do next.
The core concept is simple.
The kernel decides when to call PowerShell,
not just how to call it.
You describe your PowerShell functions to the kernel in plain language.
You explain what each function does,
what parameters it needs, and what kind of results it returns.
The kernel then presents these functions to the LLM as a set of available tools.
The model reads those descriptions, it understands the purpose.
It reasons about when a specific tool should be used.
Should I call this function now?
Or should I call a different one?
What parameters should I pass to get the right result?
What will the output tell me about the next step?
This is the shift from deterministic execution to adaptive reasoning.
A traditional script says, "Do this, then do that, then do the other thing."
The agent says, "Here is my goal, these are the tools I have,
and here is what I should do first based on what I know right now."
Semantic kernel supports three main ways to integrate your tools.
First, you have native plugins,
where you write C-Pars code and decorate methods with attributes
to compile them into your agent.
Second, you can use OpenAPI imports to point the kernel at a specification
and automatically expose those endpoints as tools.
Third, it supports MCP servers,
which are model context protocol servers that standardize how tools are shown to AI systems.
For PowerShell specifically, the native plug-in pattern is the most direct way to get started.
You create a .NET class and write methods that call your PowerShell CMDlets.
Each method should do one specific thing.
Maybe one method retrieves a user from Microsoft Graph
while another resets a password or checks mailbox permissions.
You decorate each method with a kernel function attribute,
so the kernel knows it's a tool.
Then you add a description attribute that explains what the function does in plain English.
When you register this class, the kernel passes every single description.
It learns the purpose of every function.
It understands the parameters you defined.
It creates an internal map of the tools, the data they need,
and the results they produce.
Now, when you ask the model to solve a problem, it doesn't just see your question.
It sees your question alongside a structured list of available tools.
It reasons about which tools are relevant to the problem.
It builds a plan.
The model tells the kernel, "I need to call the get user function with the username jsmith."
The kernel runs the code.
The model sees the result.
Then it decides if the goal is finished,
or if it needs to call another function to keep going.
This is why your descriptions matter so much.
If you write a description that says resets a user's password,
the model understands exactly when to use it.
But if your description is vague like "updates user account",
the model gets confused.
It won't know if that function is for passwords, licenses, or something else.
And it might make the wrong choice.
The kernel uses these descriptions to teach the model the "why" behind the tool.
This allows the LLM to compose multi-step workflows
instead of just running one command at a time.
The model doesn't follow a fixed sequence.
It reads a ticket, understands the goal,
and chains tools together to reach that goal.
If something unexpected happens,
like a user missing or a permission failing, the model adapts.
It tries a different approach because it can reason about what went wrong.
This is orchestration.
It's not just execution.
Microsoft Graph as the data fabric.
The kernel now knows how to orchestrate PowerShell,
but PowerShell needs something to talk to.
It needs access to data.
That's where Microsoft Graph enters the picture.
Microsoft Graph is the unified API layer for every Microsoft 365 workload.
It covers mail, teams, SharePoint, and user identities in Azure AD.
It handles device management through Intune, Planet tasks, and OneNote notebooks.
Instead of learning a dozen different APIs for a dozen different services you go through Graph.
One interface, one way to authenticate, one consistent data model.
For autonomous agents, Graph is more than just an API.
It's the source of truth for the entire state of your organization.
When an agent needs to know something about your enterprise, it goes to Graph.
Is this user licensed?
Is this device compliant?
What are the email forwarding rules on this specific mailbox?
Graph knows the answer to all of those.
This changes how you work.
Right now, when you write a script, you manually craft every single query.
You decide what information you need.
You run a command like GetMJuser, and you look at the properties.
You see a value and decide whether to move to the next step.
You read the error message if it fails.
You interpret what that error means.
The script is just a sequence of manual queries where you encoded every decision point
up front.
An agent doesn't work that way.
The agent queries graph receives the data and analyzes the results to decide the next move.
It makes decisions based on what actually happened, not what you predicted would happen.
If a mailbox is in a strange state you've never seen before, the agent doesn't panic,
it reads the state, understands the implications, and reasons about what fix makes sense.
It might try one approach, see it didn't work, and then try something else.
The power of this is obvious in complex workflows.
Suppose you're diagnosing why a user can't access a shared document.
The problem could be the user, the device, the network, or the permissions.
An autonomous agent works through this systematically.
It checks the identity in Azure AD and the device compliance in Intune.
It looks at the sharing permissions in SharePoint and checks for conditional access policies.
Then it correlates all that data to build a hypothesis.
This is where agents become force multipliers.
A human doing this investigation might take an hour to click through all those screens.
An agent does it in seconds because it can query all these systems at once without getting
distracted.
But we have to talk about security.
If permissions must be scoped to the specific task, not the whole tenant, this goes back
to our talk about just-in-time identities.
An agent that resets passwords doesn't need to read your email.
An agent that checks device compliance doesn't need to write to groups.
Each agent gets only the graph permissions it actually needs to do the job.
The policy engine enforces this.
When an agent requests a token for a task, that token only has the permissions required
for that one moment.
Graph gives agents access to the entire enterprise data fabric in a structured way, but that
access is always controlled and auditable.
The agent sees what it needs to see and nothing more.
That is how you scale these operations safely.
Headless authentication and identity governance.
Headless means the agent runs without any user interaction at all.
There is no human sitting at a keyboard and there is no browser window popping up to
ask for MFA.
The agent has to prove who it is and get access to do its work, but it does all of that
automatically in the background, without anyone getting involved.
This is fundamentally different from how you probably use Microsoft 365 today.
When you open Outlook, you authenticate yourself.
The browser might ask for your password or your Authenticator app and you respond to get
logged in.
That is called delegated authentication.
It uses your identity, your credentials and your permissions because you are the actor
and the system is responding to you.
Agents cannot work that way.
An agent that needed to prompt for credentials would just hang there waiting forever.
It cannot interact with an MFA app and it cannot click approval buttons, so it has to
authenticate in a way that is fully automated.
This is app-only authentication.
The agent has a credential, which is usually a certificate or a client secret stored somewhere
secure and it uses that to request access tokens from Azure AD with no human involved.
But this is where 2026 changes the model entirely.
The traditional approach is to issue one credential to the service principle, store it somewhere,
and use it for every single task.
The agent runs and authenticates with that static credential to get a token that is valid
for an hour or more.
It uses that same token for everything it does.
If someone needs to change what the agent can do, they have to update the credential storage,
the app registration and redeploy the whole thing.
The shift we are seeing now is to what just in time token issuance, instead of one permanent
credential that the agent uses to get its own tokens, the agent requests a token from
a policy engine whenever it needs to do work.
The policy engine looks at what the agent is trying to do and checks a specific policy
to decide if this agent should be allowed to perform this specific task right now.
If the answer is yes, it issues a token scope exactly to that one task.
That token might be valid for only 60 seconds.
It can only be used to reset one user's password or read one mailbox or update one device's
configuration and then it expires.
This is the big architectural shift.
We are moving from a permanent identity credential that unlocks everything to time limited, task-specific
tokens issued by a policy engine.
The policy engine is the new component in the setup.
It is an external service that understands your organization's risk posture, your security
policies, and your operational context.
When an agent wants to do something, it goes to the policy engine and the engine starts
asking questions.
Does this task allowed, has this agent done this task before successfully?
Is there unusual activity happening?
Only if the answers to all these questions support the request, does the policy engine issue
a token?
Managed identity is another piece of this puzzle.
If your agent runs inside Azure, like in a function app or a container, that agent can
use Azure's managed identity system.
The agent does not store any credentials at all.
It simply proves that it is running in that specific Azure resource and Azure issues
it a token automatically.
You configure the managed identity with exactly the permissions it needs.
And when the credentials need to rotate, Azure handles that in the background.
You are not manually rotating secrets or storing credentials in code because the system
handles identity automatically.
But there is one more layer to consider.
Continuous access evaluation or CAE is how Microsoft revokes access immediately if something
changes.
Normally, a token issued at 2pm stays valid until 3pm, even if something bad happens at
2.30pm.
CAE changes that logic.
If a risk signal triggers during your tokens lifetime, like an impossible travel alert
or a policy violation, CAE revokes your token immediately.
Your access stops within seconds.
For autonomous agents, this is absolutely essential.
An agent that has been compromised or starts acting abnormally should lose its access immediately
rather than waiting for the next token refresh.
The continuous evaluation of risk means the policy engine can revoke a token and prevent
further damage before the compromised agent even realises what is happening.
This is why autonomous agents actually need tighter identity boundaries than humans do.
Humans have judgment.
You can see a prompt that looks suspicious and choose to ignore it, but agents do not have
that ability.
An agent just follows its logic, so the system has to make sure the agent's identity gives
it access to do exactly what it is supposed to do and nothing else.
Just in time tokens, continuous evaluation and immediate revocation are the pillars of
an identity architecture that supports secure operation at scale.
Rapping PowerShell as semantic kernel plugins.
Now let's talk about the mechanics of actually connecting PowerShell to semantic kernel.
This is the moment where the reasoning layer meets the execution layer and it is
actually much simpler than you might expect.
The process follows three basic steps.
First, you identify which PowerShell CMD lets your agent actually needs to function.
You are not wrapping every command in the library because you want to be deliberate.
If your agent handles password resets, you would need "GetMGuser" to find the user and
reset "MGuser Authentication Method" passed by order to change the password.
You would also need sent "MGuserMail" to notify them of the change.
That is your CMDL at list which might only be a dozen functions total.
Did you create a .NET class that wraps these CMDellets?
This is straightforward, C# code where each method in the class calls one or more PowerShell
CMDL.
A method named FindUser by email calls "GetMGuser" and a method named ResetUserParsword
calls the ResetCemDL.
Each method does one thing and performs one clear action.
Third, you decorate these methods with two specific attributes.
The kernel function attribute tells semantic kernel that this method is a "Calible" tool.
While the description attribute contains a plain English explanation of what the function
does.
It is the critical part that most people underestimate.
Here is why those descriptions matter so much.
When you register your plugin with the kernel, the kernel does not actually execute your
code yet.
It reads those descriptions and builds an internal model of what is available.
It notes that there is a function called ResetUserParsword that needs a user ID and a temporary
password.
The kernel communicates this to the LLM and the model reads these descriptions to learn
how to use them.
Now when you ask the agent to solve a problem, the model has all this information ready.
It knows what each function does and understands when each function is relevant to the task
at hand.
It reasons about whether to use that function based on the goal.
This is why a description like ResetUserParsword is completely different from something vague
like "Modify's user account settings".
The first one tells the model exactly what the function is for while the second one leaves
the model guessing.
You should also document the side effects and the prerequisites.
If your Reset function requires the user to have a mailbox, you need to say that.
If it sends a notification automatically or logs the action to an audit system, that is
important context for the agent.
The model needs to understand not just what the function does, but what happens as a result
of calling it.
If it is a high-risk operation, you should say that explicitly.
A good description for a password Reset function might look like this.
It resets a user's password to a temporary value and sends that new password to their
registered email address.
It requires that the user exists in Azure AD and has an active mailbox.
It also triggers an audit log entry and returns true if successful or false if the mailbox
is unreachable.
That is specific.
The model reads that and knows exactly what the function does, what could go wrong and
what the result will be.
When the model encounters a ticket about someone unable to access their account, it sees
this function description and realises it is the right tool for the job.
The kernel passes these descriptions and uses them to teach the model how to reason about
your tools.
It is not magic, but rather a form of structured learning.
The model studies the descriptions, the parameters and the expected outputs to learn patterns
about when each tool is actually valuable.
This is why good descriptions are the difference between an agent that makes smart decisions
and one that makes random ones.
An agent that understands the purpose and the implications of each tool can chain them together
intelligently.
An agent given vague descriptions will just stumble around trying different functions at
random until something works.
So when you wrap your PowerShell CMDlets, you should treat the descriptions like documentation
written specifically for the AI.
Be explicit and be specific.
Describe not just what the function does, but why someone would want to use it and what
the final result actually means.
This is how static PowerShell CMDs finally become intelligent, reasoning agents.
Designing function signatures for reasoning.
Now that you understand the description layer, we need to talk about the actual shape
of your functions.
Descriptions are known aren't enough to guide an agent because the structure of your functions
how you define parameters and what you return all dictate how well an LLM can reason about
them.
The core principle here is single-purpose design.
One function should do exactly one thing, which means one clear and specific action.
This isn't just a suggestion for clean code, it's how agents think.
When you build functions for an agent to call, every parameter you add increases the cognitive
load on the model.
Every possible return state creates a new layer of ambiguity that the agent has to navigate.
The narrower and more focused your function is, the clearer the model's decision making
becomes.
A function that takes 15 parameters with 10 optional branches is a puzzle that forces
the model to reason about parameter combinations that might not even make sense together.
On the other hand, a function that takes two required parameters and returns one simple result
is transparent.
So the model understands exactly what happens when it triggers that call.
Let's look at a concrete example of bad design.
You might write a function that takes a JSON blob as input to handle multiple tasks.
This JSON could contain a user ID to reset a password, a group ID to add a member, or even
a device ID to trigger compliance checks.
The function reads the JSON, figures out what action to perform, and then executes it.
While this saves you from code duplication and feels efficient to write, it's actually terrible
for agent reasoning.
The model sees this function and starts guessing what should go in the JSON or what might
come out of it.
Because the input is ambiguous, the model might construct a JSON object that doesn't make
sense for the operation it's trying to perform.
It might pass fields that the function doesn't use, or it might misrequire fields entirely.
You've essentially made the model's job harder by trying to make your own code simpler.
Good design separates these into three distinct functions.
One function finds a user by email, another resets that uses password, and a third notifies
them of the change.
Each function has a clear purpose and takes only the parameters it actually needs to function.
This ensures each function returns exactly what the model needs to know to decide what
to do next.
Parameters should always be explicit and strongly typed.
Don't accept generic strings that could mean multiple things.
If you need a user ID, you should accept a GUID, and if you need a temporary password,
you should accept a secure string.
If you need a mailbox address, you should accept an email address and validate the format.
Strong typing prevents the model from passing invalid data, and it tells the model exactly
what kind of data the function expects.
The model reasons better with narrow, well-defined tools because it doesn't have to figure
out whether its input is valid.
It doesn't have to guess what the function will do because the contract is clear.
Return values should also be structured.
Don't just return a string, return a JSON object instead.
If you're checking whether a user exists, return a structured object like Psa, Tsa, Tsa,
Tsa exists, true, user ID, ABC1023 on display name, John Smith, is rather than a simple true
or false.
If you're attempting a password reset, return, success, true, temporary, password, null
notification, send, true, errors.
Instead of just the word success, this matters because the agent needs to pass the result
and decide on the next move.
If you return a plain string, the model has to interpret what that string means, which
leads to questions about whether it's an error or a success.
If you return a structured object with explicit fields for success, status and errors encountered,
the model knows exactly what happened.
It can reason clearly about what to do next.
Structured returns also make you logging much easier.
You can serialize the return object directly to create an audit trail that shows exactly
what each function returned.
This allows you to analyze patterns in agent behavior because the data remains consistent
across every execution.
Think about function design as teaching the model a new language.
Each function is a word, the signature is the definition of that word, and the parameters
are what the word needs to work.
Return values are what the word produces.
If your words are vague and overloaded, the sentences won't make sense, but if your words
are precise and single purpose, thoughts flow clearly.
An agent that calls a dozen narrow well-defined functions will reason circles around an agent
that calls three kitchen sink functions.
Every time you remove complexity from a function, you make the agent smarter.
The plan execute refined loop.
This is where everything changes.
Up until now, we've been talking about the building blocks like the reasoning engine,
the data access, and the function design.
Now we're going to talk about the actual workflow that ties it all together, and it's
radically different from how scripts work.
Standard scripts work in a linear deterministic way.
They go from step one to step two to step three, and then they're done.
They execute a predetermined sequence.
And if an unexpected condition occurs, they either handle it with predefined logic or
they fail.
There's no adaptation and no recovery path except for what you explicitly programmed into
the code.
It works differently by following a cycle of thinking, acting, evaluating, and adjusting.
The agent reads the ticket and builds a plan, then it decides what steps are needed based
on the current context.
After it executes those steps, it looks at what happened to see if the plan worked.
If the goal wasn't achieved, the agent asks what went wrong and what that means for the
next attempt.
Then it goes back to planning and tries a different approach.
This is the core agent workflow, plan, execute, and refine.
The key insight is that all three stages happen inside the agent's reasoning loop.
The agent isn't just following a script you wrote, it's building a mental model of the
problem, and updating that model based on what it learned.
Step one is the planning phase.
The agent reads the incoming ticket and extracts the key information to understand what the
user is trying to accomplish.
It looks at its available tools, which are all those power shell functions you wrapped and
builds a sequence of actions.
But it doesn't execute yet because it needs to think first.
It reasons about the order, asking if it makes sense to check if the user exists before
resetting their password.
The agent realizes it shouldn't notify the user before confirming the reset succeeded,
so it builds a plan based on that logic.
Step two is execution.
Now the agent actually calls those power shell functions in the sequence it planned.
It passes the right parameters and gets back structured results.
Step three is refinement, and this is where it gets interesting.
The agent looks at what came back to see if the first function succeeded.
If it did, the agent confirms that and moves to the next step in the plan.
But what if the function returned, exists, false?
It wasn't in the plan, but the agent doesn't panic.
It recalculates.
If the user doesn't exist, the agent might assume the email address in the ticket is wrong
or contains a typo.
It might decide to search for users with a similar name, or it might ask the original request
of a clarification.
The plan adapts based on what actually happened in the environment.
This is not linear execution, it's adaptive reasoning.
This matters because in real enterprise work, things rarely go exactly as planned.
A user might have a weird permission state you never anticipated, or a power shell function
might return an error you didn't write logic to handle.
Sometimes a prerequisite isn't met or an API call times out.
Scripts fail on these issues, but an agent adapts.
Here's a concrete example.
An agent receives a ticket saying, "I can't log into my laptop."
The agent plans the diagnosis by getting the device from Azure AD,
checking compliance, and verifying the user's license.
The plan is reasonable.
It executes and calls the device "lookup function" which works perfectly.
Then it calls the compliance check, but the device is non-compliant.
The plan was based on the assumption that the device was compliant
and that assumption just broke.
The agent recalculates.
If the device is non-compliant, the issue might not be about licensing,
it might be that conditional access is blocking the login.
The agent loops back to planning and creates a new plan to check the conditional access policies.
It executes the new plan and evaluates the result success.
The agent found the specific policy that's blocking the login.
Now it needs to decide what to do.
It probably shouldn't fix this autonomously because changing a conditional access policy is high risk.
This is a decision point where the agent needs human judgment,
so it builds a structured proposal instead of executing a fix.
It tells an IT manager what the issue is and asks if it should apply the fix.
The manager approves it in Teams and then the agent executes.
This is the plan "execute refine loop in action".
The agent isn't following a predetermined script.
It's building a mental model and adjusting based on what it learns.
When things go sideways, it doesn't fail. It adapts.
Orca-strating multi-step workflows.
Now we need to look at what actually makes this useful for real work,
because the reality is that IT tickets are almost never simple.
They don't just show up as a clean request to reset a password.
Instead, they arrive as a messy tangle of interconnected problems
that touch five different systems at once.
Take a common ticket like user can't access Teams.
On the surface, that sounds like a single problem,
but in reality, it's a dozen.
To figure out what's actually happening,
you have to check if the user exists in Azure AD,
verify their Teams license,
and see if the service is even enabled for the company.
Then you have to look at their device compliance,
check for network blocks,
investigate mailbox sync states,
and confirm they're in the right groups.
That isn't a two-step process. It's a 10-step investigation,
where the order of operations matters.
You can't check for a license if you haven't confirmed the user exists yet,
and you can't verify device compliance
if you don't even know which hardware they're using.
Some of these checks are prerequisites,
some are fallbacks,
and others only matter if the first three things fail.
A traditional script tries to hard-code this entire sequence
from step one to step 10.
If anything goes sideways,
the script relies on conditional logic
that you had to anticipate months ago,
but you can't predict everything.
Maybe a serial number is missing from the ticket,
or an API call times out,
or the mailbox is in a weird state
that your code wasn't built to handle.
When that happens, the script either hits a dead end,
or it just fails.
An agent doesn't follow a hard-coded map.
It reads the ticket,
and decides what needs to happen next based on the evidence.
It understands that the first logical move
is to confirm the user exists,
so it makes that decision and executes it.
When the result comes back,
that data either confirms or destroys the next assumption,
and the agent adjusts its plan accordingly.
Watch how this workflow actually unfolds.
The agent reads a ticket from JSmith@Company,
comes saying they can't get into teams.
The agent plans to check the user's state and the service state,
so it calls the lookup function first.
The result shows the user exists with ID,
ABC123.
Next, it checks the license and sees its active.
It checks if the service is enabled,
and the answer is yes.
Then it hits a snag.
It needs to check the device state,
but the ticket doesn't say which device is the problem.
The agent sees two registered devices
and realizes it can't move forward
without knowing which one is failing.
It leaves a note for the human asking for clarification,
but it doesn't just stop there.
It keeps digging and finds a conditional access policy
that's currently blocking all unmanaged devices.
Now the agent has the full picture.
The likely culprit is that one of the user's devices
isn't managed,
and the security policy is doing its job.
The agent decides on a fix,
like enrolling the device or creating an exception,
but it knows these are high-risk moves.
It won't act autonomously here.
Instead, it builds a structured proposal for an IT manager.
The manager gets a notification in teams with a clear breakdown.
The user is blocked on an unmanaged device.
And here are the three ways to fix it.
The manager clicks "Approve for device enrollment"
and the agent handles the rest.
It runs the enrollment, verifies the fix,
and tells the user they're good to go.
This entire loop, the diagnosis,
the adaptation, the escalation,
and the final execution
is what a multi-step workflow looks like.
The agent decided the sequence
and adapted when it hit a gap in the data.
It didn't break just because a condition was unexpected.
It reasoned its way through.
A hard-coded script fails here
because the person writing it couldn't predict every single variable.
You can only code for the problems you've already thought of.
An agent reasons about what matters based on the live ticket,
deciding what to query,
and in what order based on what it learns at every step.
This is why agents handle variety
without needing a script rewrite every week.
The human in the loop isn't a feature you bolt on later.
It's built into the logic.
The agent knows exactly when it's moving from looking at data
to changing things.
And it stops to ask for permission before it crosses that line.
Error handling and fallback strategies.
We have to be honest about scripts.
They are incredibly brittle.
The moment an error happens,
the whole thing stops,
an exception is thrown,
and the process dies.
Then a human has to step in to find the bug,
edit the code, test it,
and redeploy the whole thing.
That recovery cycle is slow, manual, and expensive.
Agents have to work differently.
When a problem pops up,
they shouldn't just quit and report a failure.
They need to recover, try a new path,
and stay resilient.
The difference is in the logic.
A script says,
"Do this and if it fails, stop."
An agent says, "Try this."
And if it fails, let's look at why and try the next best thing.
Let's look at a password reset.
The agent calls the reset function,
but the system returns an error saying the user wasn't found.
A standard script would just stop and escalate to a human.
The agent, however, reads that error
and thinks about what it actually means.
Maybe the user exists in a different directory,
or perhaps their name was misspelled in the ticket.
Instead of quitting,
the agent tries a different angle.
It might search by a partial name,
a phone number,
or look for recently updated accounts.
It can loop through these fallback strategies
until it finds a match that works.
The secret is that the agent has to be able to classify
what kind of error it's looking at.
Not all errors are created equal.
A temporary error might be a service throttling your requests,
which just means you need to wait 30 seconds and try again.
A permanent error is something like a deleted account
where no amount of retrying is going to help.
Then you have recoverable errors
like a missing user that might be found elsewhere
and fatal errors like a lack of permissions.
An agent that understands these categories
can handle them with some intelligence.
If it's temporary,
it uses an exponential back-off to retry.
If it's permanent, it skips to the next logical step.
If it's recoverable, it tries a different tool.
And if it's truly fatal,
it stops and asks for help.
In practice, this looks like an agent handling an access ticket.
It tries the email address and gets nothing.
That's a failure for that specific tool.
But the agent knows it's a recoverable situation.
It tries searching by the display name,
finds the right person, and keeps moving.
If every single search method fails,
the agent finally stops and tells the human
that the user doesn't exist anywhere in the system.
When the human gets that message,
they have all the context they need to make a fast call.
They can see it's a typo or a new hire
that hasn't been onboarded yet.
Because the agent did the legwork,
the human isn't starting from scratch.
The goal here is graceful degradation.
If the agent can't solve the whole ticket on its own,
it doesn't just crash.
It hands the problem to a human
and explains exactly how far it got,
what it tried, and what finally blocked it.
The human isn't wasting time on diagnostics anymore.
They're just the tiebreaker.
To make this work,
you have to build explicit error classification
into your functions.
You can't just return a success or fail flag.
You need to provide enough data,
so the agent can decide if there's a recovery path
or if it's time to escalate.
Resilient systems are designed for failure.
You have to expect that things will break
and give your agent the tools to try a plan B.
By letting the agent navigate these small hurdles on its own,
you keep the workflow moving
instead of letting every minor error turn into a manual task
for your team.
Human in the loop approval gates,
you need to draw a very clear line.
On one side, you have things an agent can decide on its own.
On the other, you have things that require a human judgment call.
Getting this boundary right is the difference
between a helpful tool and one that goes rogue.
Not every decision should be autonomous.
Some actions are low risk
because they don't actually change anything.
If an agent wants to pull a list of users,
check forwarding rules on a mailbox
or look at device compliance data, that's safe.
It can do those things without asking for permission,
but other actions are high risk.
Deleting a user account,
resetting MFA or changing access permissions
can break someone's entire workday.
These actions change the state of your environment
and could even create a security hole.
Because of that, you need a human to say yes
before the agent pulls the trigger.
The best practice for 2026 is simple.
Agents propose and humans approve.
The agent does all the heavy lifting during the diagnostic phase
that gathers the context, looks at the situation,
and reaches a conclusion about what needs to happen,
but it doesn't execute high risk changes on its own.
Instead, it creates a structured proposal
that explains what it found, what it wants to do,
and why it thinks that's the right move.
Then it waits.
The word "structured" is the most important part here.
The proposal isn't just a big block of text that's hard to read.
It's a specific object with clear fields like the proposed action,
the reason, the risk level, and the potential impact.
It shows which checks passed and if there are any blockers.
By laying it out this way, a human can review the facts
in seconds and make a fast decision.
Think about how this looks inside Microsoft Teams.
When an agent hits a situation that needs a human eye,
it builds that proposal.
But instead of sending a message, it sends an adaptive card.
The card is clean and easy to scan.
You see the username, the status, the proposed action, and the impact.
It tells you if the user will be notified
or if an audit log will be triggered.
At the bottom, you have three simple buttons.
Approve, reject, or ask me more questions.
A human gets the notification and looks at the card.
It takes maybe 10 seconds to review the details.
If they hit "approved" the agent goes to work,
if they reject it, the agent takes that feedback
and tries a different path.
If they have questions, the agent can provide the diagnostic data
it used to reach that conclusion.
The human is making an informed choice, not a guest.
This is what we call "risk-based" tearing.
Low-risk actions stay autonomous,
but medium-risk tasks might need a team lead to sign off.
High-risk actions like deleting a user
should require a manager or a security officer.
Your policy layer defines exactly what fits into each tier.
This gives humans control over the decisions that actually matter
while letting the agent's handle the small stuff.
The beauty of this model is that it scales.
One person approving decisions won't become a bottleneck
if most of the work doesn't need approval.
The agent handles the easy stuff,
like running diagnostics and fixing low-risk queries.
Humans are no longer stuck doing the busy work or running routine tasks.
They are making the calls that matter.
Their time is spent on actual decision-making
rather than the administrative work that leads up to it.
In this setup, the agent is a decision support system.
It isn't there to replace human judgment,
but to augment it.
It gathers all the relevant info,
analyzes it,
and hands over a clear recommendation.
The human still brings their expertise
and organizational knowledge to the table.
The difference is that they're making that choice with complete information
instead of operating in the dark.
This is also how you build trust.
Organizations don't trust machines
that make irreversible changes without asking first.
But they do trust systems that propose a plan,
explain the logic and wait for a green light.
You aren't handing over the keys to the kingdom.
You're just letting the machine do the analytical work
so you can focus on the final decision.
The agent becomes a collaborator rather than a replacement worker.
It does what is best at,
which is rapid analysis and calling APIs.
You do what your best at,
which is weighing risk and understanding nuance.
When you work together like this,
you move much faster than either of you could alone.
Case study.
Autonomous ticket resolution.
Let's look at a real scenario to see how this works.
This is the step-by-step process of an autonomous agent
handling a ticket from start to finish.
A user sends in a ticket at 9.47 am.
They say they can't log into their laptop
because of a compliance error
and they need it fixed immediately.
There's no serial number, no error code,
and no extra context.
It's just a frustrated message.
The agent picks up the ticket the second it arrives.
The first thing it does is pull the email from the metadata.
It knows the device is involved,
but it doesn't know which one yet.
The agent has a starting point,
but it needs to go find the missing data.
It starts the diagnosis by querying Azure AD to find the user.
The account is active and there are no obvious issues there.
Next, it checks in tune to see what devices are registered to that person.
It finds two a laptop and a phone.
Since the ticket mentioned a laptop,
the agent pulls the compliance status for both.
It sees that the phone is fine,
but the laptop is marked as non-compliant.
The laptop hasn't checked in for three days.
The operating system is on an old build
and the current policy requires a much newer version.
Now the agent has the answer.
The device is blocked by a conditional access policy
because the OS is outdated.
But the agent can't just force an update.
That's a high-risk move that could fail or interrupt the user's work.
The agent doesn't have the authority to make that call on its own.
Instead of stopping, the agent builds a proposal.
It organizes everything it learned,
including the device ID,
the current build,
and the specific policy that's blocking access.
It knows the fix is to update the OS to the latest version.
It could also suggest replacing the device if it were too old,
but an update is the fastest way forward.
The agent sends this proposal to the IT manager on duty.
It doesn't send an email that will get buried.
It sends a team's adaptive card that pops up as a notification.
The manager sees the user impact,
the technical details,
and the risk level all in one place.
The manager reads the card in about 20 seconds.
They understand the requirement
and they see that the fix makes sense.
They hit a proof.
The moment that button is pressed,
the agent moves into the execution phase.
This is where delegation is key.
The agent might not push the update directly,
but it can trigger the workflow in your management system.
It moves the device into an update group and sends a note to the user.
It tells them a security update is ready
and asks them to save their work and restart.
It can even alert the manager once the restart happens,
so they can keep an eye on it.
The user gets the notification on their phone.
They probably expected this to take all day,
but now they have a clear instruction to just restart their machine.
They reboot the update runs for about 15 minutes,
and the device comes back online with the correct OS build.
The compliance start as flips to green almost immediately.
The agent keeps watching that status.
As soon as the device shows as compliant,
it knows the problem is solved.
It checks Azure AD one last time to confirm the block is gone.
Then it sends a final message to the user,
letting them know they can log back in.
It closes the ticket with a full summary of what happened
and how it was fixed.
The total time from the first message
to the final resolution was 15 minutes.
If a human had handled this manually,
they would have spent an hour just going back and forth with the user.
They would have had to remote in, check in tune,
and manually walk the user through the update.
That's two or three hours of wasted time.
The agent didn't take the human's job.
The manager still made the final call.
The agent just did the boring diagnostic work
and handled the execution once it had permission.
The human handled the judgment and the agent handled the speed.
This is the force multiplier effect in action.
The agent takes care of the complexity and the data analysis.
The human takes care of the authorization.
The result is a level of speed and accuracy
that you just can't get when you're working alone.
Scaling to enterprise operations.
One agent resolving one ticket is a great proof of concept,
but in a real organization,
you don't deal with one ticket a day.
You deal with hundreds or thousands.
This is where the model breaks.
We have to stop talking about a single agent
and start talking about a fleet of agents running in parallel.
The architecture changes fundamentally when you move to this level.
Instead of one agent and one orchestrator,
you have a pool of agents, a work dispatcher,
and a monitoring system that watches everything.
Think of the dispatcher as the nervous system of the entire operation.
Tickets come in and get routed to the first available agent
with the right skill set, which keeps the flow moving.
An identity agent handles user account issues,
while an infrastructure agent manages device compliance
and an application agent deals with licensing.
The dispatcher looks at the incoming request,
categorizes the problem,
and sends it to the right specialist.
If every identity agent is busy,
the ticket sits in a queue until someone finishes their current task
and picks up the next one.
This is load balancing,
but it is much smarter than just assigning tasks in a circle.
Each agent tracks its own performance metrics in real time,
measuring success rates, resolution times,
and how often it has to escalate a problem.
The dispatcher uses this data to root work intelligently.
If one agent consistently results password resets in eight minutes
while another takes 18,
the dispatcher roots more of those specific tasks to the faster agent.
This isn't a permanent change because agents improve or decline over time,
so the system adjusts dynamically based on current capability.
To make this work, your infrastructure has to be cloud native.
You aren't running fixed agents on fixed servers anymore.
Instead, you are spinning up agents as the load increases
and tearing them down when things get quiet.
This is orchestration at a different level
where Kubernetes handles the container life cycle
while the dispatcher manages the actual flow of work.
The monitoring layer watches both the hardware
and the agents themselves to ensure everything stays healthy.
Monitoring is the most critical piece of this puzzle.
A central dashboard shows you exactly how many tickets are in the queue,
how many are being worked on, and how many were resolved in the last hour.
It tracks agent health and availability constantly.
If an agent starts crashing repeatedly,
the system pulls it from the pool and flags the issue for the operations team.
It also reveals escalation patterns.
If a certain type of ticket is being kicked back to humans more than expected,
it tells you that something is wrong with the training or the classification.
The data shows you whether the problem is outside the agent's scope
or if it just needs better documentation.
This is where feedback loops finally start to matter.
Every ticket and agent resolves
in every decision it makes becomes part of a massive pool of training data.
Your system is actually learning.
Some organizations feed this data directly back into the model
while others use it for periodic retraining,
but the result is the same.
The agent that used to take eight minutes per ticket gets faster
and the escalation rate on difficult issues drops
as the agent learns from human corrections.
Load balancing also gives you the power to handle massive traffic spikes.
On a typical Monday morning, you might get a wave of tickets
because everyone had issues over the weekend,
but you can just spin up more agents to clear the queue.
By Wednesday evening, when things slow down,
you scale back and stop paying for compute you don't need.
Parallel execution changes your throughput completely
and if you had one script running one ticket at a time,
you would be limited by the clock
and a hundred tickets would take hours to finish
with a fleet running in parallel
though same hundred tickets might be done in 30 minutes.
The time it takes to resolve an individual ticket doesn't change much
but your total capacity multiplies.
This is the shift from running a script to running an operation.
You aren't just launching a PowerShell command anymore.
You are operating a complex system of agents, orchestration and governance.
The agents are just the workers,
while everything else is the machinery that makes them reliable at scale.
This requires a real infrastructure shift.
You need a message queue for work distribution
and deep observability through logging and metrics.
You also need policy engines to enforce rules
and human approval workflows to keep things safe.
Most importantly, you need an audit trail for every single action.
It also forces you to change how you think about governance.
You have to decide who approves what,
how the escalation path works and what happens if an agent makes a mistake
or gets attacked.
These are operational questions, not development ones.
Moving from a pilot to full production isn't about writing better code.
It's about building the system that the agents live inside.
Governance and guardrails.
Autonomous agents running at scale need boundaries that are clear,
enforced and unchangeable.
Without these limits, you are just giving away access
and hoping for the best.
The governance layer is what turns an agent from a wildcard
into a predictable reliable system.
Think about the level of access you are actually granting here.
You have agents that can query sensitive user data,
reset passwords, modify permissions,
and even send emails on behalf of the entire company.
Any one of those powers is a massive risk
if it's used in the wrong context.
Putting all of them together in an agent without guardrails
is a guaranteed way to end up explaining
a massive security breach to your board.
The policy layer is what defines these guardrails.
It is a declarative model that states exactly what an agent can do,
which data it can touch and under what specific conditions it can act.
This isn't buried in a block of code or a forgotten configuration file.
It is a living document that the governance team controls
and auditors can review at any time
without needing to redeploy the agents.
In practice, this looks very specific.
You might define a policy that says
a password reset agent can only help users in the HR department
if it gets approval from an HR manager first.
You can even add a rule that it only works
if the user hasn't asked for a reset in the last 30 days.
Because the rules are measurable and specific,
the agent checks them every single time it tries to act.
If the conditions aren't met, the agent stops
and either refuses the request or escalates it to a human.
Policies can be incredibly granular.
You don't just say an agent can read all user data,
you say it can read six specific fields for users
in the sales department during business hours.
The access is scoped to exactly what is needed for the task
and nothing more.
These policies also determine when a human needs to step in.
A simple read-only query might not need any oversight,
but modifying an email address or deleting a device certainly does.
Your policy layer maps every possible action
to a specific approval tier.
This means the agent knows whether it needs a yes
from a human before it even attempts to perform the action.
The audit trail is the necessary partner to these policies.
Every single move an agent makes is logged,
including what triggered the action,
which policy allowed it,
and what the final outcome was.
If something goes wrong,
you can rewind the tape to see exactly what happened
and who approved it.
This audit trail serves several purposes at once.
Regulators need to see that you are tracking
who accessed what and when,
but it's also vital for troubleshooting.
If an agent starts behaving strangely,
you can replay the logs to see exactly
where its reasoning went off the rails.
It also provides the feedback you need to improve the system
by showing you where policies are too tight
or where agents are making repeated mistakes.
Compliance requirements are baked directly into this layer.
If you have rules about data classification,
the agent has to respect them.
It won't export confidential files or keep personal data
longer than the retention window allows.
The policy isn't just a suggestion.
It is a hard constraint that the agent cannot break.
The shift happening here is fundamental
because you are moving from trusting the script
to trusting the policy.
With old school scripts,
you had to trust that the author wrote secure code,
which meant you had to audit the code itself before it ran.
If something broke, the script was the problem.
With agents, you trust that the policy is correct
and the enforcement is airtight.
The agent is just a worker following orders.
If something goes wrong, it means the policy failed,
not the agent.
This also changes how you handle updates.
With traditional scripts,
every update is terrifying because a small error
could break everything.
With agents, you don't change the code to change the behavior.
You just update the policy.
If you want an agent to be more autonomous,
you adjust the governance layer.
If you need to restrict it, you do the same.
The capability of the agent stays the same in the code,
but its permissions change in the governance.
Governance is actually what enables you to scale.
It isn't a hurdle or a constraint.
It's the foundation that lets you spin up more agents
with total confidence because the boundaries are clear
and the audit is complete.
You don't have to worry about what might go wrong.
You have a perfect record of everything that happens
and a system that ensures it stays within the lines.
Security considerations for autonomous agents.
The moment you give an agent the power to execute commands,
you have created a high-value target.
Unlike a human employee, an agent never gets tired,
and it won't stop to question a suspicious instruction.
It simply follows its logic to the end.
This creates a massive risk if the agent is compromised
or if someone manages to inject malicious instructions
into its context.
You have to ask yourself,
what is the blast radius if this goes wrong?
You need a real-world threat model
based on what actually matters in your specific environment.
The danger isn't just that an agent might malfunction.
The real threat is that someone outside your organization
or even a malicious insider turns that agent into a weapon.
Isolation is your first line of defense here.
Agents shouldn't run on the same infrastructure as your critical systems.
Instead, they need to live in containers,
Kubernetes pods, or isolated network segments.
If an agent is compromised,
that isolation keeps the damage contained.
It prevents the attacker from immediately pivoting
to your domain controllers or email servers.
Think of it as a sandbox.
This is a major shift from how we usually run scripts.
A script running on a server with admin rights
can reach your entire environment,
but an agent in a properly configured container
can only see what you explicitly allow through network policies.
Credential handling has to change as well.
Traditional scripts usually store credentials
in an encrypted vault or a config file.
The script authenticates once,
gets it token,
and uses that token for as long as it lives.
If that credential leaks,
it stays valid for a long time.
An agent should never store credentials like that.
It shouldn't have long-lived tokens at all.
Every time it needs to perform a task,
it should request a new credential from an identity broker
that is only valid for that specific job.
Because these credentials expire in minutes,
they are worthless to a thief almost immediately after they are issued.
This ties back to headless authentication in CAE,
but the security angle is much more aggressive.
It isn't just about checking a compliance box.
It's about ensuring that even if someone dumps the agent's memory
or reads its logs,
there are no usable credentials sitting there.
If that agent starts behaving strangely
by making unauthorized API calls or accessing data it doesn't need,
the policy engine can revoke its access instantly.
Behavioral analytics serves as your early warning system.
If an agent that usually processes password resets
suddenly starts scanning every user in the directory,
that is a major signal.
If an agent that typically runs during business hours
suddenly wakes up at 3am,
or if it jumps from 10 API calls to 1,000,
your monitoring system needs to flag it.
This is actually easier than traditional monitoring
because agent behavior is incredibly predictable.
You know exactly which commands it should run,
what data it needs,
and how long the process should take.
Any deviation from that baseline is a red flag
that likely indicates an attack.
While a script has broad boundaries
because humans might run it in different ways,
a production agent has a very narrow path.
Anything outside that path
deserves an immediate investigation.
The principle of least privilege
becomes much tighter with agents.
A human might need broad permissions
because their job requires flexibility
across different domains.
An agent only needs exactly what is required
for its one specific function.
A password reset agent has no business reading email servers
and a device provisioning agent doesn't need to see financial data.
You enforce this at the API level
so the agent can call a function,
but the function itself is restricted to specific objects.
This represents a profound shift in how we think about security.
With scripts, you focus on securing the code
by scanning for vulnerabilities and auditing changes.
It's a code security problem.
With agents, you are securing the identity and the context.
The code is actually secondary.
The real question is what this agent is authorized to do
right now in this exact moment
with this specific identity.
If that answer is tightly scoped
and constantly re-evaluated,
the agent stays secure even if the code has flaws.
Security architecture is moving away from the traditional perimeter.
We are moving toward a zero-trust model
where every single agent action is evaluated,
every identity is verified
and every behavior is monitored.
The agent doesn't get a free pass
just because it's software.
In fact, you should treat it with less trust
than a human user because it operates autonomously.
Your security team will find their roles changing too.
They won't just be auditing lines of code anymore.
Instead, they will be defining policies,
reviewing behavioral baselines
and managing the identity life cycle
for an entire fleet of agents.
They have to think about attack surfaces
that simply didn't exist a few years ago
which requires a completely different skill set,
measuring agent performance.
When you move from scripts to agents,
your measurement system has to change completely.
You can't rely on the old metrics
because you aren't evaluating the same type of work anymore.
With scripts, success was a binary outcome.
You check to see if it ran,
if it crashed or if the logs showed any errors.
These are mechanical measurements.
The script either finished its sequence or it didn't.
You measured things like runtime and error frequency.
And if the script finished without a crash,
you just assumed it worked.
The logic was hidden inside
so you couldn't see why it made certain decisions.
Agents are a different story.
A script might run perfectly
but still fail to solve the actual problem.
On the other hand, an agent that stops
and escalates a ticket to a human
might actually be making the smartest possible move.
Success isn't about the agent running smoothly.
It's about the agent achieving the final goal.
You should start by looking at your automation rate.
This is the percentage of tasks
that are fully resolved by the agent
without any human stepping in.
If you handle a thousand tickets a month
and your agents resolve 400 of them,
your automation rate is 40%.
This is your headline metric
because it shows exactly how much work the agents
are taking off your plate.
You should expect this number to climb
as you refine the agents
though it will never hit 100%.
Some problems will always be outside the agent's scope
but the trend will tell you
if you're moving in the right direction.
The escalation rate is the other side of that coin.
When an agent can't finish a task,
you need to know how often it escalates
versus how often it just fails.
A well-designed agent will escalate more than it fails.
Escalation means the agent tried,
realized it couldn't finish
and handed the ticket to a human
with all the necessary context.
Failure means it just crashed
or threw an error with no way forward.
You want to see low failure rates
and high escalation rates.
An agent that hands over a complete diagnostic report
to a human is much more valuable
than one that fails silently.
Approval time is another critical factor
because humans are often the bottleneck.
When an agent suggests a fix
that needs a sign off, how long does that take?
If your agents are fast,
but your humans take two days to review the work,
you've just traded one bottleneck for another.
You want these approvals happening
in minutes rather than hours.
This metric tells you if your workflow is actually efficient
or if it needs to be redesigned.
Quality metrics are harder to track,
but they are essential.
Accuracy asks if the agent did the right thing,
diagnose the problem correctly
and apply the proper fix.
You measure this by having a human expert sample agent
decisions to verify they were correct.
Over time, this builds a reliable quality score.
You also need to measure completeness.
Did the agent solve the whole problem?
Or did it stop after fixing just one part of a multi-step issue?
Then you have the business metrics.
Cost per resolution is the total cost of your compute power
and human approval time
divided by the number of tickets resolved.
This tells you if automation is actually saving you money.
If your agents end up costing more than your human staff,
your model is likely broken.
You also want to track the mean time to resolution or MTTR.
When agents are involved, the time from ticket submission
to closure should drop significantly.
Finally, check user satisfaction to see if people are actually
happier with the faster response times.
The shift here is moving from,
did the system work?
To, did the system solve the problem?
Scripts let you measure execution,
but agents require you to measure helpfulness.
This also changes your feedback loop.
With scripts, you look at logs to find bugs in the code.
With agents, you look at quality metrics
to see where the decision making went wrong
so you can retrain the model or update your policies.
You aren't just debugging code anymore.
You are improving the way the system thinks.
New observability practices are starting to emerge around this.
You need real-time dashboards that show these trends
and historical data to see if your improvements are actually sticking.
You need to break things down by category
so you can see if your agents are great at one task
but struggling with another.
You also need drill-down views
that let you inspect a specific ticket
to see exactly what the agent decided
and why it made that choice.
Measurement becomes a constant conversation
between you and your agent fleet.
The metrics will show you exactly where to focus your energy next.
If your automation rate is stuck at 30%,
you need to look at the 70% that is still escalating.
If your approval time is creeping up,
your process is becoming a bottleneck.
If the cost per resolution is climbing,
your agent might be over-engineered
or your infrastructure might be inefficient.
Without these specific metrics, you are flying blind.
You won't know if your agents are actually making things better
or if you're just enjoying the feeling of having things automated.
The roadmap to operationalization.
Moving an agent from a lab experiment to a production workhorse
requires a specific path.
The technology isn't actually the hard part
because you have already built the core logic.
The real challenge is shifting how your team works,
what they monitor, and how they build trust in the system.
You have to follow a roadmap with distinct phases
and if you try to skip them, it will cost you.
Phase one is the pilot.
You pick one narrow domain and one specific capability
like password resets and that is it.
You build a single agent that does one thing.
It only runs queries with read-only access to Azure AD and Intune
so there are no rights and no approvals yet.
When a user submits a ticket saying their password expired,
the agent reads the account status, confirms they exist,
and checks that they aren't locked out.
It resets the password and notifies the user
before closing the ticket.
This phase proves the fundamental concept
that an agent can interpret natural language
and execute a sequence of actions to solve a real problem.
You aren't doing anything fancy or using complex reasoning yet
but you are showing the team that the idea works
so they can gain confidence.
This pilot usually runs for four to eight weeks
while you measure success rates in error patterns.
This is where you discover the operational infrastructure
you are missing, like better logging or a plan
for updating agent behavior.
You might realize that approval workflows
are much harder than you thought
but these discoveries are exactly why you run a pilot.
You are learning what it takes to run the system at a low scale
where mistakes don't cause a massive collapse.
Phase two is expansion.
You add a second domain, perhaps access requests
or device provisioning, which means you now have two agents
running in parallel.
This is where scaling starts to matter
because you are adding complexity instead of just doing more of the same.
The orchestration layer now has to root tickets to the right agent
and your monitoring must track which agent handled which specific task.
You can start introducing low risk right operations here.
The access request agent might assign a user to a group
if the request is valid
but you still avoid high risk changes like deletions or MFA resets.
You only allow straightforward modifications
that you can easily undo if something goes wrong.
You also start introducing approval workflows
for medium risk decisions during this six to ten week period.
You are proving that multiple agents can coexist
and that the routing works without the approval system becoming a bottleneck.
This is when you start seeing patterns
in what the agents get right and where they struggle
and that feedback becomes the fuel for your retraining and policy adjustments.
Phase three is scale.
You have a fleet now
with five or six agents handling different domains
from a shared ticket queue.
The orchestrator distributes work based on capability
and availability.
And while high risk operations are finally in the mix
they all have strict approval gates.
This phase is about proving the system can handle real production volume.
You aren't testing 100 tickets a week anymore
but instead you are running hundreds every single day.
This is where your infrastructure scaling happens
and you find out if your Kubernetes setup can actually handle the load.
You will see which types of tickets the agents nail
and which ones cause them to stumble.
This phase typically runs for three or four months
as you ramp up the volume
and the business impact becomes visible.
Tickets that used to take two hours now take 15 minutes
which clears your backlog
and frees your IT staff from routine drudgery.
This is the moment you get the organizational buy-in
needed for the final stage.
Phase four is optimization.
Your agents are production grade
so now you focus on making them better.
You feed resolution data back into the model
so the agents can learn from human corrections.
You adjust policies based on the patterns you see
and optimize routing
so the right agent gets the right ticket more often.
You reduce approval times by refining
what actually needs human judgment
versus what the agent can decide on its own.
This phase is continuous because it isn't a checkpoint
but an ongoing operational mode.
You are constantly measuring ROI and tuning performance
while adding new domains as opportunities appear.
The entire journey from pilot to production
usually takes six to 12 months.
It isn't because the technology is slow
but because operationalization requires a high level of discipline.
You cannot skip phases or try to pilot everything at once.
You have to prove at each stage that the system works
that your team knows how to run it
and that the business impact justifies the next step.
The mindset shift moves from can we build this
and to how do we run this?
And that is where the real work happens.
The technology is the easy part.
What changes when agents are autonomous?
Everything changes the moment your agents start running
without permission gates.
Your operations transform not because the technology is different
but because the work distribution
and the organizational structure have to reorganize.
Think about your operational tempo.
Right now your IT team is reactive
because a problem happens, a user calls
and then someone diagnoses and fixes it.
This is a respond to crisis model
but with autonomous agents at scale, the game completely inverts.
Agents can detect that a device is drifting out of compliance
before the user even notices a problem.
They see patterns of failed logins from a specific location
and flag them for security
or they notice outdated applications across departments
and proactively push updates.
They watch your tenant health metrics constantly
and predict when you are going to hit a service limit.
This shift from reactive to proactive is preventive meaning
problems get solved before they ever become outages.
This changes the types of fires that end up on your desk.
Instead of spending your day fighting active incidents
you spend it reviewing what the agents prevented.
Your monitoring doesn't show you crisis dashboards anymore
but instead shows you early warnings
and the agents proposed fixes.
Instead of getting paged at midnight because something broke
you get an alert that something is about to break
and the agent is asking for approval to fix it ahead of time.
The organizational structure has to follow this shift right now.
You have a lot of people doing level one work
like ticket triage,
password resets and access requests.
These roles exist because you need human judgment to decide
where a ticket goes and what the best path forward is.
Autonomous agents eliminate that entire category of work.
You don't need as many junior technicians doing routine resolution
but the people you do have must be more skilled.
You need architects to design what agents can do
and policy experts to define the guardrails.
You need people who can read agent behavior analytics
to determine if an agent is making good decisions.
When an agent struggles in a specific domain
you need someone who can actually debug the workflow.
The skills conversation changes entirely.
You stop hiring people who are just good at following procedures
and start hiring people who can design procedures for agents to execute.
You stop training people on how to reset a password in exchange
and start training them on how to design an agent
that understands when a reset is the right answer.
You are moving from execution focused skills to design focused skills,
shifting from task specialists to system architects.
The cost structure inverts as well.
Right now you are paying salaries
and labor is your biggest operational expense.
As you move to autonomous agents
you are paying for compute, cloud infrastructure and API calls.
These are capital expenses, not labor expenses
and that matters because capital scales differently than people.
You can spin up more agents instantly
but you cannot hire a dozen good technicians overnight.
The constraint shifts from how many people you can hire
to what your cloud budget looks like
and whether your infrastructure can handle the throughput.
For some this is a dramatic cost reduction
while for others it is a cost shift
where you replace people with infrastructure.
Either way the economics are different.
The institutional knowledge problem gets solved and created at the same time.
Right now if your best technician leaves
you lose years of troubleshooting knowledge
and all the workarounds they've learned.
Their departure is painful
but with agents that knowledge is codified in the decision making logic.
When an agent escalates to a human
it isn't because it doesn't know what to do
but because the situation requires human judgment.
The knowledge doesn't walk out the door
but you do have a new problem.
The agent only knows what it knows
and updating that knowledge requires retraining or policy changes.
You can't just call a senior tech and ask them a question.
You have to change the model or the policy.
The speed to resolution changes your entire relationship with your users.
Problems get fixed in minutes instead of hours
and users start to see IT as a responsive service they can trust.
This isn't a small detail.
This is how you shift the perception of IT
from a bottleneck to a service that actually works.
It changes user behavior, ticket patterns
and how the business views technology as a whole.
The real opportunity underneath all of this is the human one.
Your team isn't spending their energy on repetitive tasks anymore
so they are finally free to work on things
that require real human thinking.
They can design better systems, understand business context
and strategize about how technology supports the company.
This is the best version of where technology should go.
It isn't about replacing humans
but about removing the drudgery so humans can do the thinking.
The competitive advantage.
The companies that get this right first
have something the others don't
and it's not just faster ticket resolution.
It's not just lower operational costs
though both of those matters.
The real advantage is that they're building a capability stack
that compounds over time
while everyone else is still writing if they're logic.
Here's how it actually breaks down.
If your organization moves to autonomous agents in 2026
you get a two to three year head start on everyone who waits.
This isn't because the technology is hard to copy.
Eventually other companies will build similar systems
but the organizations that start now
accumulate operational knowledge, feedback data
and policy patterns that the late comers simply won't have.
Think about what happens during your first year operating agents.
You're not just running automation, you're learning,
you're seeing patterns in what kinds of tickets agents
handle beautifully and what kinds trip them up.
You're building institutional knowledge about
how your specific environment behaves
and your refining policies dozens of times
based on real production feedback.
By the time the year is up you don't just have working agents.
You have a mature operational model.
An organization that starts this in 2027 or 2028
doesn't get to follow your path.
They have to chart their own.
They might avoid some of your early mistakes
but they don't get the benefit of your years of operational refinement.
They're starting from scratch while you're already optimized.
The second advantage is data.
Every ticket in agent resolves, every decision it makes
and every correction it receives.
That's training data.
Your agents get smarter over time
because they're operating in your actual environment
against your actual problems.
If you move fast,
you accumulate 18 months of production feedback
before competitors even launch pilots.
That feedback becomes a learning advantage.
Your agents understand your environment better
than any generic agent ever could
because they've seen your specific patterns,
your specific edge cases
and your specific business context.
The third advantage is organizational readiness.
By the time your industry is having conversations
about autonomous agents in 2027,
you've already retrained your team.
You've already figured out what skills matter.
You've already built the cultural capability
to work alongside autonomous systems.
You've already had the hard conversations
about what gets automated and what stays human.
Organizations coming later don't get that cultural head start.
They're still figuring out how to think about this
while you're already executing.
The fourth advantage is market consolidation.
In every technology transition,
the leaders captured disproportionate market share,
not because they have better technology eventually.
Competitors catch up,
but because they hit escape velocity first,
they're solving customer problems faster.
They're cheaper, they're more reliable.
They start winning business.
By the time competitors launch similar solutions,
the leader has already grown their customer base,
built stronger partnerships,
and established market presence.
The technology is table stakes after the first mover advantage.
The market position is what lasts,
but there's also a risk
that makes this a necessity rather than an option.
Organizations that don't move toward autonomous agents
by 2027 or 2028 start falling behind operationally.
Not gradually, sharply.
Imagine your competitor has reduced their meantime
to resolution to 40 minutes,
while yours is still three hours.
Imagine they're handling 80% of routine tickets autonomously
while you're at 20%.
Imagine their IT operational cost per resolution is half of yours.
These aren't minor differences.
These are the differences that show up in your margins,
your customer satisfaction scores,
and your ability to compete.
This is why the shift from automation is optional
to automation is strategic matters.
For the last 15 years,
you could be competitive with decent scripting
and solid operational practices.
That era is ending.
The organizations that build autonomous agent capabilities
now will set the standard for what IT operations look like.
Everyone else will be playing catch-up.
Not because the technology is complex, it's not.
Because the organizational capability
and operational knowledge compounds over time.
You can't catch up on learning by throwing money at the problem.
You catch up by committing now.
The competitive advantage isn't permanent.
It's an 18-24-month window
where the first move is established a lead.
After that, the technology is available to everyone.
But the organizations that move first
have already built the muscle memory.
They know what works in their environment.
They've optimized their workflows.
They've trained their teams.
They've embedded autonomous operations into their DNA.
That advantage takes years to overcome.
Static power shell scripts worked for a predictable world.
That world doesn't exist anymore.
Your enterprise is dynamic.
Your problems are complex.
And automation without reasoning is just repetition at high speed.
The shift to autonomous agents powered by semantic kernel
and Microsoft Graph isn't a technology change.
It's an operational one.
It's how IT operations work starting now.
Start building your first agent in the next quarter.
Pick a domain where you have high ticket volume
and low variation.
Get it running in production.
Measure what matters.
Use those results to expand.
The time to start isn't some time next year.
It's now.
Your competitive advantage depends on it.