From answering questions to getting things done
A traditional AI assistant is primarily reactive. We ask a question, provide some context, and receive an answer. A Copilot takes this a step further. It can understand our context, work with our data, and help us create content, analyze information, or perform tasks.
Agents introduce another fundamental capability: Action.
An agent can be given a goal and, within the boundaries we define, determine the steps needed to achieve it. It can reason about the task, select tools, interact with systems, retrieve information, call APIs, and potentially coordinate with other agents.
Imagine asking an AI system: "Prepare the monthly sales report, identify the customers whose usage has dropped significantly, create a summary for the account managers, and schedule follow-up meetings."
This is no longer simply a question-and-answer interaction. The system needs to understand the objective, find the appropriate data, analyze it, determine which customers require attention, generate the report, and potentially interact with calendars or other business systems. That is the shift from assistance to agency. And it has profound implications for how we build technology.
The rise of the agentic enterprise
We are moving towards a world where organizations won't have just one AI assistant. They will have many.
A sales agent might analyze opportunities and prepare account briefings. A finance agent could reconcile invoices and identify anomalies. A support agent could investigate incidents and recommend or execute remediation steps. A developer agent could analyze issues, write code, create pull requests, and help run tests. These agents may operate independently, or they may collaborate with one another. This is where the concept of the agentic enterprise starts to emerge.
The important question is no longer simply: "Where can we use AI?"
Instead, organizations need to start asking: "Which decisions and processes can safely be delegated to AI?"
That question is much harder, as it involves architecture, security, identity, governance, data, compliance, and organizational change.
An agent is more than an AI model
One of the biggest misconceptions about agents is that an agent is simply a large language model with a clever prompt. Let’s get that clear: It isn't.
The model is only one component of the system. A production-grade agent may need access to enterprise data, APIs, applications, databases, and external services. It may need memory and context. It may need to understand which tools it can use and when it should use them, and most importantly, it needs an identity.
And this is where things get particularly interesting for enterprise IT. For decades, we have developed sophisticated approaches to managing human identities. Users have accounts, permissions, groups, authentication methods, access reviews, and lifecycle management.
But what happens when the "user" is an AI agent?
- Who is the agent?
- What is it allowed to access?
- Who authorized it?
- Which data can it read?
- Which systems can it modify?
- Can it send an email?
- Can it create a Teams message?
- Can it approve an expense?
- Can it deploy code?
- Can it create another agent?
And perhaps most importantly: How do we know what it actually did?
These are not theoretical questions. As agents become capable of taking real actions, they become part of the security and governance boundary of the organization.
The new identity problem
The rise of AI agents creates an interesting evolution in identity management. We have traditionally thought about two broad categories: humans and applications. Agents blur that distinction. An agent may behave like an application because it is software, but it may also behave like a user because it can make decisions and perform actions on behalf of someone or something else. This creates a new category of non-human actors that organizations must manage carefully. Giving an agent broad permission because "the agent needs access to everything" is obviously dangerous.
But giving every agent its own highly restricted identity introduces another challenge: organizations need to understand what each agent is supposed to do and maintain those permissions throughout its lifecycle. The principles that have served us well for human identity, like least privilege, strong authentication, separation of duties, auditing, and lifecycle management, become just as important in an agentic world.
Perhaps even more important, because an employee may perform hundreds of actions during a working day. An autonomous agent could potentially perform thousands.
From Copilot to agent: the Microsoft ecosystem
The Microsoft ecosystem is evolving rapidly to support this transition.
Microsoft 365 Copilot brings AI directly into the applications where people already work. Copilot Studio allows organizations to create customized agents and connect them to business processes and data. Microsoft Foundry provides capabilities for building and managing AI applications and agents on Azure. Alongside these platforms, developers can use frameworks and services that let them build increasingly sophisticated agentic applications. The result is not a single "agent platform".
It is becoming an ecosystem. Microsoft 365 provides workplace context. Azure provides cloud infrastructure and an application platform. Microsoft Foundry provides capabilities for building AI applications. Copilot Studio brings agent creation closer to business users and low-code developers. Identity, security, governance, and data services provide the foundations required to operate all of this responsibly. The challenge for architects is therefore not simply learning another Microsoft service. It is understanding how these pieces fit together.
The architecture is changing
Traditional enterprise architecture often looks relatively predictable. Users interact with applications. Applications interact with APIs. APIs interact with data, but AI introduces another layer. Users can interact with copilots. Copilots can invoke agents. Agents can call tools and APIs. Those tools can access enterprise data. An agent may also decide to invoke another agent. Suddenly, the architecture becomes dynamic.
The path between a user and a database may no longer be explicitly defined by a developer. An AI system may determine which tool to use based on the context of a request. That creates enormous possibilities, but also enormous responsibility, as Architects need to think about what happens when an agent makes the wrong decision.
- What happens when an agent receives malicious instructions from a document?
- What happens when it is manipulated through prompt injection?
- What happens when it has access to sensitive information that it shouldn't expose?
- What happens when an agent calls an expensive service repeatedly?
- And what happens when two agents disagree?
These are architectural questions, not just AI questions.
Humans are still part of the architecture
There is also a temptation to think that agentic AI means removing humans from the process. In reality, some of the most effective enterprise architectures will probably be those that carefully define where humans remain in control. Not every decision should be autonomous.
Some actions may require approval. Others may require human review only when the agent is uncertain. Some processes may be fully automated because the risk is low and the outcome is predictable. This leads to an important design principle:
Autonomy should be treated as a spectrum, not a switch.
An agent might start by recommending an action. Then it might prepare the action for human approval. Eventually, once the organization has sufficient confidence, it might be allowed to perform that action automatically. Technology enables autonomy, as the organization decides how much autonomy is appropriate.
The biggest challenge may not be technology
The technical capabilities are advancing incredibly quickly. But the hardest part of the agentic transformation may not be building the agents. It may be changing the organization around them.
Teams need to understand what agents are allowed to do. Security teams need visibility into their behavior. Developers need new approaches to testing and observability. Architects need new patterns for agentic systems. Compliance teams need to understand how decisions are being made. And leadership needs to decide where AI should, and should not, be allowed to operate autonomously. This is why AI adoption cannot be reduced to deploying Copilot licenses.
Giving employees access to an AI tool is relatively easy. Building an organization that can safely operate hundreds or thousands of AI agents is an entirely different challenge.
So, what's next?
The move from Copilots to agents represents a fundamental shift in how we interact with technology. For decades, software waited for us. We opened an application, clicked a button, filled in a form, and initiated an action. Then came conversational AI, where we could simply ask for software to help us. Now we are entering a world where software can increasingly act on our behalf. That is the real significance of agents.
The question is no longer whether AI can generate text, images, or code. We already know it can. The question is how far we are willing to let AI act. And that brings us back to the most important challenge of the agentic era: trust.
- Can we trust an agent with our data?
- Can we trust it with our systems?
- Can we trust it with business decisions?
- Can we understand what it did?
- And can we stop it when something goes wrong?
Organizations that answer these questions successfully will move beyond simply experimenting with AI and start building truly agentic enterprises. The future of the Microsoft Cloud may therefore not be defined by how many Copilots we deploy. It will be defined by how effectively we design, secure, govern, and collaborate with the agents that come next.
The Copilot era taught us how to work with AI.
The agentic era will teach us how to work alongside it.
And that conversation is already happening at CollabDays Portugal.
Join us and learn more about this important topic!