When AI Stops Waiting for Instructions

Recently, I’ve noticed a shift in the conversations surrounding enterprise AI. Just a year ago, most discussions revolved around the capabilities of agents. Questions often included: Can they reason through multiple steps? Use various tools? Access enterprise data? Complete their assigned tasks?

Now, however, I’ve been hearing different kinds of questions emerging. How much responsibility should we assign to an agent? What level of authority should it possess? Who is accountable for its actions once it’s operational? And what occurs when it’s left unsupervised?

These are not just technical inquiries; they focus on operational models. This is particularly pertinent given Microsoft’s latest category of agents.

At Build 2026, Microsoft unveiled an innovative concept: Autopilots. Updates from Microsoft Foundry have made this idea more concrete: a durable agent can have its own identity, email, calendar, OneDrive storage, Teams presence, as well as a place in the organisational structure.

Microsoft Scout, the first Autopilot introduced, moves beyond theory. It operates across Teams, Outlook, OneDrive, and SharePoint, actively managing meetings, preparations, and the necessary follow-ups that pile up throughout the day.

Historically, enterprise technology has waited for us to interact with it. Now, it is evolving to take on tasks independently.

The evolution has been remarkably fast. Initially, we had AI that simply answered questions. Gradually, tools like Copilots emerged to assist with work. Now, we have agents that can handle multi-step tasks using enterprise context.

Autopilots represent yet another step forward.

PROMPT → TASK → ROLE → RESPONSIBILITY

The process starts at the prompt level, where AI provides responses. At the task level, it performs actions. At the role level, it remains consistent. And at the responsibility level, it takes ownership of outcomes within established boundaries.

For instance, consider release management. An engineer may ask an agent to check the readiness of a release. In contrast, a persistent agent could monitor dependencies around the clock, track unresolved issues, prepare necessary documentation, coordinate with teams, and escalate any emerging risks.

There’s no need to remember to make a request. The agent activates based on the work itself. This transition from being called upon to having ongoing responsibility carries significant implications beyond just enhancing the model capabilities.

Currently, Microsoft Foundry classifies agents into assistive agents, background service agents, and Autopilots.

An important distinction to understand is that simply being autonomous doesn’t qualify an agent as an Autopilot. A background agent can operate autonomously throughout the day, but the critical differentiator is its identity.

Every Foundry agent is given an Entra agent identity. An Autopilot, on the other hand, is assigned an agent user account, enabling it to function with its own identity within Microsoft 365, rather than relying on the identity of the staff member who initiated it.

In discussions about agentic AI, the topics of identity and accountability often come up surprisingly late in the process. While excitement grows around reasoning, tool use, and orchestration, someone will inevitably ask: Whose permissions is this agent using? Who granted access? Who can view its actions? How do we revoke that access? These questions become critical when agents operate continuously.

Autonomy defines what an agent can do. Identity reveals who is responsible for those actions. Accountability identifies who is liable for the outcomes. As agents get smarter, those last two questions resonate even more.

This conversation extends beyond individual agents. With Microsoft Agent 365, there’s a broader governance framework: Foundry agents can automatically appear in its registry, giving administrators a unified perspective across the expanding agent network.

One of the most intriguing aspects of Microsoft’s Autopilot framework is its lifecycle. Developers create a blueprint that outlines what an Autopilot can do and the necessary infrastructure. Once it gains approval and is published, teams can hire instances based on that blueprint. Each instance can possess its own identity, permissions, manager, and access rights.

The lifecycle at Microsoft closely resembles: Build → Publish → Approve → Hire → Onboard → Operate → Offboard.

This language is revealing, not because agents are employees—they’re not. But once software has a persistent identity, access, responsibility, and the ability to take initiative, familiar management practices become essential: onboarding, ownership, permissions, policies, and eventually, offboarding. This is the transition that agentic AI makes from mere experimentation to a viable operating model.

Another frequent topic in client discussions is economics. An agent that functions only when directed has a fairly clear consumption pattern. In contrast, an always-on agent might monitor events, gather context, reason, invoke tools, and manage tasks even when no one is directly interacting with it.

This shifts consumption from transactional to continuous. Previously, I argued that businesses should transition from merely counting tokens to considering The Cost per Successful Outcome, ensuring that every outcome justifies its Intelligence Budget.

Autopilots emphasize the importance of this discipline further. Evaluating a release-management Autopilot should focus not on token usage but on its effectiveness—whether releases are expedited, risks are identified sooner, and engineering resources are redirected to more valuable initiatives.

Before entrusting an agent with authority, define its economic parameters.

The key question is not merely, What will this agent cost? but rather, What responsibilities are we compensating it to manage, and how valuable are those responsibilities?

I’ve also noticed a common misconception treating autonomy as a sign of maturity. Autonomy doesn’t necessarily equate to advancement. For most companies, the goal should be suitable autonomy, rather than maximum. Every persistent agent should have what I term an Autonomy Envelope: clear limits surrounding its ability to observe, decide, and act independently. Within that envelope, let it operate freely. At the boundaries, it should require additional authority, and when it extends beyond that envelope, it should escalate the issue.

A scheduling agent and a clinical workflow agent shouldn’t operate under the same autonomy envelope. Similarly, an agent providing purchase recommendations and one approving a multi-million-pound transaction should have different limits.

This is why Microsoft’s latest Foundry features—such as long-running execution, durable state, human-in-the-loop approvals, resilience, and steerability—are so significant. A constant agent must be able to be interrupted, recover, and sometimes understand when it’s essential to pause and ask for help.

Effective autonomy doesn’t mean no human intervention; it’s about knowing when that intervention is essential.

Microsoft’s own AI journey offers a revealing benchmark. In September, the company published insights from its AI transformation process, with one admission standing out: they initially approached AI much like a traditional tech rollout and realised that access and usage do not equal transformation. Significant improvements emerged when teams reevaluated their workflows in light of AI.

Microsoft reports having over 111 agents functioning across various cloud supply chain workflows, with cycle times for specific planning processes dropping from roughly 10 business days to less than 2.5. They also highlight a nine-person cross-functional team collaborating with agents to achieve an initial product release in just 35 days.

Recent research from McKinsey supports this notion, indicating organisations are adopting agents more swiftly than they’re redesigning foundational workflows.

This aligns with my own observations on the ground. Businesses can develop impressive agents in surprisingly short timeframes. The more challenging conversations arise afterward: What should the agent be responsible for? What remains under human control? Where does accountability lie? And does the existing workflow still make sense?

According to Microsoft’s 2026 Work Trend Index, Frontier Professionals are individuals actively redesigning their work processes around agents, rather than simply using AI tools. Notably, 32% of AI users surveyed in India belong to this category, compared to just 16% globally. This suggests a significant opportunity for growth.

The future revolves not only around integrating agents into existing organisations but also about rethinking the fundamental work the organisation is set up to accomplish.

Copilots enhanced individual capacities. Agents enabled us to delegate specific tasks. Now, Autopilots bring persistent responsibility into the mix. The next significant step is orchestration and redesign—creating synergy between humans and agents across processes in ways that may look noticeably different from today.

Before deploying an Autopilot, I’d suggest considering five critical questions: What outcome is it designated to manage? What authority does it hold? What context can it access? When must it escalate issues? And who remains accountable for its actions?

If these questions resemble a job description, perhaps that’s intentional.

While Copilots asked us to adapt individual approaches to work, Autopilots challenge us to rethink the division of labour itself.

Microsoft is making the technology more tangible with persistent identities, blueprints, hiring and onboarding processes, team unity, long-running execution, lifecycle management, and human interventions. However, the responsibility for deciding how much authority to delegate to agents is still a human decision.

For decades, software has waited for instructions. Now, it’s learning how to respond. Ultimately, it is beginning to undertake long-term responsibilities.

The organisations that will thrive aren’t necessarily the ones that implement the most Autopilots but those that excel at determining what tasks agents should own, how far their authority should extend, and where human oversight is essential.

When software no longer awaits direction, the hardest questions are no longer about deployment. They revolve around accountability.

This leads us to a vital principle for the agentic enterprise: Hire slowly, even if the candidate is software.

Microsoft Learn — What is an autopilot in Microsoft Foundry?

Microsoft Learn — Autopilot lifecycle in Microsoft Foundry

Microsoft Learn — Microsoft Agent 365 integration with Microsoft Foundry

Microsoft — Introducing Microsoft Scout: Your always-on personal agent

Microsoft Learn — What’s new in Microsoft Foundry

Microsoft — What we’ve learned from Microsoft’s own AI transformation

Microsoft — Work Trend Index 2026: India’s AI advantage is human

McKinsey & Company — Stacking the odds: A blueprint for successfully scaling agentic AI