devopsy.kinsta.cloud

Category: AI

  • Datadog Adds Raft of Additional AI Agents and Tools to Portfolio

    Datadog Adds Raft of Additional AI Agents and Tools to Portfolio

    Datadog at its DASH 2025 conference today previewed a raft of artificial intelligence (AI) agents that automate tasks ranging from assessing infrastructure alerts that normally require the expertise of a site reliability engineer (SRE), to fixing code and triaging cybersecurity issues using the company’s security information event management (SIEM) platform.

    In addition, Datadog is also adding Proactive App Recommendations that analyze telemetry data to suggest the next best action and APM Investigator to identify and trouble shoot bottlenecks impacting application performance.

    At the same time, Datadog is adding data observability tools, along with extensions to its service for monitoring large language models (LLMs), to add support for AI agents and previews of tools to test and validate the impact of prompt changes, model swaps or application changes on the performance of LLM applications. The company has also added an AI Agents Console to make it simpler to discover and invoke its AI agents. Datadog LLM Observability, now generally available, monitors the integrity of AI models and performs toxicity checks that look for harmful behavior across prompts and responses, while Datadog Workload Protection monitors interactions between LLMs and their host platforms. A Datadog Cloud Security and Sensitive Data Scanner (SDS) also enables organizations to meet compliance requirements.

    Datadog is also making generally available Datadog Code Security, a service that leverages AI to detect, prioritize and remediate vulnerabilities in their custom code and open-source libraries based on runtime threat activity and business impact. It has also extended the capabilities of its log management suite to run in an on-premises IT environment—meeting data sovereignty requirements in regulated industries—and to help reduce costs with a lower-cost archive tier of storage.

    Finally, Datadog has added a managed internal developer portal (IDP) that is integrated with the company’s core application performance monitoring platform. It provides a live system of record for telemetry data to surface what software is running, who is responsible for it, and how it is performing. There are also templates powered by Datadog’s App Builder and Workflow Automation to automate tasks such as creating the scaffolding for a new service along with engineering reports and scorecards to track compliance, reliability, security, observability, cost and other metrics.

    In general, Datadog is making use of a range of proprietary and open source LLMs, including one optimized for time-series data that it has developed. Over time, Datadog plans to mix and match LLMs to address specific use cases as additional AI advances are made.

    Michael Whetten, vice president of product for Datadog, said, for example, the latest Bits AI SRE, Bits AI Dev Agent and Bits AI Security Analyst agents not only extend the range of tasks being automated, but also enables them to query data, analyze anomalies or scale infrastructure using shared memory in a way makes it possible for AI agents to reuse functions. Datadog has also developed a Model Context Protocol (MCP) server to make it simpler for AI agents to consume its data and interoperate with each other. The overall goal is to not, for example, replace SREs, but rather augment their expertise in a way that makes it easier to manage complex IT environments, he added.

    It’s still early days so far as adoption of AI technologies across DevOps workflows is concerned, but a recent Futurum Research survey finds 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code. In fact, arguably the challenge now is not so much deciding whether to use AI as much as it is determining where AI will have the biggest impact on improving both software quality and the speed at which applications are deployed.

  • 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.

  • This Bankrupt AI Startup Was More Artificial Than Intelligent

    This Bankrupt AI Startup Was More Artificial Than Intelligent

    It turns out Builder.ai was more artificial than intelligent.

    The $1.5 billion artificial intelligence (AI) company backed by Microsoft Corp. recently shuttered operations after its neural network was exposed to actually be 700 engineers in India.

    Builder.ai, which has begun formal bankruptcy proceedings in jurisdictions where it operated, including India, the U.K., and the U.S., said on LinkedIn it would be “entering into insolvency proceedings.”

    “Despite the tireless efforts of our current team and exploring every possible option, the business has been unable to recover from historic challenges and past decisions that placed significant strain on its financial position,” the company wrote.

    The company’s Natasha, an AI app-building service, helped it land a strategic collaboration and “significant” investment with Microsoft two years ago. At the time, Builder.ai CEO Sachin Dev Duggal said, “From my first meeting with Microsoft to the moment we agreed to collaborate more strategically, one thing has been really clear — Microsoft’s commitment to helping everyone unlock their true potential.”

    Documents reviewed by Bloomberg showed Builder worked with VerSe, an India-based social media startup, to falsely increase its sales numbers, regularly billing each other for similar amounts between 2021 and 2024. “We’re not the kind of company that is in the business of inflating revenues,” VerSe co-founder Umang Bedi told Bloomberg, calling the accusations “baseless and false.”

    The sudden rise and fall of Builder.ai serves as a cautionary tale in an industry overflowing in hype, and one susceptible at times to scams. Since it was founded in 2016, the company originally known as Engineering.ai has been embroiled in scandal. It promised to make software creation “as easy as ordering pizza” and marketed its AI assistant, Natasha, as a breakthrough in building software with minimal human input.

    At its peak, Builder.ai raised more than $450 million from the likes of Microsoft, SoftBank’s DeepCore, and IFC to reach a valuation of $1.5 billion.

    But there were cracks in the corporate facade.

    Employees and outsiders pointed out Builder.ai relied on about 700 engineers in India who manually wrote code for client projects while the company misrepresented the work as AI-generated.

    Former employee Robert Holdheim sued the company for $5 million, alleging he was fired after flagging concerns over deceptive practices. Legal filings subsequently revealed Builder.ai misled investors by claiming apps were “80% built” by AI though the supporting tech was barely functional. A 2019 investigation by the Wall Street Journal found most of the coding was done manually.

    And the saga of Builder.ai is far from over: The company reportedly owes $85 million to Amazon.com Inc. and $30 million to Microsoft in unpaid cloud services. A U.S. federal probe is underway, with investigators seeking access to its financial and client data.

  • Managing Day 2 Concerns for Agentic AI Architecture

    Managing Day 2 Concerns for Agentic AI Architecture

    We’re now in the fifth wave of computing. If that sounds dramatic, that’s because it is—and probably also because someone in marketing really wants to make “agentic AI” stick. For those keeping track at home, the first four waves were mainframes (your granddad’s computer), web (when we were all hopeful), cloud (when we were still kind of hopeful), and mobile (where that hope became a subscription to your attention span).

    And now? Agentic AI.

    Let’s get the buzzwords out of the way: Agentic AI is a fancy term for giving large language models (LLMs) persistent memory, looping logic, and callbacks to reach out to your APIs. It’s like giving a Roomba a graduate degree and asking it to run your IT department. These “agents” operate independently (ish), have goals (ish), and make decisions (ish) based on prompts, semantic search and however much context you can cram into a vector database.

    Sounds fantastic. Until you have to operate and maintain this stuff in production.

    Because Day 1 is always a party, demos run great on slide decks. Day 2 is when the ops team walks into the room, sees the cloud bill, and quietly walks back out.

    The Scale Problem (a.k.a. We Broke TPS)

    Let’s talk about scale. Traditional systems had thousands to millions of users. With mobile, we got billions. Agentic AI? Try trillions. Not just people, though. You’ll have agents helping users, agents helping agents and agents judging the work done by other agents. 

    Mainframe

    Web

    Cloud

    Mobile

    Agentic

    Users

    thousands

    millions

    100 million

    billions

    trillions

    TPS

    100

    500

    2,500

    10,000

    1,000,000

    5x

    5x

    4x

    100x

    Each one of those agents runs loops. Each loop makes calls. Each call hits an LLM. Every LLM call contributes to Transactions Per Second (TPS). Not all transactions or LLM interactions are the same. Humans have very different behavior than agents.

    The types of interaction behavior we might see:

    • Human users = finite and sleepy
    • Agents = infinite and caffeinated
    • LLM inference = expensive, slow, and shockingly unreliable
    • Therefore: system load = Who knows? How do we even predict this stuff?

    It isn’t unusual for pre-agentic systems to max out around 10,000 TPS. Agentic systems? You’re looking at a million TPS just to hit parity with your company’s Slack usage.

    But What About Cost?

    Ah yes, the CFO’s favorite section.

    Running agents is expensive. Running smart agents is very expensive. Running smart agents 24/7 with high-accuracy LLMs? Welcome to a world where your annual AI ops bill might be an order of magnitude higher than it was before.

    Let’s put that in relatable terms:

    • GPT-4 32K (86% accuracy): $98 per million tokens
    • Open source model (42% accuracy): $0.013 per million tokens
    • Database transaction: pocket change by comparison

    And don’t let the open-source optimism fool you. A 42% accurate agent might write emails like “Dear Sir/Madman, I have eaten the spreadsheet,” which is cute until it’s running your treasury. Remember that hallucinations and bad responses are so common, we already have patterns for using multiple other LLMs just to judge the work of the first. This means that your cost isn’t just the cost to ask an LLM an innocent question, it’s the cost to resolve tools, cost to make the actual request and cost to make potentially multiple judgment requests.

    So now you’re faced with the AI version of the eternal tradeoff: dumb and cheap vs. smart and broke.

    Latency, Reliability and Other Sad Stories

    LLMs are not built for low-latency, high-throughput work. They’re built for… storytelling. And hallucinating. And sometimes – if you ask nicely and are an expert in prompt engineering – even answering your questions.

    Now, imagine your core systems relying on that. Imagine your uptime metrics depending on the whims of an LLM inference API that thinks “return customer data” means “find a retail location where customers can bring and return their data”

    Agentic systems aren’t transactional. They’re conversational. They’re unpredictable. They can fail to give you an answer, they can stop answering in the middle of a stream. Don’t listen to what people tell you, you can’t blindly trust an LLM.

    And yet, we keep trying to run them like traditional software. We build orchestration platforms, routing layers, retry loops, and cost governors. Why? Because otherwise, these things will try to eat the entire internet in a single for-loop and send us the cloud bill.

    Capacity Planning Is Now Chaos Planning

    You used to think about load in terms of peak usage. Now? Your agents don’t sleep. They don’t go to lunch. They just keep going, looping away, slamming vector DBs and semantic search engines with relentless, existential enthusiasm. Your system lows are higher, your median times are higher, and your peaks are higher.

    This means:

    • Your database load goes up 100x
    • Your network saturates under constant agent chatter
    • Your infrastructure team turns into a stress-testing experiment
    • And you still get worse answers than just asking the intern

    You don’t plan for “peak load” anymore. You plan for “non-stop Reddit debates between bots.”

    The Blueprint (Such as It Is)

    In theory, building a sustainable agentic architecture looks like this:

    1. Semantic Search – All your domain knowledge gets shoved into a vector DB, ready to be retrieved by semantic similarity.
    2. Agentic Sessions – Every agent interaction is logged to provide context, continuity and accountability.
    3. LLM Invocation Loops – Prompt, retrieve, augment, call LLM, process, repeat until you get a satisfactory answer, or you run out of usage quota.
    4. Orchestration Layer – The puppet master that tells agents what to do, when, and for how long before they bankrupt you.

    This is all manageable, assuming you can hire a team of distributed systems engineers who also speak fluent “prompt engineering,” understand vector math, and have no plans for sleep.

    What Ops Teams Need to Do (Besides Cry)

    If you’re serious about building something in this space—and not just gluing ChatGPT to your CI pipeline, you need to:

    • Plan for real-time TPS: Millions of them, all at once, with unpredictable spikes.
    • Plan for augmentation (RAG): Simple one-off queries are rare. Instead, your agents will be making multiple round trips to the LLM to resolve tools and multiple passes at a vector database for context augmentation.
    • Instrument your agents: Know which model they’re using, how often, and at what cost.
    • Design for failure: Assume models will hallucinate, APIs will fail and your agents will suddenly think they’re writing sci-fi.
    • Stay modular: You’ll want to swap models faster than your CFO can say “cost optimization.”

    Final Thought: The AI Agency Gap

    The AI Agency Gap is the chasm between dumb bots and actual autonomous systems. It’s the space where most agents will live—semi-capable, semi-stable, semi-helpful. They’re the interns of the software world: energetic, inconsistent and always one bad prompt away from disaster.

    If you want to thrive in this new wave of computing, you’re going to need resilience, observability, guard rails, patience and some really good stress coping techniques. The future isn’t just about building agentic systems, it’s about knowing that you’ve made all of your microservices unpredictable and require 10x more resources.

    Good luck.

  • 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.