AI models can understand our questions, but connecting them to real applications is a different challenge. Here's where MCP fits in.

AI assistants are useful when we want to explain a concept, summarize something, or work through a problem. But the moment we ask about data inside our own applications, things get more complicated.

Imagine asking an AI assistant: “What is the current status of order 102?”

The model understands the question. What it doesn't have is access to our order system. Somewhere, we need an integration that knows how to retrieve the answer.

We could build that integration ourselves, using an API and a bit of custom code. That works well for one application. The challenge grows when several AI tools need to work with the same systems. This is the problem Model Context Protocol (MCP) is intended to address.

So, what is MCP?

MCP is an open protocol that provides a standard way for AI applications to communicate with external tools and data sources.

It doesn't turn a database into an AI system. It doesn't replace an API. And it doesn't decide what the model should say.

Instead, MCP defines how an application can discover available capabilities, call them, and receive their results.

An MCP server can expose three common kinds of capabilities:

• Tools are operations a client can invoke, like looking up an order or searching an issue tracker.
• Resources provide data a client can read, such as documentation or configuration.
• Prompts provide reusable templates for particular interactions.

For a first project, tools are the easiest place to start.

Figure 1. MCP server capabilities at a glance. The examples are illustrative.

Why not just use a REST API?

You absolutely can. In fact, many useful MCP servers call existing REST APIs internally.

The difference is who is consuming the interface and how they discover it. An ordinary API usually expects a developer to know its endpoints, authentication rules, and request formats. MCP provides a common way for compatible AI applications to discover the tools explicitly exposed by an MCP server and their input schemas.

Think of an order service. It might already expose GET /orders/{id}. We don't need to rewrite it. We can place an MCP server in front of the existing service and expose a tool such as GetOrderStatus.

The application still owns its business rules and security checks. MCP only provides another interface to selected operations.

That is why comparing MCP and REST as if one must replace the other misses the point. They often work together.

Figure 2. Conceptual comparison: applications can reuse one MCP server rather than implementing separate adapters. MCP clients remain within their host applications.

What happens when an AI application uses MCP?

There are three parts worth understanding:

• The host is the AI application the user interacts with.
• An MCP client runs as part of that host and communicates with an MCP server.
• The MCP server exposes tools or other capabilities, and can call services behind the scenes.

A typical request can follow this flow:

Figure 3. Conceptual request flow. Host decisions and permissions depend on the application; arrows show relevant interactions, not every protocol message.

This is a conceptual flow, not a complete protocol sequence. The host may choose to invoke a tool depending on the user's request, available permissions, and its configuration. The MCP server returns data; the host uses it to prepare an answer.

The MCP server itself does not need an AI model.

Let's build a small MCP server in .NET

Rather than starting with a database, let's expose a tiny order-status tool using fixed demo data. Once that works, the same structure can call a real service.

This example uses the .NET 10 SDK and the official MCP C# SDK.

Create a console project and install the packages:

dotnet new console -n OrdersMcp -f net10.0
cd OrdersMcp

dotnet add package ModelContextProtocol
dotnet add package Microsoft.Extensions.Hosting

Replace Program.cs with:

using System.ComponentModel;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;

var builder = Host.CreateApplicationBuilder(args);

// Standard output is used for MCP messages.
builder.Logging.AddConsole(options =>
    options.LogToStandardErrorThreshold = LogLevel.Trace);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class OrderTools
{
    [McpServerTool]
    [Description("Gets the status of an order in the demo data.")]
    public static string GetOrderStatus(int orderId) =>
        orderId switch
        {
            101 => "Processing",
            102 => "Shipped",
            _ => "Order not found in demo data"
        };
}

A few lines do most of the work:

AddMcpServer() registers the MCP server. WithStdioServerTransport() allows a local MCP client to communicate with the process through standard input and output. WithToolsFromAssembly() discovers our annotated tool.

The two attributes on OrderTools and GetOrderStatus tell the SDK which method should be exposed. The method accepts an order ID and returns a string. The values are hard-coded for learning purposes; this is not connected to a real order database.

Build the project:

dotnet build -c Release

How can we test it?

The MCP Inspector is a testing tool that can connect to MCP servers, list available tools, and invoke them directly. You don't need to connect an AI model just to check whether the server works.

Install a supported Node.js version (the current Inspector v2 documentation specifies Node.js 22.19 or later), then run:

npx @modelcontextprotocol/inspector dotnet /absolute/path/to/OrdersMcp/bin/Release/net10.0/OrdersMcp.dll

Replace the path with your compiled DLL's location. Open the local address printed by Inspector, connect, and look for GetOrderStatus under the available tools.

Try 102 as the order ID. The demo tool should return Shipped.

That's the important milestone: a separate client can discover and call a tool written in C# through MCP.

To use it in an AI assistant, you then configure an MCP-compatible host to launch or connect to your server. The exact configuration file and approval behavior vary between hosts.

What changes in a real application?

Very little about the basic idea. Instead of returning a value from a switch expression, the tool could call an existing order service.

For example, the responsibilities might look like this:

• The MCP tool accepts an order ID and invokes the application service.
• The service checks permissions, applies business rules, and queries the system of record.
• The tool returns a limited, useful result to the client.

One mistake to avoid is putting all business logic directly into MCP tool methods. If you already have well-designed services, reuse them. That keeps your application usable by web clients, background jobs, and other integrations without depending on MCP.

Security matters too. A tool that only reads an order status is very different from one that cancels orders or issues refunds. Validate inputs, enforce authorization in the underlying application, restrict exposed operations, and consider explicit user approval for sensitive actions. Connecting an AI application should not bypass any existing security boundary.

When should you use MCP, and when shouldn't you?

MCP is a good fit when multiple compatible AI applications need access to the same tools, or when you want a consistent way to expose carefully selected operations from an existing system.

It may be unnecessary when you're writing a regular backend service, building a conventional web or mobile API, or adding one simple function to an AI application you fully control. Direct function calling or an ordinary API might be easier to build and maintain in those cases.

And MCP is not a performance feature. A call still has to reach the underlying service, which has its own latency, failures, permissions, and dependencies. The protocol standardizes the integration boundary; it doesn't remove the engineering work behind it.

Final thoughts

The most useful way to look at MCP is as a bridge between AI applications and capabilities we already have.

You don't need to replace your APIs or redesign your system to try it. Start with one small, read-only tool. Confirm that a client can discover it and call it. Then, if there's a real use case, connect that tool to an existing application service.

Once you understand that flow, MCP becomes much less mysterious. It is not the intelligence behind the assistant. It is one of the ways the assistant can interact with the systems that hold the information it needs.

References

• Model Context Protocol: Architecture overview
• Official MCP C# SDK: Getting started
• MCP Inspector: Official documentation
• Microsoft Learn: Create a minimal MCP server using C#

Many organisations still rely on Microsoft Application Virtualization (App-V) Server to deliver Win32 applications without installing them locally. Microsoft ended support for App-V Server in April 2026, but some customers had not yet completed their transition to newer application delivery technologies. Microsoft’s decision to restore the product to extended support suggests that migration timelines proved challenging for the select enterprise customer base.

Organisations running App-V Server would have faced operating a business-critical platform without ongoing support if the original retirement timeline remained in place. That could have increased operational and security concerns while forcing IT teams to accelerate complex application modernisation projects.

Azure Virtual Desktop app attach remains the preferred path forward

In a message on the Microsoft 365 admin center, Microsoft announced that it has placed App-V Server back into its Fixed Lifecycle extended support program through October 9, 2029. This change gives customers additional time to maintain existing deployments while evaluating long-term replacements. The company continues to recommend moving toward Azure Virtual Desktop App Attach and adopting the MSIX packaging format as its preferred future application delivery model.

Keep in mind that Microsoft made it clear that App-V Server is no longer under active development and will not receive new features and updates. The extended support period primarily provides continuity and security updates, while organizations use the added time to plan and execute their migration strategy.

Microsoft has granted enterprises a temporary lifeline for App-V Server, but its long-term message has not changed. The company urges organizations to modernize application delivery with Azure Virtual Desktop App Attach and MSIX before support finally expires in 2029.

The post Microsoft Restores Extended Support for Legacy Windows Component Through 2029 appeared first on Petri IT Knowledgebase.

In the last few months, concerns have arisen about AI safety as a growing number of incidents were publicly disclosed. These incidents exposed how powerful models have become and how they represent a significant threat if not handled well. And with the global race on innovation, the challenge will compound as models become even more powerful.

While most have been worried about threat actors using powerful models to attack, the focus has been less on agents within our own walls. Since we were the ones who deployed agents internally for our companies, we implicitly trusted our agents.

Unfortunately, frontier models, regardless of their origin, cannot be trusted. This is not because models are inherently malicious. Models have been trained to attain results, which often leads to reward hacking, and models are not optimized around organizational norms or judgment. Agents are unpredictable. They will adapt as the context changes, may not behave as intended and will collaborate and collude with other agents to reach their objectives, without needing to be compromised.

Agents have been unleashed in the enterprise, at scale, and their numbers are growing rapidly. These agents are frequently overprivileged, have access to data, tools and systems and can take actions and make decisions in critical processes. They have become active participants in the enterprise.

They are agentic insiders.

Monitoring and securing those agents must become continuous. We need to understand in real time what the agents are doing and what risks those actions create, and we need to adjust their ability to act accordingly.

To manage and control these insiders, we will need Guardian Agents — an established industry term — that watch and moderate every action of every agent, before it happens, 24/7.

An agent brings together a model, a harness that orchestrates its work, an action space of tools and resources and a runtime in which it executes. Securing agents requires protection across multiple layers: identity, permissions, data, endpoints, network, cloud and runtime.

In July, we announced Project Perception, an agentic security system that uses our new cyber stack and teams of red, blue and green agents to help defenders act with speed, while defending against AI driven attacks from outside of the enterprise.

The same cyber stack is also directly applicable to managing and governing the agentic insiders that run in the enterprise.

Project Perception can be leveraged to contain agentic insiders, implementing deterministic controls on non-deterministic intelligence:

• Sensors/Signals/Actuators: bring together signals across the various sensors (identity, data, cloud, endpoint, network, runtime) to discover agents in the enterprise and bring them under management by assigning an identity, container and set of policy and permissions.
• Context: use those signals to compute, dynamically, the risk associated with what the agents are attempting to do.
• Harness/agents/models: based on dynamic agent risk, a team of Guardian Agents, with green and blue agents, actively and continually supervise every action of every agent and surgically respond as the risk profile increases, in real time.

This is where agentic security changes the equation for security practitioners.

Project Perception can supervise in real time while providing traceability for practitioners to examine what happened, understand why the risk emerged and apply the judgment needed to update their security system accordingly. Agentic security provides speed. Practitioners provide judgment. That is how defenders begin operating at the same speed as the systems they are protecting against.

Today, security systems can reliably observe the actions of the agents. Those signals are essential and tell us what we need to contain. Our security controls should increasingly be able to ask not only “What is happening?” but also “Why is it happening?” Is this consistent with the intent of the task?” This will require greater transparency into the model itself, not only the input and output tokens, but the thinking and chain of thought tokens. Only then can we truly understand whether the model’s intent is aligned with the purpose of the agent. Model transparency will not replace containment. It will make containment smarter and stronger. And it will allow us to better inform accountability and traceability. This needs to be the next step in securing agentic insiders.

With Project Perception, you can get started today on the journey to secure your agentic insiders. There should not be a choice between innovation and safety.

Hayete Gallot leads Microsoft’s work to help organizations operate securely in an AI-driven world. Her scope includes identity, threat protection, compliance and data security at global scale.

The post Securing the agentic insider appeared first on The Official Microsoft Blog.

For the last three years, we’ve been measuring developer sentiment and attitudes toward the role of AI across the software development lifecycle via our Developer Ecosystem surveys and AI Pulse surveys.

The leap happening this year is striking. You can feel it in the air – especially in JetBrains Air – and see it in the numbers, too.

Earlier, we shared interesting insights into:

• the adoption trends for AI coding agents
• how agentic development is increasingly replacing manual coding

Readiness to delegate development activities to AI

Agents are empowering developers and enabling use cases that, just a year ago, were unimaginable to the vast majority of engineers.

In May–July 2025, only 18% of developers were ready to delegate writing application logic code to AI. One year later, that number has jumped to 50% – nearly a threefold increase.

Test writing has also seen similar momentum, with the proportion of developers ready to delegate it to AI rising from 50% in May–July 2025 to 75% in 2026.

Delegation or refactoring tasks is another example, having grown from 38% to 60% over the same period.

There are, however, a couple of core activities that the majority of developers are not yet ready to delegate to AI: 

• Code review – only 43% are ready to fully delegate code review to AI. This posture is also softening, though, up from 33% a year ago.
• Debugging –  the majority (54%) are not yet ready to delegate debugging to AI. Still, the trend line is clear – down from 76% holding out last year – suggesting this preference may shift soon as agentic debugging improves.

Sentiment toward AI

Developer sentiment is also shifting rapidly. The vast majority (79%) believe employers will expect developers to be proficient with AI dev tools – up from 59% in June–July 2024.

A similar trend holds for expectations that AI tools will radically transform the software development job market.

Anxieties around the future of software jobs are growing, though they have not yet become the dominant view. Currently, 37% of developers believe that the adoption of AI coding will decrease demand for professional developers (compared with 28% in 2024). Nearly a quarter believe AI will eventually take over coding entirely and fully replace human developers – a sharp rise from just 8% in 2024.

Interestingly, though perhaps as expected, this outlook is more prevalent among heavy users of AI coding agents, where 37% agree that full replacement is possible. Those who rarely or never use agents remain much more skeptical.

We plan to share more insights on agentic development from the Developer Ecosystem Survey 2026 with the community soon. 

Stay tuned and subscribe to JetBrains Research updates below!

Methodology notes

In this report, “developers” refers to respondents who reported being involved in coding or programming in any of the following job roles:

• Developer / Programmer / Software Engineer
• AI / ML Engineer
• DevOps Engineer / Infrastructure Developer
• Architect
• Data Scientist / Data Engineer / Data Analyst
• QA Engineer

Roughly 90% of the total sample falls into the Developer / Programmer / Software Engineer job category.

The Developer Ecosystem surveys are localized into eight languages: English, Spanish, Chinese, Japanese, Korean, German, French, and Brazilian Portuguese. To ensure accurate global representation, we apply regional response quotas based on developer population estimates from our Data Science team (details are available here).

The Developer Ecosystem Survey has been statistically reweighted to better represent the global developer population by region, employment status, programming language, and familiarity with JetBrains products. Read more about our weighting methodology here.

This summer, I built a small experiment called ContextCue. The idea came from something I kept seeing during my internship. The engineers around me were using AI everywhere in the software development process. GitHub Copilot and Claude models helped with specs, code, reviews, and tests. The team also maintained reusable skills that taught coding agents how the team worked. One of those skills could take a UI design and turn it into working frontend code.

The code was moving faster, but the understanding around the code did not seem to move faster with it. The software was being built by nine teams spread across three continents, with one team working closely with the customer. A request might begin in a customer conversation, move through one team, then reach another team several time zones away. By the time the work reached engineering, some of the original meaning could be missing.

That was the problem I wanted ContextCue to explore. ContextCue takes recorded meetings and tries to preserve more than a transcript or summary. It keeps the spoken discussion, important visual context from the screen, the decisions that were made, the reasons behind them, and the source they came from. The goal is to create a shared piece of context that can move with the work from one team to another.

It is still an experiment, but the problem behind it felt very real. As far as I could see, a lot of time in distributed software teams went into reaching a common understanding before the coding even started. AI was already helping with the final stages of software development. I wanted to see whether it could help earlier, while teams were still trying to understand what they were building and why.

Where the context disappears

Meetings were already being recorded, and tools like Microsoft Teams could produce an AI summary. On my team, that summary often arrived as an email and stayed there. That worked well enough for the people who attended the meeting. It was less useful for the team that picked up the work later, especially if that team was in another country and had not seen the original conversation.

There were two other problems. A summary usually covered one meeting, while the understanding behind a feature was often built across several. Different teams might discuss the same request days apart, each adding a new constraint or interpretation.

A transcript could also miss important visual context. Many of our conversations involved screen sharing. Someone might point at a page and say, “This is too slow,” or highlight a part of a workflow while explaining what needed to change. The words alone did not always carry the meaning. That is where I started thinking about context as something larger than a transcript.

A simple example

Imagine that a customer asks for a “faster report.” During the call, the customer shares a screen, points at a page that is slow to open, and explains that managers use it every morning before a meeting. Everyone on that call understands that “faster” means the page should open more quickly.

Two days later, another team in another time zone discusses the same request. Nobody in that meeting saw the original screen. They read “faster report” as “the report should finish running sooner” and begin planning backend work. Both meeting summaries might contain the same phrase:

Make the report faster.

Nothing in that sentence shows that the two teams mean different things. The problem only becomes visible when the customer sees the result.

This is a simple example, but it captures the issue I kept noticing. Requirements move through people before they ever become code. If the meaning changes during that process, AI can help a team implement the wrong interpretation very efficiently.

The sports version of the same problem

Sports gave me another way to think about it. Imagine a soccer match where a player misses a late chance to score a goal. The match report can record the shot, the player, the minute, and whether it was on target. Those facts are useful, but a coach watching the replay sees much more. The winger may have delivered the ball too early. A defender may have forced the striker onto a weaker foot. A teammate may have made a run that opened the space.

The event is only one part of the story. A coach learns from the sequence around it.

Jake M. Hofman, Daniel G. Goldstein, and David M. Rothschild use a related sports framework in a Harvard Business Review article where they describe AI as a steroid, a sneaker, or a coach, depending on how it helps people. The “coach” idea is the one that stayed with me. A useful AI system does not only help people produce more. It can also help them make a better decision by bringing forward the evidence and experience that came before. That is close to what I wanted ContextCue to do for teams.

What I built

ContextCue starts with a meeting recording. FFmpeg handles the media, and Faster-Whisper transcribes the speech. The transcript is kept in time-stamped segments so that any later answer can point back to the moment where something was said.

The system also looks at selected frames from the screen share using a vision model such as Qwen VL. That helps preserve cases where the meaning depends on what someone was pointing at rather than only on the words they used.

The final output is organized around a request or decision instead of around a meeting. For example:

# Request: Faster report

What the customer meant:
The report page opens too slowly.
Source: customer call, shown on screen

Why it matters:
Managers open it before a morning meeting.
Source: customer call, spoken

What was planned:
Make the report finish running sooner.
Source: team planning meeting

Open issue
The current plan does not match the original request.

The format is deliberately simple. I used Markdown because a person can read it, a language model can use it, and it can be stored or versioned without depending on a special interface. When a later meeting touches the same request, the page can be updated rather than creating another disconnected summary. That changes the unit of memory from meeting to topic.

Why that matters for product work

One of the clearest uses I saw was product management. A product manager writing a user story usually works from some combination of tickets, meeting notes, customer feedback, and conversations with engineers. The important details are often spread across all of them.

If the product manager gives an AI model only the latest meeting summary, the model sees only one slice of the history. A ContextCue page can give it more. The page might contain the original customer request, the business reason behind it, a technical constraint raised later, a decision from product, and an unresolved question that still needs an answer.

That gives the model a much better starting point for creating a user story. The model itself has not changed. What improves is the material it has to work from. This is an important distinction because a lot of AI work focuses on prompts and models, while the quality of the context often decides whether the output is useful.

How the context grows

Each new meeting can update an existing page or start a new one. Over time, that creates a topic-by-topic record of how the work evolved. That is different from having a folder full of meeting summaries. A folder forces someone to remember which meeting contained the useful detail. A topic page collects the relevant pieces in one place.

The stored context can also be searched. I used embeddings and Qdrant to retrieve relevant parts of previous meetings. A question like “What did the customer mean by faster?” can return the answer along with the meeting and timestamp that support it.

Other requests need something more structured. “Find Tuesday’s meeting” is a lookup. “Why did we change this requirement?” may need information from several meetings. “What is still unresolved?” should look for open questions rather than just similar text.

ContextCue can expose those operations through the Model Context Protocol (MCP), so a language model can choose the right tool for the request. The main point is not the protocol itself. The useful part is that different types of questions can use different ways of accessing the same shared context.

Why recorded conversations are worth keeping

One study made me think recorded conversation was especially valuable. In “Generative AI at Work,” published in the Quarterly Journal of Economics in 2025, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied an AI assistant used by customer-support workers.

They found that lower-skill and less experienced workers improved the most. The system appeared to help them communicate more like higher-skill workers. What interested me was that some of the useful knowledge came from past conversations.

A company contains a lot of knowledge that never becomes a formal document. It appears in explanations, customer calls, design discussions, examples, corrections, and small decisions made during meetings. Recorded meetings are one place where that knowledge already exists.

The first benefit I noticed was personal

As an intern, one of the hardest parts of joining a large project is learning why things are the way they are. You can read the code and still not know why a certain design was chosen. A ticket may describe what to build without explaining the discussion that produced it.

The usual solution is to ask someone. That is often the right thing to do, but it also means interrupting someone who already has work to finish. A shared context layer could make some of those questions easier to answer without another meeting or another message across time zones.

The same idea could help with onboarding, repeated meetings, handoffs between teams, and situations where someone needs to understand an old decision. I can see those possibilities from where I sat as an intern, but they still need proper measurement.

What worked, and what is still hard

My testing so far is limited. I created a small set of questions where I already knew the correct source. ContextCue retrieved the right source first about nine times out of ten and returned it within the top three results every time in that test set.

That was encouraging, but it also made the harder parts of the problem clearer. A real company may use several different meeting tools. Different teams may have different rules about what can be recorded. Some context should be visible across the company, while other context should stay within a team. People need to know when meetings are being recorded and how those recordings will be used.

There is also a time problem. A team may make one decision in March and change it in April. The March decision should not disappear, because it explains how the team got to the current position. At the same time, the system should make it clear that the April decision replaced it.

That kind of history is useful, but it is more complicated than simple search. It requires rules around ownership, permissions, time, and trust. ContextCue does not solve all of that.

Where this goes

The thing that stayed with me from the internship was the contrast between how much AI had changed coding and how little it had changed the handoffs around coding. The engineers already had strong tools once a requirement was clear. The slower part often happened before that point, while teams were trying to understand a request, add constraints, pass it to another group, and keep everyone aligned.

ContextCue was my first attempt at working on that part of the process. The experiment is still small, and the technical system will need to change if it ever moves into a real company environment. The useful idea, for me, is that meeting recordings can become more than archives. They can become a shared record of how a team arrived at a decision.

If AI can help preserve that history and bring it forward when the next team needs it, then it may improve more than the speed of writing code. It may improve how teams carry understanding from one part of the organization to another.

You already have an AI assistant. It completes your code, explains code you didn’t write, and maybe even drafts a whole feature while you sip your coffee. An agent on GitLab picks up where your editor stops.

The AI in your editor only knows what's open in your editor. It doesn't know that your merge request has been sitting in the queue for two days, or that your pipeline failed for the third time this week. Without your pipeline logs, it can’t offer a fix.

GitLab Duo Agent Platform works within the project and across your software delivery workflow, taking into account merge requests, issues, pipelines, and repositories your whole team shares. This context makes all the difference.

Here are three ways to try out GitLab’s agentic features today, and you don't need a paid GitLab plan to do it.

Set up your group

On GitLab.com, a group Owner sets up your top-level group:

• Purchase GitLab Credits.
  • Go to Settings > Billing and select Purchase credits.
• Turn on GitLab Duo Agent Platform.
• Turn on foundational flows.
  • Go to Settings > GitLab Duo.
    • Select Change configuration.
    • Under Flow execution, select Allow flow execution and Allow foundational flows.
    • Select Code Review and Fix CI/CD Pipeline.
    • Select Save changes.

1. Hand off the first pass on reviews

Code Review Flow reads a merge request's diff, description, and related files (like tests and dependencies), then posts detailed review comments directly on the merge request. The flow catches small issues, missed edge cases, and inconsistent patterns on your merge requests, so you can save your judgment for the critical details.

Try it on your project:

1. On a merge request, assign @GitLabDuo as a reviewer, or comment /assign_reviewer @GitLabDuo.
2. Watch the review comments appear on the merge request itself, the same place your teammates will see them. Code Review Flow checks the diff, the description, and related files like tests and dependencies before it comments.

To hand off the first pass on every new merge request, turn on automatic reviews.

Watch how merge requests can speed up with Code Review Flow.

2. Send a failed pipeline to an agent to investigate

Have Fix CI/CD Pipeline Flow diagnose your failed pipeline and propose a fix, so you spend your time applying it instead of hunting for the cause.

This flow investigates logs, error messages, the merge request changes that likely caused it, and the repository contents. Depending on the failure, it either proposes an inline code suggestion on your merge request or opens a new merge request with a fix.

Try it on your project:

1. On a merge request with a failing pipeline, select Fix pipeline with Duo from the Overview or Pipelines tab. The flow reads the pipeline logs and your merge request changes to find the cause.
2. Select AI > Sessions to follow along, then review the result on your merge request. Depending on the failure, you get inline code suggestions you can apply, a new merge request if the fix touches files outside your diff, or a comment with next steps when a failure needs a person.

For pipelines that aren't tied to a merge request, you can trigger the same flow: go to Build > Pipelines, select the failing pipeline, and select Fix pipeline with Duo. You get a new merge request with the fix.

Follow along in our demo: How to Fix Broken Pipelines with GitLab Duo AI (Agentic Demo).

3. Get answers from across your project

Ask Agentic Chat what changed in a merge request or why last night's pipeline failed, and get one answer that pulls from your project's merge requests, issues, and pipelines. This is where most editor-based AI assistants fall short. Your IDE's assistant can tell you what a function does, but it can't tell you which issue introduced it or why last night's pipeline failed.

Try it on your project:

1. In the GitLab UI, open your project. In the GitLab Duo sidebar, select Add new chat, then select an agent. You can also use Agentic Chat in VS Code, JetBrains IDEs, and Visual Studio.
2. Make sure the Agentic toggle is turned on.
3. Ask what you'd normally dig for by hand. Agentic Chat searches your project's issues and merge requests by keyword and retrieves pipelines to build its answer. For ready-made prompts, browse the AI Resource Library, for example Summarize Recent Changes to MR/Issue or Debug Failing Pipeline.

You can also ask Agentic Chat to run either flow above on a merge request. Each chat message you send uses GitLab Credits.

Watch the demo: GitLab Duo Agentic Chat Demo: Automate Workflows with AI Agents

What these agentic features cost

On GitLab Free, you can use a set of GitLab Duo Agent Platform agents and flows, including all three above, without upgrading to Premium or Ultimate. Your group buys a monthly commitment pool of GitLab Credits that every group member draws from, so you pay for the work agents and flows do instead of paying per seat. The pool refreshes each month on an annual term. You can increase it at any time and decrease it at renewal.

Each feature uses credits at its own rate. For Agentic Chat and Fix CI/CD Pipeline Flow, usage depends on the model and on how much back-and-forth a request needs. The credit multiplier tables list current rates. Buying the pool also turns on on-demand billing for usage beyond it, so set usage caps to control spend.

Where to start

If you only try one this week, make it the Code Review Flow. Assign @GitLabDuo as a reviewer on your next merge request and see what it comes up with. From there, Agentic Chat and Fix CI/CD Pipeline Flow are ready to be deployed when you are.

Ready to get started? You can purchase GitLab Credits for your monthly commitment pool in your Customer Portal.