Bee, the AI wearables startup Amazon acquired last year, makes devices that remember what people say in everyday conversations. A new update, announced Thursday morning, includes a feature that turns those passing remarks into shopping suggestions on Amazon.com.

For example, as described by Amazon, someone might mention offhand that they’re out of dish soap, and a product recommendation would show up on Amazon.com and in the Bee mobile and desktop apps. Amazon pitches it as a way for people to remember to buy things they need.

It’s the kind of thing many people have long suspected their phones of doing secretly, listening to conversations and serving up related content or ads. Researchers haven’t found evidence of that. Either way, Amazon’s twist is to do it openly — and to make it voluntary.

The feature is opt-in, meaning it won’t happen unless users choose to connect their Bee accounts to Amazon.com, and Bee says it won’t share data with Amazon without user consent.

The Amazon.com integration requires Bee Pro, a $12 monthly subscription that also includes unlimited conversation summaries and the ability to ask Alexa+ about things Bee has captured.

New hardware: The feature is part of a broader announcement that includes the first new Bee devices under Amazon’s ownership: Bee Frontier, a $74.99 wristband that can also clip onto clothing, and Bee Eclipse, which attaches magnetically to the back of a phone and starts at $99.99.

Bee Frontier, available now, has dual microphones, up to seven days of battery life and IP67 water resistance. Bee Eclipse, about the size of a credit card, runs more than 21 days on a charge and will be available soon, Amazon says.

Amazon says Bee lets people pay attention to a conversation instead of taking notes, keeping track of details such as when and where they agreed to meet a friend. The devices turn conversations into summaries, to-dos and reminders.

Users can read their summaries in the Bee mobile app or a new desktop app, formatted for different kinds of conversations, such as lectures, care plans and brainstorming sessions. Bee also picks up on recurring themes in conversations and suggests goals and actions.

Bee connects to apps including Gmail, Google Calendar and Microsoft Outlook. After a call or meeting, it can list action items, draft follow-up emails or create calendar invites based on the conversation.

Users can also link Bee to Apple HealthKit and to their photos. Most of those features, including the desktop app and third-party integrations, also require Bee Pro.

Without a subscription, Bee users get conversation summaries and 14 days of memory. New customers get 30 days of Bee Pro free.

How Bee handles privacy: Amazon says Bee runs on a system it calls Bee Private Compute, which processes conversations in an isolated environment where “no one, including Amazon, can access your data.” Audio is deleted after it’s processed, and transcripts are encrypted with keys controlled by the user’s device.

Both new devices turn on and off with a single button and show a light when they’re running. For phone calls, Bee Eclipse prompts users to get permission from the other people on the call each time it starts, according to Amazon.

Bee and Amazon: Amazon acquired Bee in July 2025 for an undisclosed price. At the time, the San Francisco startup, led by co-founders Maria de Lourdes Zollo and Ethan Sutin, had raised $7 million and sold a $49.99 wristband called Bee Pioneer.

Thursday’s update connects Bee to two of Amazon’s biggest consumer businesses: its online store, through the product recommendations; and Alexa+, the new version of its longtime voice assistant, by letting users ask Alexa+ on an Echo device about things Bee has captured.

Amazon isn’t the only tech giant betting on AI devices.

• Apple last month announced Siri Recap, an opt-in feature that summarizes conversations on its new Apple Watches, set to arrive in beta later this year.
• Meta bought Limitless, maker of a conversation-recording pendant, in December 2025, and last month unveiled the Muse Charm, a keychain-sized device for its Muse AI agent that’s set to ship this December.
• OpenAI is developing its own hardware with former Apple designer Jony Ive.

Bee also competes with startups such as Plaud, Omi and Friend, which make AI recorders and pendants that listen to conversations, and with AI notetaking apps such as Granola and Otter that work on a phone, with no extra device required.

On another front, Amazon is fighting to keep other companies’ AI agents out of its store. Last month it blocked Meta’s Muse assistant from shopping on Amazon.com, after earlier moves against shopping agents from Perplexity, Google and OpenAI.

Every city already knows how to move people. Guide signs tell you where you're going. Warning signs tell you what's ahead. Work zones tell you someone is building and someone else is directing traffic. Traffic engineers call the whole system wayfinding. It's one of the oldest user-experience disciplines local government has.

We borrowed it to build a conference app on Azure. A public-sector association asked us for a digital passport for its annual conference. Attendees visit sponsor tables, collect stamps, and earn a spot in the prize drawing. Underneath, it's a wayfinding problem in two directions: getting people to the right conversations, and getting every request to the right Azure service and back. This post walks the route.

The destination: conversations, not stamps

Sponsors don't come to a conference for a table. They come to talk to people. A paper passport fails at exactly that: walk up, get a stamp, walk off. So before we chose a single service, we set the destination. A stamp has to be earned by a conversation.

Each sponsor table has a question, and the sponsor gives the answer while talking with the attendee. Scanning a table's QR code opens that question rather than awarding points, because a scan alone proves nothing. Points roll up to a live leaderboard and the prize drawing. Every Azure decision that followed traces back to that one sentence.

The route a stamp takes

The architecture is four exits on one road, and each service does one job well.

Exit 1: Azure Static Web Apps. The React front end is served from the global edge. A navigation fallback means a deep link printed on a table's QR code opens straight into the app. Security headers live in staticwebapp.config.json, next to the code they protect.

Exit 2: Azure Functions. The API runs on the Node.js v4 programming model. HTTP triggers handle sign-in, check-ins, the leaderboard, and the staff portal. A timer trigger keeps the app warm during conference hours. Shared modules hold the rules that matter, such as how points are awarded, so every endpoint follows them consistently.

Exit 3: Azure Cosmos DB. This is where most of the design thinking went. There are three serverless containers, and each partition key matches how the data is actually read. Attendees are partitioned by email, which is how they sign in. Check-ins are partitioned by attendee, which is how a passport is drawn. The database itself guarantees one stamp per sponsor per attendee:

// checkins container: partitioned by attendee
partitionKey: { paths: ['/attendeeId'], kind: 'Hash', version: 2 }
// one check-in per sponsor within each attendee's partition
uniqueKeyPolicy: { uniqueKeys: [ { paths: ['/sponsorId'] } ] }

Point awards use optimistic concurrency. The function reads the attendee, computes the new total, and writes it back only if the document's _etag hasn't changed. If two taps race, or a staff member grants a manual credit at the same moment, the loser gets a 412, re-reads, and tries again. Nobody's points are double-counted or lost.

Exit 4: Microsoft Graph. Sign-in links are sent through Microsoft 365 mailboxes using an Entra ID app registration with the Mail.Send application permission. Azure Communication Services Email stays configured as a standby route.

Put a sign at every hazard

Good roads don't assume perfect drivers. They post a sign wherever conditions change. We did the same: we listed what would really happen when a few hundred people use this on their own phones, in a hotel ballroom, all at once. Then we built an Azure answer for each one.

No accounts, but every stamp tracked. The client didn't want attendees creating accounts or remembering passwords. They still needed each person's passport tracked, through phone switches and closed browsers, all the way to the prize drawing. An attendee's email resolves both: it is their passport number. They type it, tap a link, and they're in. Staff can find them at the help desk, and winners can be contacted. Link tokens are stored only as hashes in Cosmos DB.

Link scanners ahead. Many organizations, especially government, run email security that opens every link before a person does. A single-use link would be spent by the scanner. So a link lasts 60 minutes and up to 15 opens. Asking for another link doesn't cancel the first, and signing in patches only the token fields on the attendee document, so it can never overwrite points.

Everyone at once. Registration is a surge: everyone opens the app and asks for a link in the same few minutes. Six Graph mailboxes take turns sending, and a busy mailbox hands off to the next.

Thumbs on phones. Answers are graded the way a sponsor would grade them: word by word, typos and word order forgiven, numbers exact. The API and the staff "test an answer" tool share one matching module, and a test fails if the two ever drift apart.

Rehearse the rush, then read the telemetry

Traffic engineers don't guess at volume; they count it. Before the event, we rehearsed registration at full scale: 200 real sign-ins in three minutes. Then we read the results back from Application Insights rather than trusting the script's console.

All 200 were delivered, with a median send of 226 ms and a 95th percentile of 418 ms. No failovers or throttling occurred. We load-tested the API the same way, with thousands of simultaneous requests. That run produced the most useful rule of the project: Functions perform best after they've been running for a while, so event week is a no-deploy zone. The timer trigger keeps everything warm.

Agents build. People hold the paddle.

Here's how the work got done. We built this with GitHub Copilot in agent mode in VS Code, using the Azure MCP Server so the agent could read live Azure state instead of guessing. The agent was the work crew. It quickly scaffolded functions, React pages, Bicep modules, and tests.

But a work zone always has a flagger, and that was our job:

• A decision log. Every significant choice is written down with its reasoning, from the platform to the partition keys. The agent works from it, and next year's team inherits it.
• A test gate. 327 API tests and 177 front-end tests run in GitHub Actions on every push. A change is done when the tests say so.
• Infrastructure as code. Five Bicep modules describe the whole environment, so we can review, rebuild, and hand it off.
• A person approves anything irreversible. That covers every deploy, data change, and production setting.

These are the same rules we'd hold any contractor to. The agent didn't lower the bar; it gave us time to apply it everywhere.

What this means for local government

Local government already thinks in systems that move people safely: roads, transit, permit counters, public meetings. Azure gives small public teams the same kind of building blocks. There's a managed front door, event-driven compute, a database that enforces its own rules, identity and mail that fit the Microsoft 365 tenant most of us already run, and telemetry to prove it all works.

AI agents make those blocks faster to assemble. The craft is the part that hasn't changed: choosing the destination, signing the hazards, rehearsing the rush, and keeping a person at the paddle. That's the same pattern for a conference passport, a 311 intake, or a permit lookup, and it's work local government developers are well placed to lead.

The road is open. Every stamp on it will mean a conversation happened.

Opening day: what the road actually carried

Rehearsals tell you what should happen. The conference told us what did. We went back to Application Insights and Cosmos DB afterward and counted.

The road held. Throughout the event, the API handled 3,579 sign-in, check-in, leaderboard, and sponsor requests. None failed. The median response time was 89 ms, and the 95th percentile was 502 ms. Our earlier load test had pushed about 3,150 requests per minute through the same functions without a single error, so the real crowd was well within the margin we'd built. Every sign-in link we sent was delivered through the Graph mailboxes, and the one rejected request was malformed.

The hazard signs weren't needed, which is the point. The optimistic-concurrency retry path never had to fire, because no two writes collided on the same attendee. The code was there if it was needed. Signs like that only get tested on the day something goes wrong, and it's still the right place for them.

The stamps were earned. Attendees collected 307 stamps across the three days, and every one came from answering a sponsor's question. We granted no manual credits. Once someone got going, they almost always finished. Completing a passport took a median of about 74 minutes, which is about how long eight real conversations take.

Every table got traffic. Stamps were spread evenly across the eight sponsors, from 24 to 28 each. Each sponsor had at least two dozen conversations, which was the whole reason for the design. The busiest hour was 2 p.m. on the first day, with 64 stamps in 60 minutes.

Attendees came from more than 40 different organizations, including city, village, and county governments across the region.

In Part 1: From First Use Case to Automated Workflows, we focused on identifying use cases and getting setup with your initial SRE Agent. Teams see the value, and now you need to decide how adoption should expand.

These are the questions we increasingly hear from teams. Who should share an agent? When does another team need its own? How do separate agents collaborate? And how do you deploy and govern all of this without creating unnecessary complexity?

Part 2 shares our recommendations for making those decisions. There is no single topology that fits every organization. Start from the work, context, permissions, and ownership involved, then create boundaries only where they are needed.

This part answers three questions:

1. How do we share an SRE Agent with more users?
2. How do we expand from one team to multiple teams, and do we need one SRE Agent or multiple?
3. How do we codify, deploy, and govern SRE Agents at enterprise scale?

1. How do we share an SRE Agent with more users?

Once the first use case is producing useful results, you will likely want to share the agent with more users who can benefit from it. Sharing is not simply about giving people access to use the agent. It is about determining what each user is allowed to do. Teams must decide who can use the agent, who can change it, who can approve sensitive actions, and which safeguards should apply to everyone.

Azure SRE Agent is a team agent: its connected knowledge, investigation history, memory, skills, custom agents, connectors, and configuration are shared within the agent. It does not create private context or state partitions for different users or teams. 

Once you decide that users can work within the same shared agent, Azure SRE Agent provides controls to define what each person can do, enforce guardrails on agent actions, and audit how the agent is used. The following sections walk through those controls.

1.1 Give each person the role required for their responsibility

SRE Agent provides RBAC roles to control who can view, use, build, approve, or administer the agent. They govern actions within the shared agent; they do not create separate resource or context boundaries. 

Assign built-in SRE Agent roles according to what each person needs to do:

• use SRE Agent Reader for stakeholders who only need to view investigations and outcomes;
• use SRE Agent Standard User for team members who need to chat, investigate, and operate the agent;
• add SRE Agent Author for the smaller group that creates custom agents and response plans; and
• reserve SRE Agent Administrator for the few people who manage the agent and approve sensitive actions.

A person who creates and tests workflows may need both Standard User and Author because the Author role alone does not provide chat or approval access. Azure Owner and Contributor roles also do not by themselves grant SRE Agent data-plane permissions.

Start with these built-in roles. If none provides the required separation, use the SRE Agent permission matrix to define an Azure custom role containing only the necessary control-plane and data-plane actions.

1.2 Apply guardrails to the shared agent

User roles determine what each person can do. As more people share the agent, its owners also need a consistent way to shape behavior, restrict sensitive operations and validate outputs. The following controls apply those guardrails across the shared agent.

Use tool access policies to control which tools the shared agent may invoke, which operations require approval, and which operations are denied. Enable approval expiration so unreviewed approval and temporary authorization requests expire automatically. Set the timeout to match the expected administrator response window.

Use hooks when inputs, tool calls, or outputs require deterministic validation, cleanup, or policy checks that should not depend on instructions alone.

Choose the appropriate network control mode. For production agents that handle sensitive data or require egress controls, use Azure VNet so non-platform traffic follows enterprise DNS, firewall, NSG, and logging policies. Review the documented traffic exceptions because platform and connector traffic do not follow the same path.

Use custom instructions to add administrator-defined instructions to the main SRE Agent's prompt. These instructions can establish which sources to prioritize, what evidence to include, how to structure an investigation, and when to stop and ask for approval. They augment the agent’s default behavior, so users do not have to repeat the same operating guidance in every request. Common prompts guide behavior; they are not a hard enforcement boundary.

Set a maximum AAU limit as a cost budget for shared-agent usage. Start with a limit appropriate for the expected users and workflows, monitor consumption, and adjust it as adoption grows rather than leaving usage unconstrained.

1.3 Audit how the shared agent is used

As more people use the agent, use its Application Insights audit telemetry to review tool calls, model invocations, agent activity and handoffs, incident activity, Azure CLI commands, and approval decisions. Use thread and call identifiers to follow a specific investigation and correlate related events.

Use the Azure Activity Log to review who created, updated, or deleted the SRE Agent resource and its related managed identity and Application Insights resources.

Together, roles, common prompts, tool access policies, hooks, and usage limits make it safer to share one agent. They do not create separate context boundaries inside it. That distinction leads to the next decision: when to keep expanding one SRE Agent and when to create another. 

2. How do we expand from one team to multiple teams, and do we need one SRE Agent or multiple?

Most enterprises want to transform how operations work across the organization. Once the teams adopt their first SRE Agent and saw their operational toil go down, the questions quickly shift: How do we expand from here? How many SRE Agents do we need? Where should the boundaries sit? And how should teams collaborate when work crosses those boundaries?

When teams first think about this topology, they often start with the size of their environment. They look at the number of subscriptions, resource groups, applications, resources, or teams and assume that a larger environment automatically requires more SRE agents. Azure SRE Agent does not require one agent per subscription, resource group, application, resource, or team, and there is no platform-defined count at which another agent is required. A single agent can work across multiple Azure management groups, subscriptions, resource groups, and Azure regions when it has the required access and context.

The way to think of topology is based on how your organization manages operations today, across the people responsible for the work and the systems they use. Consider the operational problems and workflows the SRE agent will support, the telemetry, source code, data, and knowledge required to perform that work, and the teams with domain expertise in the systems involved. Also consider what each group of users is permitted to see, what actions the agent is permitted to take, and who will create and maintain its workflows. 

The following factors can help you think through which work belongs together and where a separate agent may be useful.

2.1 Factors to help decide when to add a new SRE Agent

2.2 How can multiple SRE Agents collaborate?

Once teams operate separate SRE Agents, operational work can still cross the systems those teams own. Collaboration does not require teams to combine their agents or share all of their context. It means passing work, evidence, and ownership to the team responsible for the next step.

Common use cases include:

• An investigation crosses a team boundary. A team determines that the evidence points to another application, platform, network, identity, database, or data layer. It passes the evidence, what it has already checked, and the requested analysis or action to the team with the required ownership, domain expertise, permissions, or authority.
• A planned change spans several owners. Each team validates its part of the system before and after the change and records the results in the shared change record.
• A central team identifies work for a resource owner. A compliance, security, or cost-management team assigns the work with the supporting evidence and required outcome.

Across these use cases, collaboration requires three things: pass enough context for the next team to act, choose how the work will move between agents, and preserve a shared record of the outcome.

Pass the work as a structured handoff. Include the problem or task, its impact, links to the supporting evidence, what has already been checked, the current findings and uncertainty, and the specific analysis or action requested. This prevents the receiving team from repeating the investigation. The receiving team then returns its findings or completed action so the originating team can continue or close the broader task.

Choose the handoff mechanism that fits the existing workflow:

• Operational tools and automation. One agent can reassign an incident, create a Jira ticket, or post a summary in Teams. Automation on the incident or ticket can invoke the receiving team’s SRE Agent and write the result back. This enables collaboration without requiring one agent to invoke another directly.
• HTTP triggers. An agent workflow or external automation can invoke a workflow in another SRE Agent and pass the context required for the next step.
• MCP-compatible clients and orchestrators. They can use the SRE Agent MCP server to ask the appropriate agent to investigate a question or continue work in an existing thread.

2.3 Two common multi-agent scenarios

These examples show how enterprises can configure multiple SRE Agents while preserving the context and authority each team needs.

Scenario 1: A shared platform agent collaborates with team-owned agents

Imagine an organization with a platform team that operates infrastructure, networks, shared data services, and other common dependencies for many application teams. Frontline operations or the service desk routes an incident to the platform team’s SRE Agent first.

The platform agent investigates using centralized infrastructure telemetry, infrastructure-as-code repositories, change history, and platform knowledge. It orchestrates work across its specialized platform capabilities and collaborates laterally with team-owned agents. If the issue is in the shared platform, the platform team continues the investigation and takes the actions within its authority. If the platform is healthy or the evidence points to an application, the agent hands the incident to the appropriate application team’s agent with the evidence already collected and the dependencies already checked.

Application agents can also have permitted read visibility into shared platform dependencies. This helps application teams identify whether a problem originates in their service or the platform, while the platform team retains authority over platform changes.

Scenario 2: Team-owned agents coordinate directly

In another organization, each product or application team operates the services it builds and owns its operational context, telemetry, code, permissions, and workflows. Each team’s SRE Agent is the first responder for its services.

When an investigation points to another service or shared dependency, the initiating agent packages the evidence and hands the work directly to the owning team’s agent. Teams whose operational work does not cross can continue to operate independently. Each agent investigates and acts within its own boundary, while collaborating teams use the same incident or ticket to maintain an end-to-end record.

Shared enterprise standards can provide consistent identity, logging, security, deployment, and governance controls. Teams can also reuse approved skills, tools, and workflow templates without combining their runtime context or agent configuration.

3. How do we codify, deploy, and govern SRE Agents at enterprise scale?

Whether an organization operates one SRE Agent or many, those agents continue to change after deployment. Teams add skills, subagents, tools, prompts, hooks, automations, and policies, while the agents accumulate knowledge and memories through operational use. Because these changes can affect how an agent investigates, analyzes, and acts, manage the agent’s configuration, artifacts, and learnings with the same discipline used for production code.

This becomes especially important when teams move from a proof-of-concept or test agent to a production agent. They may need to create the production agent in the same region or another region while preserving the configuration, knowledge, memories, and operational refinements accumulated during testing. They also need to understand whether changes to a skill, subagent, tool, prompt, or policy changed the agent’s behavior.

Our recommendation is to export an agent that has already been refined through real use, bring the export under version control, and use it as a repeatable baseline. Teams can then preserve its learnings, create production agents in the required environments, track how the configuration changes, and decide which parts should remain agent-specific or be shared with other agents.

3.1 Export the working agent as code

The Azure SRE Agent team maintains the public microsoft/sre-agent repository with templates and scripts for deploying, exporting, cloning, and verifying agents. The repository includes Bash and PowerShell scripts that create a deploy-ready export of a working agent.

The export includes the agent settings, connectors, skills, subagents, tools, hooks, common prompts, repositories, plugin configuration, scheduled tasks, incident filters, HTTP triggers, incident-platform configuration, knowledge, and expected configuration. By default, it also includes synthesized knowledge and workspace memories developed through prior investigations and interactions. Repository instructions can be included when needed.

Review the export for sensitive information and keep connector credentials and other secrets outside the repository. Commit the approved export to Git so teams can preserve the agent’s accumulated knowledge, track configuration changes that may affect its behavior, identify drift, recreate the agent in the same or another region, and use a known agent-as-code baseline for future changes.

3.2 Standardize what should be shared

Decide which parts of the baseline should apply to every agent. Use Bicep or Terraform and Git to define common identity, network, security, logging, audit, and deployment controls, while parameterizing the values that differ by agent or environment.

The public SRE Agent templates provide examples for infrastructure as code, export, deployment, verification, and CI/CD. For reusable operational capabilities, use a private plugin marketplace backed by private GitHub or GitHub Enterprise. Teams can maintain approved skills and MCP integrations once, while agent owners install only the capabilities relevant to their agents. Each installation is pinned to a Git commit so teams can control when updates are adopted.

Together, the version-controlled export, infrastructure as code, shared baseline, and private plugin marketplace provide a repeatable way to expand SRE Agent without making every agent identical.

Share your thoughts

There is no single enterprise topology to copy. The useful pattern is to start by looking inward at the operational toil your team owns, prove value with an initial agent, then share that agent where context and authority can be shared safely, and introduce new agents where organizational or operational boundaries require them.

As you scale SRE Agent beyond a single team, where does sharing, governing, or coordinating agents still feel harder than it should? What could we build or improve to make enterprise-wide adoption easier, safer, or more manageable? What scenarios are you trying to solve next?

We’d love to hear what is working, where you are getting stuck, and what you would like to see next. Share your experience and ideas in the comments below. Your feedback will help us understand where organizations need better guidance, stronger governance, or new capabilities in SRE Agent.

Next steps

• Return to Part 1: From First Use Case to Automated Workflows.
• Open Azure SRE Agent and start your first use case.
• Create and set up an Azure SRE Agent.
• Explore the public SRE Agent templates for infrastructure as code, export, verification, and CI/CD examples.

We have learned a lot from talking with teams that are bringing Azure SRE Agent into their day-to-day operations. Across those conversations, we have seen a common set of questions emerge as teams move from exploring an initial use case to adopting SRE Agent more broadly.

Some teams are starting with a simple question: “Where should we begin?” Others have already seen value in reducing operational toil and improving incident response and are asking what comes next. How do we expand from one successful use case to more workflows? Can multiple teams share the same agent safely? When should we use one SRE Agent versus multiple agents? How should agents collaborate? And how do we deploy and govern them consistently across the enterprise?

This two-part guide shares the patterns we have seen and our recommendations for navigating that journey, from the first use case to broader enterprise adoption. Our recommendation is to start with one operational problem your team understands, learn what the agent needs to solve it effectively, and expand from there. The goal is not to design your enterprise topology on day one. It is to make each next decision with better evidence.

Part 1: Deploying Your First Azure SRE Agent

1. Which operational problem should we start with?
2. How do I run the first use case? Should I use SRE Agent’s built-in capabilities or customize it?
3. How do we turn a successful first use case into more automated operational workflows?

Part 2: From One Team to Enterprise-Wide Adoption

4. How do we share an SRE Agent with more users?
5. How do we expand from one team to multiple teams, and do we need one SRE Agent or multiple?
6. How do we codify, deploy, and govern SRE Agents at enterprise scale?

Part 1 focuses on proving and expanding the operational value. Part 2 addresses the questions that appear when more users, teams, and agents become involved.

1. Which operational problem should we start with?

A strong first use case is a recurring, bounded problem that the team feels today and understands well enough to judge. Focus on work that affects reliability, consumes engineering time, slows incident response, or creates avoidable cost.

Start with the operational pain your team feels most. Choose one well-bounded problem that matters to the team and is familiar enough to judge.

If you are unsure where to begin, start by asking SRE Agent to investigate an issue or incident your team is already looking at. Give it the observed symptom or question, let it bring together telemetry, dependencies, source code, and recent changes, and see whether it can identify where the problem is likely occurring. That investigation can include root-cause analysis, deployment correlation, Azure resource health, and dependency analysis. The examples below are some of the use cases we have seen customers implement.

• Alert investigation: correlate alerts with telemetry, dependencies, source code, and recent changes to explain what happened and identify the next step.
• Incident auto-triage: collect the initial evidence, identify likely ownership and severity, remove known false positives, and prepare the incident for the responding team.
• Proactive availability: perform proactive health checks, reliability risks, degraded signals, or unhealthy dependencies before they become customer-facing incidents.
• Deployment correlation: correlate a failure or degradation with recent deployments, configuration changes, feature releases, and infrastructure updates.
• Production deployment validation: evaluate post-deployment telemetry, logs, dependencies, and service-health criteria to confirm that a production release is healthy.
• FinOps proactive cost optimization: identify unexpected cost changes, underused resources, and rightsizing opportunities before spend becomes a larger problem.
• Certificate expiry monitoring: identify certificates approaching expiration, determine the affected services and owners, and initiate the appropriate follow-up.

2. How do I run the first use case? Should I use SRE Agent’s built-in capabilities or customize it?

Once the team has selected the operational pain it wants to address, the next step is to prove that SRE Agent can improve the outcome. Two questions matter at this stage: how should we set up SRE Agent to execute the first use case, and do we need to customize beyond its built-in capabilities?

Keep the first use case deliberately small. Connect only the context required to solve the selected problem. For deployment validation, that may be the relevant telemetry source, code repository, deployment history, and runbook, not every repository, monitoring system, or resource the team may eventually use. For more guidance on setting up the first SRE Agent, see Getting the best out of Azure SRE Agent.

Begin with diagnostic or read-only access. Use the agent’s managed identity and Azure RBAC as the starting point for Azure resource access. Grant only the resource scopes and permissions required for the use case. As the workflow demonstrates a need to perform write actions, add the narrowest permission at the narrowest practical scope rather than granting broad access up front.

Test the agent against a few recent historical incidents the team understands. Use these cases to confirm that the agent can reach the right telemetry, code, deployment history, and operational knowledge, and to expose missing context before a live incident.

Then use SRE Agent alongside the team’s normal response process when a real issue occurs. This is where teams begin to build trust: the agent surfaces the relevant evidence, identifies where the problem is likely occurring, connects it to a dependency or recent change, explains its reasoning, and helps responders reach the diagnosis faster.

Define the outcomes you want to accomplish. Measure the outcome in the system that already records it, for example, mean time to resolution in the incident platform, alert volume or false-positive rate in monitoring, deployment failure or rollback rate in CI/CD. Choose the measure that matches the pain that justified the use case. Establish a baseline, then use an SRE Agent live report or an existing dashboard to track the result.

2.1 When do I customize SRE Agent, and do I need a skill, custom subagent, or tool?

Always start small with SRE Agent’s built-in capabilities. Then add only what the workflow needs.

1. Start with the expert skills and tools that come with SRE Agent. Out of the box, SRE Agent combines Azure-specific product knowledge and built-in operational capabilities for diagnosing issues and finding probable root causes across Azure. This expertise spans all of Azure, including compute, storage, networking, data, monitoring, and management services. Its native integrations connect Azure Monitor, Application Insights, and Log Analytics, GitHub, and Azure DevOps so the agent can correlate infrastructure state, telemetry, deployments, work items, and source code. General-purpose tools, including Azure CLI, Kusto queries, and code analysis, let it gather deeper evidence within its assigned permissions. For example, it can trace network connectivity, troubleshoot gateway and load-balancing paths, query application telemetry and logs, and correlate a degradation with a recent code or deployment change.
2. Add a custom skill when SRE Agent needs to understand how your environment or organization works. Before writing a new skill, browse the plugin marketplace and the public Azure SRE Agent Plugins repository to see whether an existing plugin covers the scenario. A skill can teach the agent how to use and interpret a third-party telemetry source such as Dynatrace, which dashboards or signals matter, how your runbooks and escalation processes work, or how your organization performs a workflow such as pull-request validation, release-risk analysis, or compliance review. Even with a native integration, adding your operating instructions as a skill can help the agent find the right evidence faster.
3. Add a custom tool when part of the workflow must run consistently. Use deterministic code when the agent must perform the same calculation, execute a predefined query, call an external API, or generate a report in an exact format every time. A skill explains when and how your organization performs the task; a tool performs the required action consistently. Prefer an existing built-in or connector tool before adding a custom Python tool, HTTP or Kusto tool, or MCP connector.
4. Use a skill and tool together when the workflow needs both organizational guidance and deterministic execution. For example, a skill can describe how your organization evaluates deployment risk, while a tool calculates the risk score or generates the required report.

For most workflows, built-in capabilities plus a custom skill are sufficient. Add a custom tool only when the workflow requires repeatable execution, external-system access, or an exact output.

2.2 When do I need a custom subagent?

A custom subagent is a specialist within SRE Agent designed for a focused operational workflow. For most use cases, start with a skill. A skill is enough when the main SRE Agent needs to understand and apply your team’s instructions as part of a broader conversation or investigation.

Create a custom subagent when you want to control the scope of that workflow, package a focused set of instructions, skills, and tools, test or invoke it independently, or connect it to a trigger. The use case itself does not determine the choice. The same deployment-validation guidance can remain a skill when an engineer asks the main agent to apply it during an investigation. Package that skill in a deployment-validation agent when the workflow should stay within a defined scope, use selected tools, and run after a deployment through an incident, schedule, HTTP trigger, or another workflow.

Start with a skill. Use a custom subagent when the workflow needs tighter scope, focused instructions and tools, independent invocation, or trigger-based automation.

3. How do we turn a successful first use case into more automated operational workflows?

Once the first use case proves the value, look at what the team still does manually around it. Where are engineers repeatedly gathering the same evidence, running the same diagnostics, monitoring the same risks, preparing the same updates, or handing off the same follow-up work?

Use live reports to bring together incident, service-health, reliability, and cost signals so recurring patterns and remaining operational toil are easier to see. When the team understands the work and the result is repeatable, it is ready to become an automated workflow.

Begin with the context already connected to the agent. Reuse the same telemetry, repositories, runbooks, resource access, and team knowledge where they apply. Add another source only when the workflow needs evidence the agent cannot currently reach.

There are different ways to start that automation. Use a:

• Response plan when an incident or alert should start the investigation
• Scheduled task for recurring health, capacity, compliance, or reporting work
• HTTP trigger when a pipeline, external monitoring system, or another workflow should invoke the agent

Start these workflows in Review mode, where a person can evaluate the agent’s reasoning and proposed actions. Autonomous mode is a good fit for actions the team has already approved its operators to perform without case-by-case review. Start with a human in the loop, build confidence in the workflow, and move approved actions to Autonomous mode when the team is comfortable allowing the agent to perform them on its own.

Start automating the work the team now understands. Use the right trigger for each workflow, and use live reports to make the next source of operational toil visible.

Continue to Part 2: From One Team to Enterprise-Wide Adoption

Every team has operational work it wishes were faster, more consistent, or less manual. What is the recurring operational problem your team would most like to solve with SRE Agent? And what could we build or improve to make it easier to turn that problem into a trusted workflow?

In part 1, we explored how your organization can go from zero to one with adoption of Azure SRE Agent to address this operational toil in your organization. We'd love for you to share your experience and ideas in the comments below. Your feedback will help us understand where teams need more guidance, better starting points, or new product capabilities.

To continue on to scaling Azure SRE Agent across your enterprise, go on to: Part 2: From One Team to Enterprise-Wide Adoption.

Next steps

• Continue to Part 2: From One Team to Enterprise-Wide Adoption.
• Open Azure SRE Agent and start your first use case.
• Create and set up an Azure SRE Agent.
• Explore the public SRE Agent templates for infrastructure as code, export, verification, and CI/CD examples.

Collaboration is changing as teams of humans and agents now work together to get more done. That’s why we’ve evolved Copilot to empower these human-agent teams: just last month, we announced copilot​ in Teams, Autopilot as your digital teammate, and new tools in Copilot for managing a team’s content workflows.

Today, we are taking the next step in human-agent team collaboration, designed to help address the problem of fragmented and outdated information and enable agent teammates to have the required team context they need to perform tasks and answer questions. In Frontier Preview, Copilot and agents in the newly announced Copilot app, Teams, and SharePoint will be able to create, contribute to, curate, and reference a team’s knowledge base in SharePoint.

Knowledge bases can support a range of team needs by bringing together the context people and agents need to do their best work. Here are some examples of how we are working with frontier teams to leverage a knowledge base:

• Legal: Collecting isolated knowledge from emails, files, and personal notes to help agents reference relevant context when creating agreements and contracts.
• Engineering: Combining technical specifications, user feedback, market research, and product history to give coding agents project context and support the onboarding of new engineers.
• Sales: Organizing account knowledge and history so sales agents can recommend relevant next steps or quickly provide account snapshots.

Team members can explicitly contribute content— whether email, messages, meetings or content that is already on the SharePoint sites they work with. Copilot will organize all this information into an up-to-date knowledge base for the team, readable to people and grounding any agents that are working with the team.

Turning raw content into synthesized knowledge

At its core, the knowledge base is a specialized library of interlinked agent-friendly markdown files, created by Copilot using Work IQ’s native knowledge compilation engine. This content processing platform can help transform a team’s content into agent-ready knowledge to improve agent performance and results. In our early internal testing, we see that an agent’s responses were up to 4x faster and 30% more token-efficient with the knowledge base when retrieving content to answer questions and performing team tasks¹.

Figure 1: The knowledge base pipeline

We believe this is the first step in transforming how human-agent teams work together by leveraging Work IQ’s knowledge compilation engine. As the science advances, the engine improves. By combining advances in content processing with the latest corpus enrichment innovations from our Applied Science research teams, we are continually improving how enterprise content is transformed into usable knowledge. The evidence is promising so far. For example, in a recent paper, we evaluated agents on the task of answering complex questions that require connecting information across multiple documents. We observed significant improvements in both cost efficiency and quality when compared with traditional agents that worked with the original documents or other enrichment methods.

Figure 2: Retrieval quality and cost improvement when using the knowledge base corpus map. 
Note: Results are from a synthetic test environment and published in a public research paper. 

With millions of sites created by customers every day, SharePoint plays a critical role as the home for the content and knowledge of a team, whether as a vibrant site of pages, files, and lists or the backing content store for a Teams Channel or Modern Group. When enhanced with a knowledge base, the SharePoint site evolves from a content source to the context layer for a team that people, Copilot, and agents can use and reference together.

What’s available now

This is rolling out now to our Frontier preview tenants. You can start by adding a knowledge base to any SharePoint site— including those backing Teams Channels and Microsoft 365 Groups. You can further use Copilot in SharePoint and the newly announced Autopilot in the Copilot app to create, curate and use your knowledge base. And with the power of Autopilot, you can also use the knowledge base directly from within Teams, from email (by emailing your autopilot).

Note: While the knowledge base and its tools are available in Frontier public, the integration with Autopilot requires access to Autopilot, which is rolling out on a separate cadence.

Knowledge base is currently available only to users enabled for usage-based billing. Administrators can manage access and spending through the Microsoft 365 admin center. Learn more about managing AI experiences enabled by usage-based billing and how to create the right policies for your organization. Because knowledge base capabilities are currently in preview, billing terms may change before general availability.

What’s coming soon

Next on our roadmap:

• Knowledge bases in more places you work, including tools in Cowork and Copilot in Teams, and custom agents created in Microsoft Copilot Studio.
• Deeper integration with M365 groups – to allow for easier bootstrapping knowledge bases from existing sources (channels, email).
• Automated, ongoing curation with the help of Microsoft Copilot Studio’s agent flows to help keep your knowledge bases up to date as your organization’s content changes.
• Greater content scaling, building on our corpus map approach to support larger volumes of content with higher quality at a lower cost.
• Integration with CLIs and coding agents via Work IQ to allow a broader range of agents to contribute to and work with a knowledge base.

More content AI innovation across the Copilot ecosystem

Our content AI strategy is focused on helping organizations turn their content into knowledge that people and agents can use in the flow of work. We’re continuing to bring that strategy to life across the Microsoft 365 and Copilot ecosystem with knowledge bases in SharePoint. And we’re not done yet!

Here are a few more recent updates in the content AI space:

• SharePoint tools in Work IQ are coming soon. Last month, we announced that SharePoint tools were coming to the new Copilot app through Work IQ.
• Copilot in SharePoint is now generally available, bringing Copilot directly into the place where your organization’s content lives. It helps you understand, create, organize, and act on content with AI. Learn more in last month’s blog.
• New capabilities to govern the content that powers AI. Copilot and agents perform best on well-governed content.
  • The SharePoint Admin Agent is the centerpiece of our new capabilities for getting there. Admins can use natural language to get tenant-level analysis and guided remediation across permissions, content lifecycle, storage, and settings. They can also monitor cross-geo content moves (preview).
  • Catalog management turns a sprawling tenant into structured, manageable content clusters, so admins can scale actions like site attestations, access reviews, and Restricted Content Discovery, and build rollout plans that better match how their organization works.
  • A detailed file level EEEU permissions report enables targeted cleanup, insights on agent access show which agents are reaching SharePoint and OneDrive content, and Governance Hub helps site owners follow through on assigned actions.

Today’s preview is just a first step, and we look forward to building this with you. Learn more about how you can be among the first to put the knowledge base to work for your teams and help shape what comes next by sharing feedback. You can either share in-product feedback using Copilot in SharePoint, Autopilot, or sign up here for an opportunity to go deeper with us on this journey.

References:

1. Results are based on Microsoft internal testing, October 2026.

On October 13, 2026, the Extended Security Updates (ESU) program for Windows Server 2012 and Windows Server 2012 R2 ended. This closes the three-year extended coverage period that began when these operating systems reached end of support in October 2023. After today, Microsoft will no longer provide security updates for Windows Server 2012 or Windows Server 2012 R2. 

How we got here 

Windows Server 2012 and 2012 R2 reached end of support on October 10, 2023. To give customers time to modernize, Microsoft offered up to three additional years of ESU for eligible servers. Over that time, ESU gave organizations a way to keep receiving critical security updates for workloads that needed more time to upgrade, migrate or modernize. 

What this means for you 

Servers still running Windows Server 2012 or 2012 R2 will no longer receive security updates from Microsoft. Unsupported operating systems become harder to secure and maintain over time and running them in production adds security and compliance risk. Unsupported infrastructure shouldn't be a long-term strategy. 

What to do next 

If you still have Windows Server 2012 or 2012 R2 workloads in production, start with these steps: 

1. Identify affected servers. Inventory your datacenter, edge and cloud environments to find where Windows Server 2012 and 2012 R2 are still running.
2. Understand your dependencies. Many remaining deployments support business-critical applications. Validate what depends on each server before you decide what to do with it.
3. Choose a path for each workload. Options include upgrading to a supported version of Windows Server, migrating workloads to Azure, modernizing applications onto Azure services, or adopting a hybrid approach.
4. Set a timeline and prioritize. Move business-critical and highest-risk workloads first to reduce operational and security exposure.
5. Get help. Engage your Microsoft account team and trusted partners to build a transition plan that fits your environment. 

Why modernizing is worth it 

Moving to a supported platform is the best way to stay secure, and it also gives you the following: 

• A stronger security posture, with ongoing security updates and support
• Better operational efficiency through modern management capabilities
• The latest performance, reliability and resiliency improvements
• Less technical debt and lower long-term infrastructure risk
• Access to new AI, cloud and hybrid capabilities 

Looking ahead 

Microsoft is committed to helping you modernize on your terms, whether you're upgrading on-premises infrastructure, migrating to Azure or taking a hybrid approach. 

To learn more about support lifecycle information and modernization paths, see Overview of Extended Security Updates for Windows Server 2012 and 2012 R2 on Microsoft Learn.