Aleksandr Surkov

In article 16, we talked about the principles of mature multi-agent work: plan-and-execute, a separate critic, rubric-based review, Reflexion, context control, step logging, and a clear stopping point. In article 17, we looked at how these approaches can be assembled technically using an agent framework. In article 18, we discussed why GitHub Copilot is especially useful inside the IDE: next to the code, files, terminal, and the real state of the project. After that, the next practical question appears: if this working pattern has already proved useful several times, how do we stop rebuilding it from scratch in every new repository? I tried to find an answer to that question in my own project, ForgentFramework. Let’s dive into it and see what I ended up with.

In the previous article, we looked at Microsoft Agent Framework as a way to technically assemble an agent system: with separate agents, workflows, tools, state, middleware, hosting, and observability. This approach works well when we are building our own solution or a closed production system around a clearly defined process. But in day-to-day DevOps work, the task often looks different. You do not need to design an agent platform from scratch. You need to quickly understand a specific repository: open the pipeline configuration, inspect the web application Dockerfile, check the Dockerfile for the background process, understand the project structure, compare it with the instructions, and, if necessary, run commands in the terminal. You can build your own agent system for this, but it takes time and is not always justified. In such scenarios, a tool that already lives inside the developer’s working environment and can work next to the code, files, terminal, and project context is much more valuable. This is exactly where GitHub Copilot in Visual Studio Code becomes interesting.

In the previous article, I discussed the idea of multi-agent work itself: why it makes sense to split a long task into several roles, and why one universal agent starts to struggle fairly quickly. But how do we move from theory to practice? After all, the question is not only about inventing the roles of orchestrator, executor, and critic and writing prompts for them. We need to understand how exactly the agents will interact, where the state will live, how tools will be connected, when a single agent is enough, and when an explicit workflow is already needed. One of the solutions is Microsoft Agent Framework. Let’s take a closer look at it.

In the previous article, I talked about a single agent as a working tool for DevOps tasks. We looked at how an agent can be useful while the task remains local: gathering context, analyzing configuration, finding a weak spot in a pipeline, or preparing a draft solution. But as soon as the task becomes longer, problems can appear. You may need to separately gather context about the pipeline, then check a Dockerfile or a deployment script, and then, for example, understand whether the proposed fix introduces a new risk for the release or operations. In a single pass, this kind of work starts to sprawl, the agent’s focus gets lost, and efficiency begins to drop. At this point, one agent starts mixing several types of work at once. It plans, executes, checks itself, and carries all the accumulated context. For a short task, this is still tolerable. For a long one, it starts to break down. And this is where the solution becomes splitting the work into several roles, each handled by a separate AI agent.

People are talking about agents and AI everywhere now, and a lot. Usually, the conversation quickly drifts into one of two extremes. Either someone claims that such tools will soon replace a significant share of specialists, or everything gets reduced to a regular chat with a model, followed by the conclusion that there is nothing fundamentally new here. But in practice, as usual, things look different. In DevOps, for example, agents are unlikely to fully replace a person for now. But as a tool that helps solve routine tasks faster, they perform extremely well. Studying project context, reviewing configurations, reading logs, finding differences between environments, and even working on automation scripts — the real effect shows up precisely in these everyday and often tedious activities. AI does not replace the engineer. But an engineer who understands how to use such a tool, and where to apply it, can become several times more effective.

Migrating legacy applications to the cloud is full of surprises. Usually, you expect problems in the code, infrastructure, or CI/CD pipeline, but in practice almost anything can surface. This time, everything stumbled over Crystal Reports… Let’s look at how we managed to migrate a legacy application built on classic ASP.NET, using Crystal Reports for report generation, to Azure App Service.

When people talk about sending email from an enterprise system, they usually mean that an application connects to an SMTP server, builds an email, and sends it on behalf of the business logic. However, when the business logic lives inside SQL Server — and this is common in legacy systems — a different approach is needed. What should you do if an email has to be sent directly from a stored procedure, a SQL Agent job, or a scheduled processing routine? In SQL Server, this is usually done with Database Mail and the sp_send_dbmail procedure. Let’s look at how to set it up.

In web applications, file-handling functionality is very common: upload a file, store it somewhere, and then serve it back to the user via a link. These files might be PDFs, images, CSVs, or other documents that the application does not generate on the fly but simply stores and later displays in the browser. The most obvious solution is to place those files on the local disk of the machine where IIS is installed. For a small solution, that can work perfectly well. But as soon as the system becomes a bit more serious, reasonable questions start to arise: how reliable is it, really, to keep user files on the disk of a specific host? If that host gets damaged, recreated, migrated, or simply maintained in an unexpected way, the file layer quickly becomes a problem of its own. At the same time, you do not always want to move straight to Blob Storage and completely change the application’s file-handling model. Sometimes it is more convenient to preserve the familiar Windows and IIS approach: folders, UNC paths, a file system, and standard file delivery through the web server. In that scenario, Azure Files mounted over SMB is a good compromise. Below, let’s look at this approach as an engineering task: how to connect an Azure File Share to Windows Server, how to configure IIS, why permissions almost always become an issue here, and how to make the whole setup actually work.

This article is dedicated to a common issue frequently encountered when automating infrastructure with Azure DevOps: the second hop problem. We’ll examine why this problem occurs and how to effectively resolve it to ensure seamless integration and automation.

Working with Azure Linux virtual machines through Azure DevOps can be challenging when SSH access is required without using service connections. Standard Azure DevOps tasks assume the existence of a preconfigured service connection, making it inconvenient and inefficient to work with dynamically created or temporary virtual machines. This article explores ways to solve this issue.

When it comes to accessing Azure virtual machines running Windows, most people immediately think of the familiar Remote Desktop Protocol (RDP). However, in automation, CI/CD, and DevOps scenarios, a more flexible and automated approach is often required. PowerShell Remoting provides a convenient and secure alternative to traditional RDP, enabling fast, secure, and automated VM management. In this article, you'll learn how to configure and use PowerShell Remote to efficiently manage Azure Windows VMs.

The security of virtual machines in the cloud is not something you can postpone. Just-In-Time (JIT) access to virtual machines in Azure significantly reduces the risk of unauthorized access by granting access only when necessary and only for a limited time. In this article, we’ll dive deep into how to effectively use JIT in Azure, configure access via the Azure portal and Azure PowerShell, open specific ports on demand, and integrate the entire process into Azure DevOps pipelines to ensure maximum automation and security.

Initially, I intended to write an article about the practice of using yaml templates in Azure DevOps to encapsulate repeatable steps in pipelines. But during the writing process, I realized that boring references to documentation and simple examples of yaml files would not be so interesting without tying them to some scenario. Thus, a short, purely technical article turned into a large text dedicated to several topics, each of which is interesting in itself. As a result, I decided to turn this text into a mini-series of articles. Here comes the second part, dedicated to using YAML templates in Azure DevOps, focusing specifically on passing parameters to and from the templates.

Initially, I intended to write an article about the practice of using yaml templates in Azure DevOps to encapsulate repeatable steps in pipelines. But during the writing process, I realized that boring references to documentation and simple examples of yaml files would not be so interesting without tying them to some scenario. Thus, a short, purely technical article turned into a large text dedicated to several topics, each of which is interesting in itself. As a result, I decided to turn this text into a mini-series of articles. Welcome to the first part, dedicated to automated testing, where I will give a brief overview of software testing approach and describe a scenario that we will automate using yaml pipelines with templates in the next article.

Today, anyone heard the words artificial intelligence, neural networks, ChatGPT . The topic is so relevant and important that it is simply impossible to pass it by. In this article, I will discuss a little about what modern artificial intelligence is and tell you about the services that you can use in Azure to work with neural networks.

Not so far ago, I ran into a situation where one of our Azure DevOps deployment agents disappeared from the network. Everything was fine with the machine, the Internet worked on it, the firewall settings and the Network Security Group were also good, but Azure DevOps stopped seeing the agent. What happened and how did we fix it? Welcome to the article.

Last time, we figured out how the cloud works at the lowest level. And now I suggest you look inside the cloud from the other side. I think that everyone knows what serverless functions are (those who do not know, go to the article anyway - you will find out there :). An example of such serverless technologies is Azure Functions, one of the most powerful tools that allows you to easily and elegantly solve many computational problems. So let's figure out how serverless functions work and there really are no servers there...

In continuation of my thoughts about the internal structure of clouds, today I would like to reflect on how it is generally they work inside from the point of view of IT engineering. Let's try to think of what layers and blocks Microsoft Azure can consist of.

After discussing how data centers work, I would like to add a few words about ensuring reliability and security within teams working in cloud vendors. I have some experience working for a cloud provider, and below I will list a few points that are mandatory for any cloud vendor's employees to follow.

Cloud technologies became a big and important part of our live and in most cases, modern IT engineers can’t imagine their work without interacting with cloud services. But, clouds don't work by themselves somewhere in the sky. Somewhere on our planet, there are data centers with a lot of servers that host all SaaS, PaaS and IaaS services we use. In this article, I will talk a little about data centers - “whales” on which clouds stand.