Operations | Monitoring | ITSM | DevOps | Cloud

Enterprises have reached a point where the pace of modernization no longer depends on the number of tools they deploy or the volume of telemetry they collect. Progress depends on whether teams can form a consistent and verifiable understanding of what is happening inside the environment. Many organizations do not realize that the single greatest barrier to modernization is the absence of operational truth.

The Enterprise AI Survey conducted by Digitate in collaboration with Sapio Research states that the journey of enterprise automation and AI adoption has evolved significantly. The initial waves focused primarily on improving accuracy, efficiency, and reducing costs. Now, the next phase, Agentic AI, is transforming this shift from mere automation to dynamic collaboration.

The Processing Engine is one of the most powerful features in InfluxDB 3. It lets you run Python code at the database—transforming data on ingest, running scheduled jobs, or serving HTTP requests—without spinning up external services or building middleware. You define the logic, attach it to a trigger, and the database handles the rest. Since launching the Processing Engine, we’ve been building out both the engine itself and the ecosystem of plugins that run on it.

This guest blog post is by Tohn Furutani, SRE Engineer at NTT DATA. Over the past year, the conversation around generative AI has shifted from single-shot use cases—such as summarization, Q&A, and chat interfaces—to agentic AI systems that can make decisions based on context, plan multistep actions, invoke tools, and adapt as conditions change.

Most "agent observability best practices" content reads like a compliance checklist from 2019 with "AI" pasted over "microservices." Implement comprehensive logging. Establish evaluation metrics. Create governance frameworks. Not a single line of code. No mention of what happens when your agent silently picks the wrong tool on turn 3 and you need to figure out why.

Today, Kosli and Adaptavist announce a strategic partnership to help regulated enterprises automate governance for AI driven software delivery - making it automated, continuous, and evidence-driven rather than a manual checkpoint that sits apart from DevOps and CI/CD. Adaptavist brings deep enterprise DevOps transformation expertise: assessment and strategy, DevSecOps integration, developer experience, and implementation across Atlassian, GitLab, and AWS.

Every engineering team wants to ship high-quality, reliable software quickly. Historically, engineers used a few guiding principles to help them consistently write clean code: keep code DRY, shift security left, write solid test cases, own your services, document your runbooks, and more.

At SREday NYC 2026, the ShipTalk podcast spoke with Phil Christianson, Chief Product Officer at Xurrent, for a leadership perspective on the intersection of product strategy, engineering investment, and platform reliability. While many of the conversations at the conference focused on tools, automation, and incident response, Phil offered a view from the C-suite level, where decisions about engineering priorities and R&D investment ultimately shape how reliability practices evolve.

When AI agents operate across a multi-module platform like Harness (from CI/CD to DevSecOps to FinOps), the number one goal is to give you answers that are correct, consistent, and grounded in real data. Getting there requires a deliberate architectural choice: when a question can be answered from structured platform data, the agent should use a schema-driven Knowledge Graph rather than raw API calls via MCP. The principle is simple: if the data is modeled, retrieval should be deterministic.

Infrastructure as Code (IaC) solves the provisioning problem. It doesn't solve the governance problem. You can version your Terraform configuration, run it in a pipeline, review every pull request — and still deploy an S3 bucket with public access, a VM with no encryption, or a resource that exceeds your cost budget. Nothing in the standard IaC workflow checks for those things. The reviewer has to know what to look for. And they won't catch it every time. Policy as Code changes that.