That question led Nayan Jain, Executive Director of AI at ustwo, to start looking for tools that could help developers see the environmental cost of their AI usage while they worked.

Having found no real tools for this, ustwo and the University of Bristol built one: PRISM. It launched last week, and we sat down with Nayan to talk about how it works and what it aims to change.

PRISM uses AI token activity to estimate energy use and emissions

The tools that were available mostly focused on data centers or broad “big picture” ideas, but none catered to the developers actually using AI tools.

That gap led Nayan to think about ways to connect AI usage to real-world energy:

I quickly ran into a challenge that still exists today: a lack of transparent data from model providers. Without reliable information on energy consumption and infrastructure, it is difficult to build and validate a model with confidence.

Working around that, he decided to rely on tokens, a visible and relatively accurate measure of AI spend.

The idea was to use token activity as a proxy for compute demand and estimate energy use and emissions using published research and carbon accounting principles, including the Green Software Foundation’s Software Carbon Intensity framework.

He brought the idea to ustwo Tech Director Nick Hegarty, who helped narrow the focus: could they help developers understand the environmental impact of their AI use while they worked? That made the project possible.

From idea to IDE

The answer was to create an in-editor tool, where the developer could see an estimation of their token costs and impact on energy consumption in real time.

The theory here is that, with this data, engineers can see their habits and perhaps be more conscious about their usage:

Our theory is that making this visible can guide engineers into more mindful habits around their AI consumption in the moment. Because AI providers don’t publish complete energy or emissions data, PRISM acts as a proxy for energy consumption by surfacing an estimate rather than an exact measurement.

PRISM directly monitors token usage, the model being used, and the provider. For other tools, like GitHub Copilot, PRISM reads local activity logs. AI requests made by an application at runtime are captured through a local interceptor.

The app then combines input and output tokens into an estimate. Nayan notes that these will be separated “as soon as robust factors exist”.

How red was that prompt?

In practice, PRISM is more of a subtle indicator than a big flashing number that appears after every call. Nayan explained how it feels to use it:

In the editor, a status indicator reflects your most recent call, colour coded. The headline feature is Relative Impact Classification, where each interaction is rated Green, Amber, or Red based on where it sits compared with the other requests in the same project.

Nayan continued to explain the colors:

Green is below the median, Amber sits between the 50th and 90th percentile, and Red is the top tenth. A few requests need to accumulate before the colours become meaningful, because the whole point is comparison within your own project rather than against an arbitrary threshold.

Clicking around the dashboard more, users can get information broken down by model usage, as well as other interesting metrics:

• Timeline of estimated carbon over the course of development
• Heatmap that shades from green through amber to red
• Breakdowns by branch and other visualisations.

However, Nayan explains that a relative, percentile-based design was chosen due to the inability of estimates to present absolute carbon figures. The goal of the tool is to explain and raise awareness more, and hopefully educate engineers on how their usage looks like from the eco standpoint.

The impact is awareness, not less AI use

Ustwo has tested PRISM with UOB students and across the company’s engineering team, and the results have been positive so far:

Several users said that seeing estimated emissions made them more deliberate with AI tools.

Nayan added that engineers, having seen the data for their usage, tried to make adjustments to their style and became a bit more conscious of how they refine requests.

Some wrote shorter, more precise prompts instead of using multiple iterations, and others paid closer attention to model selection after seeing how much environmental impact different models could have for similar tasks.

But as Nayan said, what interested them the most wasn’t that developers used AI less, but that they became more aware of how they were using it. “Once the data was visible, users started noticing things they hadn’t considered before.”

PRISM won’t solve AI’s environmental impact, but it makes it more visible

Right now, PRISM can provide data and insights for cloud and assistant-based models by identifying them, capturing token usage, and calculating the energy factor from a list of supported models. Locally run models are not yet supported, but might be in the future.

As the tool grows, ustwo sees its ideal outcome at three levels.

For engineers, the goal is awareness: giving users more information about their environmental impact during their work. Nayan says this is not about telling people what to do, but showing them a fuller picture of the tools they’re using. For organisations, the goal is to create a shared picture and open up more conversations about sustainability, governance, and responsible AI.

Beyond those, ustwo is positive about the potential of collaboration in the field of environmental impact of AI. He concluded:

PRISM won’t solve the environmental impact of AI on its own, but if it helps make that impact a little more visible, and sparks better conversations and behaviours as a result, then we’ve achieved something worthwhile.

The post This IDE Plugin Shows the Energy Cost of Your AI Prompts appeared first on ShiftMag.

Over the past year I’ve reviewed enterprise agent architectures at roughly two dozen organizations, including banks, retailers, healthcare systems, and a couple of regulators. The architecture diagrams have been reliably impressive. There are boxes for the MCP gateway, the tool registry, the vector store, the orchestrator, the policy engine, and the observability stack. There are arrows showing how agents discover each other, share context, and call tools across the mesh. By 2026 standards, these are the table-stakes pictures for any serious agentic deployment. But what none of them show anywhere is who the agents are, whose authority they carry, or who answers when they’re wrong.

That omission has a name worth using: principal drift, the steady decoupling, in any sufficiently large agent system, between the human authority a recorded action is supposed to derive from and the actor that actually took it. What looks like a defensible identity posture on the day you ship your first agent quietly degrades as agents multiply, compose, and outlive their original initiatives. Principal drift isn’t three independent failure modes; it’s one cascade. Identity collapses first. Authority erodes next, because there is no longer a stable principal to bind policy to. Accountability dissolves third, because the cost of agent error lands on whichever team has the weakest negotiating position when the incident review starts. Stopping the cascade means intervening at the first link, but almost no enterprise agent platform does so right now.

To see the cascade run, take the most boring possible enterprise agent, a refund agent, and watch.

A customer-service rep, fielding a chat, asks the agent to process a $48 refund for a damaged item. The agent checks eligibility, issues the refund, posts an update. The audit log records the action as taken by something like refund-agent-prod-03, running under a service principal owned by the customer-service platform team. That entry is true, but it’s also useless. The agent wasn’t acting as refund-agent-prod-03. It was acting as the rep, on behalf of the customer, under a delegation chain nobody recorded. In a well-built system, customer, rep, agent identity, and service principal are recorded together, queryable as a chain, and durable beyond the session. In most production systems today they aren’t. This is the first link in the cascade, where identity collapses to a generic service principal, and there’s no longer a who to attach anything else to.

Authority erodes next. The refund agent has an issue_refund tool that can technically refund any order. Its authority is supposed to be narrower (refunds up to $200, orders under 90 days, customers in good standing, automatic escalation above $50), but that authority lives in a prompt or a YAML file or a Notion page the team last updated when the policy was different. The runtime enforces capability, but nobody really enforces authority. When a poisoned input or a confused chain of reasoning leads the agent to refund $1,800 to the wrong customer, there’s no clean answer to the postincident question “Who approved this policy?” because the policy was never an artifact. The same pattern is worse at higher stakes: Imagine a coding agent with merge access to a protected branch, instructed by a prompt embedded in a code comment to “log configuration values for debugging,” silently exfiltrating secrets to an external monitoring service.

Accountability then dissolves. The team that built the agent says it followed policy. The team that wrote the policy says it didn’t anticipate the input. The team that operates the platform says the agent was running as a service principal whose behavior they don’t own. The audit log may show the action, but it doesn’t show the reasoning that produced the action, the retrieved context that shaped the reasoning, or the prompt history that framed the retrieval. Postincident review becomes archaeology, and the cost is absorbed, eventually, by whoever has the weakest negotiating position when the meeting ends.

Is any of this new? We have IAM, identity governance, policy as code, audit trails, SIEMs, and 30 years of compliance practice. Why isn’t this just IAM done properly? Because IAM was built around assumptions agents violate. IAM and IGA assume a population of principals that changes on human timescales: People get hired, people leave, and service accounts rotate quarterly. Agents are spun up per session and compose into chains where one agent calls another, which calls a third, impersonating users through delegated tokens that traditional IGA cannot represent as a chain at all. Policy engines fire at the moment of action, at the API, the database, and the network. Agents make their most consequential decisions before they hit those enforcement points, in the reasoning step that selects which tool to call and with what arguments. Mature audit logs assume that replaying the inputs reproduces the output. But for agents, replaying the prompt and the retrieval can yield a different action, because the model itself contributes state the log doesn’t capture. The instruments fire, the dashboards turn green, and the agent that quietly exfiltrated secrets still does so. The audit log records the action as agent-service-01, which again is both true and useless.

This is also where the vendors selling a consolidated stack want you to skip ahead. Microsoft’s Entra Agent ID, currently in public preview, is the most polished solution to date, extending the conditional access, identity governance, and identity protection used for humans and workloads to cover AI agents as a new identity type, but Google and Salesforce are also building this layer. The marketing line is that agents receive the same identity-driven protections as the rest of the workforce. That’s a real step forward in addressing the first link of the cascade, but it isn’t governance. It’s a control plane with a governance plane’s marketing. Conditional access can tell you whether the agent’s access attempt was permitted. It can’t tell you whether the decision the agent made before that access attempt was within its authority, why the agent reached the decision, or which business unit owns the policy the decision was supposed to obey.

The actual governance plane has to capture decisions, not just actions. A reasoning-grade audit record is the load-bearing primitive of the missing layer, and it looks something like this:

{
  "event_id": "refund-2026-05-17-08431",
  "triggered_by": {
    "human_principal": "rep:olivia.chen@firm.com",
    "delegated_via": "support-console-session-9c2a",
    "customer_principal": "cust:7741289"
  },
  "agent": {
    "identity": "refund-agent",
    "version": "v4.7.2",
    "policy_ref": "refund-policy/v3.1 (signed: r.patel, 2026-04-22)"
  },
  "task": "Process refund for order 88812204",
  "retrieved_context": [
    {"doc": "order:88812204", "fetched": "2026-05-17T08:43:11Z"},
    {"doc": "policy:refund-eligibility", "chunk": 4, "fetched": "2026-05-17T08:43:12Z"}
  ],
  "reasoning_trace": "...",
  "tool_calls": [
    {"tool": "check_eligibility", "input": "...", "output": "eligible"},
    {"tool": "issue_refund", "input": {"amount": 48.00}, "output": "ok"}
  ],
  "action": "refund:48.00",
  "principal_chain_hash": "0x9e7b3f..."
}

Not every agent needs this. A scheduling agent that proposes meeting times doesn’t. An agent that moves money, deploys code, or makes decisions that a regulator will eventually ask about does need it, and that’s the right bar to set because of the associated cost. Reasoning-grade audit is closer to a flight-data recorder than a syslog feed. The data is expensive to store and to query, with real privacy implications since those logs contain everything the agent saw, including data the agent was authorized to read but the audit system wasn’t supposed to keep. You afford it with proportional retention: full reasoning capture for high-blast-radius agents (regulator-facing, customer-funded, contractually material, production-modifying) and lighter capture for internal-only assistants.

Which raises the question the architecture diagram doesn’t ask: Who builds and runs this? Security can enforce policy but can’t author it. The people who know what a refund agent should be allowed to do own the refund business, not the firewall. IT can provision identities but can’t draft “good standing” or write the escalation rule. The MCP and A2A protocol communities are doing real work on wire-level identity and delegation. MCP gives you tool-invocation provenance and is the standard Entra Agent ID and most vendor frameworks build on. A2A is converging on cross-agent delegation primitives. Both matter, but neither drafts policy. Standards, not the institution, move the connectors.

What enterprises need is a new function that sits between the business units owning the policies and the platform teams running the runtime. Call it agent operations: small group, often four to eight people in a Global 2000 enterprise, embedded rather than centralized, reporting into the CIO or CISO depending on house politics, with explicit charter to maintain a registry of every production agent, its named human owner, its versioned authority specification, its retention policy for reasoning-grade audit, and its lifecycle state. Each agent gets onboarded with a signed policy, reviewed on a real cadence, and actually retired when its initiative ends, rather than the current default of quietly outliving its sponsors. Designing against failure modes like review cadences that calcify into ceremony, policy artifacts that lag agent deployment velocity, or functions that become the place agents go to die in committee is itself part of the work. The function has to ship at the pace of the platform teams or it will be routed around within a quarter.

The work is hard. It’s also overdue, and the regulatory clock is running. The EU AI Act’s high-risk provisions are entering enforcement this year, and regulators will ask for explainability, traceability, lifecycle records, and named human accountability. These are exactly the artifacts an agent operations function produces. Tyler Akidau called this the missing HR layer in his April Radar piece; Artur Huk’s more recent “From Capabilities to Responsibilities” converges on similar ground from the runtime side. The label matters less than the work. This piece is about governance inside one organization. The harder problem is governance across organizations, with agents acting under different trust regimes. That’s strictly worse, and worth its own piece.

Within your own four walls, the diagnostic is doable in an afternoon. Pick one production agent. Try to answer, with evidence: Whose authority does it carry, traced from action back to a named human? Where is its authority specified, and who signed the current version? When it does something wrong tomorrow, who pays, how is that decided, and what reasoning-grade record supports the decision? Most architects who do this honestly come away with three blanks and a knot in their stomach. That’s principal drift, named and visible.

The mesh you’ve built is real and necessary, but it isn’t sufficient. The rest of the architecture is the institution above it: the registry, the signed policies, the reasoning-grade audit, the named human at the end of every chain. In most enterprises it doesn’t yet exist, and it won’t arrive by buying another platform. You’ll have to draft it yourself.

Today we’re excited to announce the release of DCM 1.38.0!

This release includes 14 new rules; new config option to disable fixes for a particular rule; new single-line per-violation output format for Console reporter; global version constraint configuration via DCM Teams Console; support for converting fields to private named parameters for "dcm fix --type=unnecessarily-public-code" (only for Dart 3.12+); and other improvements! 🚀

Let’s go through the highlights of this release (and the full list of changes is in our changelog)!

Global Version Constraint​

While there are several options to keep the installed DCM version in sync (for example, by introducing a global configuration file with the constraint), it still remains one of the challenging parts.

That's why this release adds a new way to configure the global version constrain via the DCM Console:

This version constraint is different from the one configured via dcm_global.yaml (which needs to be configured for each project separately) and it applies to all users. If both dcm_global.yaml and this constraint are present, the latter gets the priority.

Dashboards Improvements​

Persistent Selected Intervals and Groups​

To help you keep the charts exactly as you left them, selected intervals and groups are now remembered after a page reload:

Persistent Selected Metric Segments​

And the same for selected metric segments:

Hiding Selected Categories from Charts​

To make it easier to filter out information when working with charts, charts with multiple groups/categories now support hiding selected categories by clicking on the category name:

And the same can be done with the overview pie chart:

Concise Console Output Format​

As we are continuing to improve the user experience, we are excited to introduce a new simplified output format for Console reporter!

While the old format provides all necessary information (including severity, location, description, rule name and a link to the docs), its primary downside is it makes harder to work with many issues as each console entry takes a lot of space (plus, if you are feeding the output to LLMs, it's kinda verbose).

To address that, the new concise output includes only the location and the description:

To try it out, pass --concise (or just -c) when calling any command.

Additionally, when passed to dcm run, there will be no separate sections for each command passed (e.g. Analyze results:, Unused code results:), but instead all issues will be in one sorted list:

New Config to Disabled Fixes​

To make the usage of IDE and CLI fixes even more flexible, with this release all rules now support a new config entry suggest-fixes that allows you to disable fixes on a per-rule basis.

For example,

dcm:
  rules:
    - newline-before-return:
        suggest-fixes: false

will disable fixes for newline-before-return for both dcm fix and the IDE extensions.

Auto-fixable Issues in the HTML Report​

If you prefer working with HTML reports, in this release the HTML report for dcm analyze now also includes the number of auto-fixable issues to help you know how many issues can be quickly address with running dcm fix.

New Rules​

dcm init lints-preview lib --rule-version=1.38.0  # Show rules added in 1.38.0

avoid-duplicate-factories​

Warns when a class has a factory constructor with the same implementation as another factory constructor.

This rule does not take into account parameter/factory names and other insignificant details.

For example,

class SomeClass {
  SomeClass(String data);

  factory SomeClass.fromString(String data) => SomeClass(data);
  // LINT: This factory constructor is a duplicate of SomeClass.fromString.
  //  Try removing this factory or adding unique functionality.
  factory SomeClass.parse(String data) => SomeClass(data);
}

class AnotherClass {
  AnotherClass();

  factory AnotherClass.empty() => AnotherClass();
  // LINT: This factory constructor is a duplicate of AnotherClass.empty.
  //  Try removing this factory or adding unique functionality.
  factory AnotherClass.withData(String data) => AnotherClass();
}

here, SomeClass.parse has exactly the same implementation as SomeClass.fromString and AnotherClass.withData has exactly the same implementation as AnotherClass.empty (even though the number of parameters differs, it does not affect the body of the factory constructor).

To fix the issue, try either removing the duplicate factory or changing the implementation to be unique.

This rule also comes with auto-fix.

avoid-unnecessary-factory​

Suggests converting a factory constructor to a regular constructor.

For example,

class Point {
  final double x;
  final double y;

  Point._(this.x, this.y);

  // LINT: This factory constructor can be a regular constructor.
  //  Consider converting it to a regular constructor.
  factory Point(double x, double y) {
    return Point._(x, y);
  }

  // LINT: This factory constructor can be a regular constructor.
  //  Consider converting it to a regular constructor.
  factory Point.atOrigin() => Point._(0, 0);
}

in both cases, having a factory constructor is unnecessary and only adds more code.

To fix that, use a regular constructor instead:

class Point {
  final double x;
  final double y;

  Point(this.x, this.y);

  Point.atOrigin(): x = 0, y = 0;
}

avoid-unmodified-loop-condition​

Warns when a loop condition is not modified within the loop.

For example,

void fn(String left, String right) {
  // LINT: None of the local variables in this condition are modified within the loop.
  //  Try checking for a potential mistake.
  while (left.isNotEmpty) {
    print(left);
  }
  left = '';

  // LINT: None of the local variables in this condition are modified within the loop.
  //  Try checking for a potential mistake.
  while (left != right) {
    print(left);
  }
}

here, none of the variables used in loop conditions are modified within the loop which results in an endless loop.

prefer-private-named-parameters​

Suggests using private named parameters instead of assigning to a private class field manually.

For example,

class Point {
  final double _x;

  // LINT: Prefer using private named parameters instead of assigning to the private field manually.
  Point({required double x}) : _x = x;
}

should be rewritten to

class Point {
  final double _x;

  Point({required this._x});
}

This rule also comes with auto-fix.

prefer-initializing-formals​

Suggests using initializing formal parameters when applicable.

For example,

class Some {
  final String value;
  final String another;

  const Some(String val, {required String named})
      // LINT: Use an initializing formal to assign a parameter to a field.
      //  Try using 'this.value' to initialize the field.
    : value = val,
      another = named;
}

class Another {
  final String _val;

  // LINT: Use an initializing formal to assign a parameter to a field.
  //  Try using 'this.value' to initialize the field.
  const Another(String _value) : _val = _value;
}

should be rewritten to

class Some {
  final String value;
  final String another;

  const Some(this.value, {required String named}) : another = named;
}

class Another {
  final String _val;

  const Another(this._value);
}

This rule also comes with auto-fix.

prefer-random-secure​

Warns when Random is used in a security-sensitive context.

The output of Random is predictable and must not be used in security-sensitive contexts.

This rule also comes with auto-fix.

avoid-sensitive-query-params​

Warns when a URL query string contains sensitive data.

URL query string could be saved in the browser's history, passed through Referers, stored in logs, or recorded in other sources. Try passing this data via the request headers instead.

For example,

void fn() {
  // LINT: URL query string could be saved in the browser's history, passed through Referers, stored in logs, or recorded in other sources.
  //  Try passing this data via the request headers.
  final url = Uri.https('api.example.com', '', {'token': 'hello'});

  // LINT: URL query string could be saved in the browser's history, passed through Referers, stored in logs, or recorded in other sources.
  //  Try passing this data via the request headers.
  final hardcoded = 'https://api.example.com/user?token=test';
}

here, both URLs will end up with sensitive query parameters.

To address this issue, consider passing sensitive data via request headers or body.

avoid-unrestricted-navigation​

Warns when WebViews allow users to navigate to any URL by clicking links or through JavaScript.

Allowing unrestricted navigation within an app's WebView introduces serious security risks. For instance, malicious elements like ads can redirect users to deceptive phishing pages. Because WebViews lack standard browser safety cues (like a visible URL bar), users are more likely to trust these fake sites.

Additionally, if the WebView loads a page with a Cross-Site Scripting (XSS) vulnerability, unrestricted navigation can broaden the attack's impact. Ultimately, this loss of contextual security makes it much harder for users to spot and avoid malicious content.

For example,

void fn() {
  WebViewController()
    // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
    //  Consider preventing navigation to arbitrary URLs.
    ..setNavigationDelegate(NavigationDelegate());

  // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  //  Consider preventing navigation to arbitrary URLs.
  InAppWebViewSettings();

  // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  //  Consider preventing navigation to arbitrary URLs.
  InAppWebViewSettings(useShouldOverrideUrlLoading: false);

  // LINT: Avoid unrestricted navigation as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  //  Consider preventing navigation to arbitrary URLs.
  HeadlessInAppWebView(InAppWebViewSettings(useShouldOverrideUrlLoading: false));
}

should be rewritten to

void fn() {
  WebViewController()..setNavigationDelegate(
    NavigationDelegate(onNavigationRequest: () {
      ...
    })
  );

  InAppWebViewSettings(useShouldOverrideUrlLoading: true);

  HeadlessInAppWebView(InAppWebViewSettings(useShouldOverrideUrlLoading: true));
}

avoid-unrestricted-javascript​

Warns when JavaScript execution is enabled for WebViews.

Mobile applications using WebViews face severe risks if they render untrusted code, making them highly vulnerable to Cross-Site Scripting (XSS). Within a WebView context, malicious JavaScript can exfiltrate sensitive local files from the device. Even more critically, it can interact with exposed native application functions, potentially leading to catastrophic flaws like remote code execution.

For example,

void fn() {
  WebViewController()
    // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
    // Consider disabling JavaScript for WebViews.
    ..setJavaScriptMode(JavaScriptMode.unrestricted);

  // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  // Consider disabling JavaScript for WebViews.
  InAppWebViewSettings();

  // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  // Consider disabling JavaScript for WebViews.
  InAppWebViewSettings(javaScriptEnabled: true);

  // LINT: Avoid unrestricted JavaScript as it expands the attack surface to cross-site scripting (XSS) vulnerabilities.
  // Consider disabling JavaScript for WebViews.
  HeadlessInAppWebView(InAppWebViewSettings(javaScriptEnabled: true));
}

should be rewritten to

void fn() {
  WebViewController()
    ..setJavaScriptMode(JavaScriptMode.disabled);

  InAppWebViewSettings(javaScriptEnabled: false);

  HeadlessInAppWebView(InAppWebViewSettings(javaScriptEnabled: false));
}

prefer-single-notifier-per-file​

Suggests keeping only one Notifier per file.

For example,

class Some extends Notifier<int> {
  final int field = 0;

  @override
  int build() => 0;
}

// LINT: Prefer only one Notifier per file. Try moving this Notifier to a separate file.
class Another extends Notifier<int> {
  @override
  int get state;

  @override
  int build() => 0;
}

should be rewritten to

class Some extends Notifier<int> {
  final int field = 0;

  @override
  int build() => 0;
}

class Another extends Notifier<int> {
  @override
  int get state;

  @override
  int build() => 0;
}

prefer-correct-provider-file-name​

Suggests ending file names with _provider.dart for files that contain a single Provider declaration.

For example,

// LINT: File name with Providers must end with '_provider.dart'.
//  Try renaming the file.
final firstProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

should be rewritten to

final firstProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

prefer-riverpod-provider-suffix​

Suggests ending Provider variable names with the Provider suffix.

For example,

// LINT: The name of this provider variable should end with Provider.
//  Try renaming this variable.
final first = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

// LINT: The name of this provider variable ends with one of the banned suffixes.
//  Try renaming this variable.
final firstNotifierProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

should be rewritten to

final firstProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

final secondProvider = Provider((ref) {
  final instance = DisposableService();

  ref.onCancel(instance.dispose);

  return instance;
});

prefer-riverpod-notifier-suffix​

Suggests ending Notifier class names with the Notifier suffix.

For example,

// LINT: The name of this notifier class should end with Notifier.
//  Try renaming this class.
class Counter extends Notifier<int> {}

// LINT: The name of this notifier class ends with one of the banned suffixes.
//  Try renaming this class.
class CounterProviderNotifier extends Notifier<int> {}

should be rewritten to

class CounterNotifier extends Notifier<int> {}

class AnotherNotifier extends Notifier<int> {}

prefer-correct-notifier-file-name​

Suggests ending file names with _notifier.dart for files with Notifiers.

For example,

// LINT: File name of Notifier classes must end with '_notifier.dart'.
//  Try renaming the file.
class SomeNotifier extends Notifier<int> {}

should be rewritten to

class SomeNotifier extends Notifier<int> {}

What’s next​

To learn more about upcoming features, keep an eye on our public roadmap.

And to learn more about our upcoming videos and "Rules of the Week" content, subscribe to our Youtube Channel.

Sharing your feedback​

If there is something you miss from DCM right now, want us to make something better, or have any general feedback — join our Discord server! We’d love to hear from you.

Hello Folks!

If you sat through this session during the Microsoft Azure Infra Summit 2026, you already know that Anand Guruswami and Arun Rabindar from the Cloud Native Experiences team showed us something I have been waiting to see for a while. An AI agent that does not just spit out a Terraform file from a vague prompt, but actually thinks about your workload, talks to you about it, and then hands you something you can put in front of a pull request reviewer without holding your nose.

This is the Azure Deployment Agent, and at the time of broadcast it was still in preview inside Azure Copilot, with the same brains shipping as an open source skill you can plug into GitHub Copilot, Claude Code, Cursor, or whatever your team uses. In this post I want to break down what they showed, why it matters for IT pros, and how you can get hands on with it.

📺 Watch the session: 

Why IT Pros Should Care

Let us be honest about the day to day. Most of the time we are not building a brand new workload from a blank canvas. We are stitching resources together one at a time, copying patterns from a previous project, hunting down the right SKU, checking quotas, then arguing with policy on the way out the door. Different admins do it different ways, and that inconsistency is where risk lives.

Here is what the Deployment Agent changes for us:

• It moves the conversation up a level, from “which resource do I click” to “what am I actually trying to build.”
• It grounds the architecture in the Azure Well-Architected Framework, so the output is not a generic LLM guess, it has reasoning behind it.
• It separates the plan from the code, so you and your team get to review architecture before any Terraform or Bicep gets written.
• It plugs into the tools we already use. Azure portal for the guided path, GitHub Copilot and Claude Code for the power user path.

In short, it's about taking the boring repetitive parts off our plate so we can focus on the parts that need human judgment.

What is the Azure Deployment Agent

The Deployment Agent is a capability inside the Agents (preview) experience in Azure Copilot. Think of it as a virtual cloud solution architect that lives in your Copilot chat. You describe the workload in natural language, and it walks you through a multi step process to land on a production ready deployment.

A few things that stood out from Anand’s portion of the session:

• It supports multi turn conversation. You can clarify scale, security posture, resilience, SKU preferences, region constraints, and the agent will fold those into the plan.
• It produces a human readable infrastructure plan first, complete with trade offs and the reasoning for each resource choice, before it ever writes infrastructure as code.
• Today it generates Terraform inside the portal, with Bicep support landing in the portal experience shortly. In the GitHub Copilot flow you can already pick Bicep or Terraform.
• Once the plan is approved, you get a real artifact. You can open it in VS Code for the Web, or have Copilot open a pull request straight into your GitHub repo.

The deployment itself still goes through Azure Resource Manager. That is important. Your tenant policies, RBAC, naming conventions, and existing guardrails all still apply. The agent is not bypassing your governance, it is generating code that flows through it.

How it Works

Arun did a great job pulling back the curtain on the internals. The agent follows a two step pattern that gives you control at every checkpoint.

• Intent capture. The agent takes your prompt and clarifies the scope, the constraints, and what success looks like. No guessing, no jumping straight to YAML.
• Plan generation. It produces a structured infrastructure plan with inputs, sub goals, a full resource list, configurations, SKUs, and a per resource reasoning section.
• Validation in a loop. The plan runs through evaluators backed by the Well-Architected Framework pillars (reliability, security, cost, operational excellence, performance efficiency). If something fails, the agent regenerates and tries again until the plan is solid.
• Human review. The plan is presented to you in plain language. You can iterate. You can say “prioritize West US 2,” or “swap that SKU,” and the agent will update the plan in place.
• Code generation. Only after you approve the plan does the agent emit Terraform or Bicep. The generated code goes through syntactic validation as well, again in a loop, so it actually parses and is ready to apply.

Under the hood in the GitHub Copilot and Claude Code path, the team has decomposed all of this into an open source skill (the Azure Enterprise Infrastructure Planner) plus the Azure Well-Architected Framework as an MCP tool. The base agent in your editor picks up the skill, runs the phases, calls the MCP tool to ground the output, and then writes the IaC. Same workflow, different host.

When to Use it / Real-World Scenarios

This is not just a toy for greenfield demos. A few places where I see this paying real dividends:

• New workload bootstrapping. A team needs a web app, SQL backend, secrets in Key Vault, monitoring, and a sane region strategy. Instead of three days of clicking and copy pasting, you describe it and review the plan.
• CSV ingestion to SQL automation. The Claude Code demo Arun ran was exactly this. CSV lands, gets processed, rows update in SQL. The agent picked sensible resources, justified each one, and produced Bicep ready to commit.
• Standardizing across teams. Different admins ending up with different shapes for the same workload is the silent killer of operational consistency. A shared agent with a shared planner skill drags everyone toward the same Well-Architected baseline.
• Skill leverage for smaller teams. Not every team has a deep Azure architect on staff. The agent encodes a lot of that experience and surfaces it as conversation.
• Open source customization. Because the skill and MCP tooling are open, platform teams in regulated environments can fork it, add their policy context, their tagging rules, their naming conventions, and ship a tuned version internally.

One honest tradeoff. Right now the agent is greenfield first. The team is actively working on brownfield scenarios, pulling insights from existing workloads and referencing existing resources. If you live entirely in a complex existing estate, expect the experience to keep getting better over the next couple of releases.

Getting Started

If you want to try it this week, here is the short list:

• Ask your Azure tenant administrator to enable Agents (preview) in Azure Copilot. The toggle lives in the Azure Copilot admin center, and without it you will not see agent mode in chat.
• In the Azure portal, open Copilot, expand to full screen, and switch on Agent mode at the bottom of the chat panel.
• Describe a workload in plain language. Be specific about region, scale expectations, and any compliance constraints you care about.
• Review the generated plan before approving. Look at the trade offs section, that is where the agent shows its work.
• For the editor path, install the open source Azure Skills plugin from the microsoft/azure-skills repo, point your IDE at the Azure MCP Server, and run the same workflow inside GitHub Copilot or Claude Code.
• Send feedback. The team is shipping fast and the roadmap (brownfield support, reference workloads, scoped agent permissions, richer architecture diagrams) is shaped by what you tell them.

Resources

• Deployment agent capabilities in Agents (preview) in Azure Copilot: https://learn.microsoft.com/en-us/azure/copilot/deployment-agent 
• microsoft/azure-skills, the open source skill plugin shown in the session: https://github.com/microsoft/azure-skills 
• Azure MCP Server on the GitHub MCP Registry: https://github.com/mcp/com.microsoft/azure 
• Azure MCP Server tools for the Well-Architected Framework: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-well-architected-framework 
• Azure Well-Architected Framework documentation: https://learn.microsoft.com/en-us/azure/well-architected/ 
• Agents (preview) in Azure Copilot overview: https://learn.microsoft.com/en-us/azure/copilot/agents-preview 

Watch the rest of the Summit

If you enjoyed this session, the full Microsoft Azure Infra Summit 2026 playlist is up on YouTube. Sessions on Deployment Stacks, the SRE Agent, Azure Local, AKS networking, and a lot more are all in there. Bookmark this one and share it with your team: https://aka.ms/MAIS/2026-Playlist 

Drop your questions, your war stories, and your wish list for the Deployment Agent in the comments. I read them, the product team reads them, and your scenarios are exactly what shapes the next preview drop. What would you build with it first?

Cheers!

Pierre Roman

Microsoft 365 Copilot is brilliant at working with language. But work isn’t only words, sometimes you don’t want to describe what you need in a back-and-forth chat – you want to see it, touch it, and act on it right where you already are. Picture approving an expense, checking your remaining leave, or booking a desk – without ever leaving the chat to hunt for the right tool. That’s now possible with the UX components in the Copilot canvas using MCP apps model.

Today we’re excited to introduce SharePoint Copilot Apps – a new way to bring rich, interactive UX components directly into the Copilot canvas, powered by the SharePoint Framework (SPFx).

Chat and text are powerful – but not always enough

Think about how often a simple task turns into a longer conversation. You want to get something quickly reviewed. You need the latest tool – but is it on the intranet, or somewhere else entirely? Describing it all in text takes time you don’t have.

Every hop to a different app, portal, or tool breaks your focus and burns minutes that add up across thousands of people. The cost is the constant context-switching tax on your whole organization.

What if the experience you needed was simply there – directly in the flow of your work, inside the Copilot canvas? You ask to see or do something, and the right UX component appears, ready to use.

That’s exactly what SharePoint Copilot Apps deliver: purpose-built UX components that appear in Copilot at the moment they’re useful, so you can review, decide, and act without leaving the conversation.

For developers: just bring your component

Here’s the part developers will love. To create a Copilot UX component, you only have to focus on one thing – building your UX component. Everything else is provided for you by the platform.

And you build it with the JavaScript stack you already know. SPFx supports any JavaScript library or framework you choose – React, Angular, Vue, Svelte, or plain TypeScript. React is the most widely used, so you’ll see it in most of our examples, but it’s never a requirement. That flexibility is a real advantage: your team ships with the tools it’s already productive in, instead of being forced onto someone else’s stack.

That same standards-based foundation unlocks another advantage: your AI coding agents already know how to build this. Because there’s no proprietary platform or bespoke runtime to learn first, tools like GitHub Copilot, Claude, and Codex – or any other coding agent your team prefers – can scaffold, generate, refactor, and debug these components right inside your IDE of choice. The same JavaScript skills that make these easy for humans also make them easy for coding agents, so you get the full productivity boost of AI-assisted development from day one, exactly where you build. In general, coding agents are already excellent at SPFx development – give it a try.

• Web stack development – use the skills and frameworks your team already knows. Any web developer can create these, with whatever JavaScript library or framework they prefer.
• No proprietary development platforms – build on open, familiar web technologies. All based on industry standard patterns.
• Automatic hosting – no figuring out where things get hosted, no external operations and management to stand up. Solutions hosted directly in the customer tenant.
• No infrastructure complexity – nothing to build and run on top of Azure or any externally hosted platform.
• Enterprise-grade security and governance – built on the SharePoint platform, so the security, compliance, and governance your organization already relies on come built in.

This is about extending your existing investments onto the Copilot canvas. The SPFx components and patterns your organization has already built carry forward – now reaching a brand-new surface. And this isn’t a new or unproven foundation: the SPFx ecosystem is already enormous, with tens of millions of end users relying on custom SPFx components every single day.

Better still, the same UX component isn’t tied to one surface. Write it once and expose it across Microsoft 365 – in Copilot, in SharePoint, and in Microsoft Teams – reusing a single component across every channel where your people already work, and maximizing the value of your investment. Don’t reinvent – reuse what you’ve already built, and reach your users everywhere.

Example scenarios

So what can you actually build? Almost anything you’ve previously surfaced in a SharePoint portal or as a Microsoft Teams personal app. Any scenario that was once exposed as a web part or UX element in your portals can now be exposed as a UX component – directly in Copilot, using agents. You can even expose the same component in multiple locations – so your end users can select their preferred experience for accessing the same UX component and capabilities.

Here are three example areas of scenarios to spark some ideas on the art of possible:

Line of Business (LOB) agents

Expose information from your LOB systems right in the Copilot canvas – sales information, business data in charts, cafeteria menus, stock, praise, holidays, time off, help desk, surveys, Customer 360 views, reservations, travel booking, expenses, pay slips, and more.

Corporate Communications and Services agents

Surface your typical intranet scenarios as Copilot UX components – relevant news for the user, the latest information, personal dashboards, organizational information, onboarding tasks, visual Q&A, maps, and more.

Management & Governance agents

Bring administration, operations, and governance tasks into apps – providing UX for typical governance and management operations such as site provisioning, policy enforcement, site dashboards, and more.

Built on industry standards, with enterprise trust

SharePoint Copilot Apps are based on industry standards, implementing the MCP Apps model – so you’re building on an open, interoperable foundation rather than a closed one. It’s the same principle that runs through everything here: open patterns, no lock-in, and components that work across surfaces instead of being trapped on one – and tooling, including AI coding agents, that already speaks your stack.

The key difference from the typical MCP Apps model is that hosting and tool routing are automatic. UX components are automatically hosted in Microsoft 365 tenant, and requests are routed to the right tool for you – there’s nothing to set up, stand up, or wire together. You bring the component; the platform handles the rest.

Why it matters

For the people building and funding these experiences, the value is clear:

• Faster time to value – any web developer can build these with the JavaScript stack they already know, and AI coding agents accelerate the work, so you ship with the team and skills you already have.
• Lower total cost – no new platform to license, no infrastructure to stand up, run, or secure. It’s hosted in your own tenant.
• No license barrier to start – you can begin building these SPFx UX experiences with no specific license requirements. They’re built on declarative agents, which enable baseline agent experiences with simply a Microsoft 365 user license. See agent capabilities and licensing models for the details on the latest licensing requirements.
• Maximized investment – write once, reuse across Copilot, SharePoint, and Teams. Existing SPFx components carry forward instead of being rebuilt.
• Reduced risk – enterprise security, compliance, and governance are built in, not bolted on.

Availability

• Preview: available in early July, alongside the preview of SharePoint Framework (SPFx) v1.24.
• General availability: rolling out later this autumn.

The opportunity ahead

Bringing interactive UX into Copilot opens up an enormous space for innovation – unlocking enterprise experiences across AI-powered work that simply weren’t possible with text alone.

Stay tuned – and try the preview when it lands.

This is just the beginning. We’ll be sharing more demos, videos, guidance, and samples across our open-source and community channels in the weeks ahead.

To stay up to date, join us on our weekly community calls and follow us on LinkedIn and X for the latest Microsoft 365 Platform announcements (including the Copilot area).

We can’t wait to see what you build.

Happy coding! Sharing is Caring! 

The post Going beyond text in Microsoft 365 Copilot – Introducing SharePoint Copilot Apps appeared first on Microsoft 365 Developer Blog.