devopsy.kinsta.cloud

Author: Mike Vizard

  • Ciroos.AI Preps AI SRE Agents Trained to Automate Incident Management

    Ciroos.AI Preps AI SRE Agents Trained to Automate Incident Management

    Ciroos.AI this week emerged from stealth to provide early access to a set of artificial intelligence (AI) agents that have been trained to augment site reliability engineers (SREs).

    Fresh off raising $21 million in additional funding, Ciroos.AI CEO Ronak Desai said the SRE Teammate provides access to multiple extensible AI agents that have been trained to proactively investigate anomalies without necessarily having to be directed.

    There is already a chronic shortage of SREs, so any tasks that can be assigned to AI agents is only going to reduce the stress level of existing teams, noted Desai. AI agents, for example, are already capable of reducing incident response times by up to 90% to enable SRE, he added.

    That capability will prove critical as the overall volume of applications deployed in production environments continues to steadily increase in the age of AI, noted Desai.

    The SRE Teammate platform makes use of the Model Context Protocol (MCP) developed by Anthropic and Agent2Agent (A2A) architecture defined by Google to enable AI agents to interact with each other.

    Ultimately, DevOps teams will soon consist of multiple autonomous agents that are supervised by software engineers to ensure tasks are completed as expected, said Desai.

    It’s not clear how quickly DevOps teams are embracing AI to manage workflows, but Futurum Group research finds 41% of survey respondents expect generative AI tools and platforms will be used to generate, review and test code.

    Even less apparent is the extent to which organizations will adopt AI copilots and agents that have been added to their existing platforms versus opting to acquire new platforms developed from the ground up for AI agents that are supervised by software engineers.

    Regardless of approach, many of the manual tasks that today conspire to make DevOps workflows more tedious will be eliminated. There is no doubt that will also change the role of software engineers, but the primary goal remains finding ways to leverage automation to enable organizations to deploy more applications in production environments that can run at higher levels of scale.

    Additionally, AI technologies should make DevOps tools and platforms more accessible to a wide range of organizations that previously could not afford the level of investment required.

    Each organization will, of course, need to determine the level of faith they are willing to place in AI. The challenge is that, given the current pace of innovation, the capabilities of an AI tool that might be made available in a few short months will be substantially higher than the current iteration. As such, DevOps teams need to base their overall strategy not just on what AI tools can do today but, more importantly, what kinds of capabilities will be available in the near future.

    In the meantime, DevOps teams would be well-advised to start making a list of tasks that are likely to be assigned to an AI agent with an eye toward determining how the role of software engineers will evolve from there.

  • Logz.io Unveils Observability Platform Designed First for AI Agents

    Logz.io Unveils Observability Platform Designed First for AI Agents

    Logz.io today launched an edition of its observability platform that is intended to be primarily used by artificial intelligence (AI) agents rather than DevOps engineers.

    Company CEO Tomer Levy said that as DevOps continues to evolve it’s become apparent that most tasks pertaining to observability will soon be assigned to AI agents. This edition of the Open 360 observability platform exposes machine-readable schemas alongside every panel, allowing AI agents to autonomously create charts, interpret anomalies and modify entire dashboards.

    Rather than simply adding a chat bot interface to an existing observability platform, Logz.io is moving to make it possible for DevOps engineers and AI agents to collaboratively observe complex IT environments using a common set of dashboards, said Levy.

    That approach still produces insights via a dashboard that can still be read by humans, but the assumption is that AI agents will be the primary end user of those dashboards, he added.

    Tasks assigned to those AI agents include executing custom playbooks created by DevOps teams, reviews of new application deployments, cost analysis and security assessments. AI agents can also automatically generate visualizations based on natural language requests, interpret and analyze anomalies in real time and interact with other agents to automate more complex tasks.

    Logz.io has already tested this AI agent-first approach with more than 200 IT organizations that have deployed more than 2,000 Logz.io AI Agents, resulting in saving a total of approximately 25,000 engineering hours this month alone—equivalent to 12 full-time SRE positions. At the current adoption rate, Logz.io projects customers will recover roughly 300,000 hours of engineering time over the next year.

    It’s not clear how extensively AI agents will change the way DevOps workflows are managed, but it is apparent that with the rise of AI coding tools, the number of applications being deployed by any organization is about to significantly increase. Most existing DevOps teams are not going to be able to keep pace with that rate of application development and deployment without being augmented in some way by AI agents.

    The challenge then becomes determining which tasks are best assigned to an AI agent versus those that still require the expertise of a DevOps engineer. Over time, however, DevOps engineers will find themselves supervising a small army of AI agents that have been trained to perform a range of specific tasks.

    Ultimately, AI agents should make applications both more resilient and secure as anomalous behavior is identified sooner. Armed with those insights, it then becomes feasible for application developers that are similarly augmented by AI agents to troubleshoot applications in a way that results in more issues being resolved long before they have any meaningful impact on the organization.

    In fact, AI agents should make it possible for more organizations to benefit from observability by proactively addressing application issues rather than simply continuing to monitor a set of pre-defined metrics that provide limited actionable intelligence. That, of course, might take some time for IT professionals to accept and fully trust, but in time, many of the tasks that conspire to make managing DevOps workflows more tedious will, like it or not, be increasingly performed by AI agents.

  • Postman Adds AI Agent Mode to Design, Build and Deploy APIs

    Postman Adds AI Agent Mode to Design, Build and Deploy APIs

    Postman today revealed it has developed artificial intelligence (AI) agents for its platform for designing and building application programming interfaces (APIs).

    Announced at the POST/CON 2025 event, the Agent Mode enables developers to, via a natural language interface, automate entire multi-step workflows spanning the designing, testing, documenting and monitoring of a single API or a logical group of APIs, known as collections.

    Postman CEO Abhinav Asthana said unlike an AI copilot, Agent Mode natively executes tasks in a way that understands the actual intent of an API developer.

    The overall goal is to reduce the amount of time required to build and deploy an API from weeks to a few hours using a set of repeatable workflows created by an AI agent, he added.

    Additionally, developers will be able to integrate the Postman agent with other AI agents via a model context protocol (MCP) server that Postman added last month.

    Finally, Postman is also committing to make it possible for developers to alternatively employ AI agents they create to build, develop and test APIs. Postman Insights, now available in a more open beta, will then provide the tools required to track usage of any API created in real time, noted Asthana.

    It’s still early days so far as usage of AI tools to build APIs is concerned, but reliance on them within AI applications is already pervasive. Based on data collected from the Postman API Platform between May 2023 and April 2025, developers made more than 7 million API requests involving AI. The OpenAI platform accounted for 60% of that activity, but API traffic involving Meta Llama and Google Gemini grew by a factor of seven and five, respectively.

    In total, there are more than 40 million developers that make use of Postman tools to build APIs for 500,000 organizations. The Postman API Network is being used to expose more than 100,000 of those APIs to drive multiple application services. As AI agents make it simpler for both developers and now non-technical end users to build and deploy APIs, the volume of activity is only going to continue to exponentially increase, noted Asthana.

    Each organization will need to determine how extensively to rely on AI agents to build and deploy APIs, but it will, if necessary, be possible to rollback any tasks completed by an AI agent, said Asthana.

    The one thing that is certain is that API documentation should substantially improve. Most application developers don’t especially enjoy creating documentation, which can be a significant issue whenever a DevOps team needs to troubleshoot an application.

    Hopefully, an AI agent trained to develop APIs will lead to higher quality. APIs, in particular, have become the focal point for cybersecurity attacks because in addition to enabling the exfiltration of data they can also be a vehicle for corrupting business logic.

    In the meantime, however, IT leaders in the months ahead might want to revisit not just how APIs are created, but also managed, secured and updated in the age of AI.

  • Survey Surfaces Uneven Adoption of SBOMs to Secure Software

    Survey Surfaces Uneven Adoption of SBOMs to Secure Software

    A survey of 100 security professionals finds nearly half (48%) of security professionals admit their organizations are falling behind on meeting software bill material (SBOM) requirements as specified by the U.S. Office of Management and Budget (OMB) Memo M-22-18, Executive Order 14028, and the European Union (EU) Cyber Resilience Act.

    Conducted during the recent RSAC conference by Lineaje, a provider of tools and services for securing software supply chains, the survey also finds a nearly equal percentage (47%) have either not started SBOM integration or are still evaluating tools and practices.

    Additionally, just over a third conceded their organization still has difficulty identifying and tracking open-source components in applications accurately, while nearly a third (29%) still lack the tools and processes needed to analyze SBOMs for vulnerabilities.

    As a result, only 38% of respondents said their organization prioritizes fixing the most vulnerable areas within their applications,

    On the plus side, a full (88%) of respondents expect artificial intelligence (AI) to have the potential to critically or significantly enhance software supply chain security visibility. At the same time, respondents are also aware that AI also introduces additional data security and privacy risks (35%) as well as potential vulnerabilities when used to write code (26%).

    Lineaje CISO Nick Mistry said AI should also make it simpler to determine whether a fix is available for a vulnerability. However, while there seems to be a lot of confidence being placed in the ability of AI to improve software supply chain security, there is still much work to be done, he added. In fact, it’s already been shown how ChatGPT can be used to create an exploit for 87% of known vulnerabilities, so the number of vulnerabilities that might be exploited is about to substantially increase, noted Mistry.

    AI tools have also experienced hallucinations that result in references to software packages that don’t exist. Cybercriminals are now creating software packages that bear the same name as part of an effort to fool developers into downloading software packages that have malicious code, said Mistry.

    Despite those concerns, however, just under a third (32%) of survey respondents said they believe their organization will one day deliver software that has no vulnerabilities. In contrast, 68% said they are uncertain that goal might ever be achieved.

    Ultimately, the ability to build and deploy secure applications comes down to processes. Unfortunately, most of the processes being used to identify vulnerabilities and then mitigate them are still flawed, said Mistry. There is still a tendency to create long lists of vulnerabilities that are then thrown over the proverbial wall for application developers to investigate. Much of that effort, however, is wasted when it is determined that an application that might have a vulnerability is either not externally accessible or the code suspected of having a vulnerability was never actually loaded into memory.

    More troubling still, 70% of the survey respondents admit that when a fix is not available for a vulnerability, they either don’t have or are not sure if they have an alternative remediation plan in place.

    It’s clear that organizations need a more unified view of vulnerabilities that will enable cybersecurity and application developers to work more collaboratively, noted Mistry. The challenge and the opportunity now is to provide those insights into software supply chain security in a way that enables everyone involved to see the same issues not just the same way, but also at the same time.

  • Redgate Extends Effort to Integrate Database Management and DevOps Workflows

    Redgate Extends Effort to Integrate Database Management and DevOps Workflows

    Redgate has updated its Flyway platform for applying DevOps workflows to database platforms to now provide deeper integration into command line interface (CLI) tools and integrated developer environments (IDEs).

    In addition, the Flyway platform now enables state-based deployments using scripts that can be generated based on a specific schema.

    Finally, Redgate is also adding options that enable DevOps teams to choose whether they want to include backups as baselines, automate the backup process altogether or never allow any type of shadow database.

    Max Drobot, group product manager at Redgate, said these latest additions are intended to make it simpler for software engineering teams with varying levels of maturity to start automating the management of databases within the context of a DevOps workflow. Rather than trying to create the perfect process, it’s now simpler for DevOps teams to more easily experiment with automating database deployments without increasing risks, he added.

    While DevOps engineers and database administrators (DBA) often need to work closely with one another, each of these teams has historically developed a separate culture around different classes of tools. Since it first launched Flyway, Redgate has been making a case for a platform that helps narrow that divide by enabling DevOps engineers to, for example, spin up a database when needed versus waiting for a DBA to have the time that would otherwise be required.

    That approach doesn’t eliminate the need for a DBA, but it does serve to reduce the overall level of friction that often exists between DevOps teams and DBAs, noted Drobot.

    The need to reduce that friction will become that much more pressing as the amount of data that needs to be incorporated into the next generation of artificial intelligence (AI) applications continues to exponentially increase, he added.

    Additionally, DevOps teams as part of building and deploying more secure applications will also eventually need to programmatically apply policies and guardrails to the data being accessed by their applications, noted Drobot.

    Managing databases has, of course, become more challenging as the number and types of them has steadily increased. Provisioning and managing databases using legacy manual processes is simply no longer tenable, he said.

    Many organizations are already embracing platform engineering as a methodology for managing DevOps workflows at scale, so it’s now more a question of when database operations will become more centrally managed within the context of a software development lifecycle (SDLC).

    In the meantime, DevOps teams might want to review how application developers are selecting databases for building applications today. All too often, rather than adhering to corporate standards, those decisions are based more on personal preference. In fact, it’s not uncommon for IT teams to find themselves spending time migrating an application developed on one database to another that the organization actually supports.

    Each organization will, of course, need to decide on its own to converge the management of DevOps and database operations but given the pace at which modern applications are now being developed and updated in the age of AI, the amount of pressure being applied to achieve that goal is only going to continue to increase.

  • Harness Adds MCP Server to Expose Data to Third-Party AI Tools

    Harness Adds MCP Server to Expose Data to Third-Party AI Tools

    Harness today revealed it has developed a model context protocol (MCP) server through which it will be able to provide more context to artificial intelligence (AI) tools, agents and platforms that are being used to build software.

    Rohan Gupta, a principal product manager for continuous delivery and AI DevOps for Harness, said exposing the data residing in the Harness continuous integration/continuous delivery (CI/CD) platform will streamline workflows by eliminating the need to rely on custom plug-ins and application programming interfaces (APIs) to provide additional context about the application development environments where code is ultimately deployed.

    Originally developed by Anthropic, MCP is based on a JSON-RPC 2.0 API framework and is rapidly becoming a de facto API standard for integrating AI tools, agents and platforms. The overall goal is to make it easier to expose relevant data to any AI agent that has permission to access it. The overall goal is to make it simpler for AI coding tools to more easily understand the reasons why, for example, a specific DevOps pipeline might have failed, said Gupta.

    DevOps teams will also be able to employ the role-based access controls (RBAC) provided by Harness to limit access to deployment logs only. All the API keys are managed through Harness and no data is ever sent to a large language model (LLM).

    It’s not clear how widely AI tools and platforms have been adopted but a Futurum Group survey finds 41% of respondents expect AI tools and platforms will be used to generate, review and test code, while 39% plan to make use of AI models based on machine learning algorithms.

    Ultimately, DevOps engineers will soon find themselves supervising a small army of AI agents with the help of what are becoming known as Planner agents, said Gupta. It remains to be seen how multiple AI agents will interact with one another to complete an end-to-end task but as orchestration frameworks continue to evolve there will be higher levels of interoperability between agents that both Harness and its third-party partners are continuing to build, said Gupta.

    In the meantime, DevOps teams might want to start creating an inventory of manual tasks that might soon be assigned to an AI agent. As the ability of these AI agents to reliably complete these tasks improves, DevOps engineers should be able to spend more of their time on activities that provide higher value to the business, he noted.

    Arguably, the next major challenge will be the cultural changes that will inevitably occur as more DevOps tasks are automated using AI agents that, for all intents and purposes, are now part of a DevOps team, added Gupta.

    Regardless of approach to building software, the expectation is that the data that AI agents need to write better code will be readily made available. Each organization will need to decide to what degree to trust AI technologies to build software themselves, but ultimately, as the pace of software innovation starts to accelerate in the age of AI, it may soon not be feasible to effectively compete without it.

  • New Relic Integrates AI Agents with Copilot Coding Agent from GitHub

    New Relic Integrates AI Agents with Copilot Coding Agent from GitHub

    New Relic this week made available a preview of an integration with the artificial intelligence (AI) agents it created for its observability platform with the AI agents that GitHub has developed.

    Nic Benders, chief technical strategist for New Relic, said AI agents that the company has developed will now be able to create an issue that GitHub Copilot will be able to use to improve an application. GitHub Copilot will analyze the issue, draft a fix, and submit a draft pull request for human review. The New Relic platform will then validate the change once it is merged.

    In effect, the New Relic and GitHub agents are creating a virtuous cycle to address incidents and performance as they arise, said Benders.

    Just as importantly, the New Relic agents are creating issues in a semi-structured format that is human readable, so DevOps teams will have the option of either assigning that task to a human developer or GitHub Copilot, he added.

    New Relic is making this capability initially available to eligible accounts that are also Copilot Pro+ or Copilot Enterprise users. Launched at the Microsoft Build 2025 conference, the GitHub Copilot coding agent is currently available as a preview to GitHub Copilot Enterprise customers and GitHub Copilot Pro+ users.

    While DevOps teams are making greater use of AI tools, it might be a few years yet before they are fully mastered, noted Benders. Using AI tools to generate code is one thing but integrating AI agents into DevOps workflows is a more complex endeavor, he noted.

    Nevertheless, a recent Futurum Group survey finds 41% of respondents expect AI tools and platforms will be used to generate, review and test code, while 39% plan to make use of AI models based on machine learning algorithms. The challenge now is identifying the specific tasks that might best be handled by an AI agent to reduce the overall amount of toil that goes into software engineering, said Benders.

    Ultimately, AI agents will also make DevOps teams less dependent on a confusing set of observability dashboards as AI agents begin to proactively discover issues, hopefully, before they have any significant adverse impact on application environments.

    Each organization will need to determine for themselves the degree to which they are comfortable relying on AI to build and deploy applications, but at this point, it’s more a question of how much rather than if. There are clearly productivity gains to be had so long as the work of AI agents remains closely supervised by DevOps engineers that have the expertise required to ensure that application quality is maintained and enhanced.

    In the meantime, DevOps teams should be aggressively experimenting with AI tools and platforms, said Benders. Like most powerful tools, it requires knowledge and expertise to get the most out of AI that only comes with hands-on experience, he added.

    After all, the DevOps goal has always been to automate as many tasks and workflows as possible. AI agents are only the latest in a long series of tools and platforms that enable DevOps teams to achieve that goal.