I have been thinking about the tool landscape that sits underneath modern IT departments. Not just ITSM tools, but also developer tools and observability platforms. The broader set of systems that help IT plan, build, operate, secure, govern, and support technology across an organisation.

This article is the start of an environmental scan and deeper dive into what this means for IT departments. Over the next few weeks, I’m going to look more closely at specific IT functions, including areas such as project management, portfolio management, risk, vendor management, licence management, security, privacy, infrastructure, observability, database management, and service management. Before diving into each area though, I wanted to step back and ask a more basic question.

How mature is the current IT tool landscape for AI usage?

That question matters because AI is starting to move beyond search, summarisation, and chat. In some tools, it is beginning to support triage, investigation, workflow execution, code changes, remediation, and operational decision support, which changes things.

The question is no longer just: Does this tool have AI?

It is: What kind of AI capability does it have, and is it mature enough for the work it is being asked to support?

What is it?

This environmental scan looks at the maturity of AI capability across the broad range of tools that support IT departments. The reason for doing the scan first is simple. IT is not one function, it is a collection of connected disciplines, each with different types of work, different risks, different processes, and likely different levels of readiness for AI.

A service desk tool, a security platform, a developer tool, an observability product, a vendor management system, and a portfolio management platform may all now claim to have AI, but they are not solving the same problem. Some AI capabilities help individuals work faster. Others support teams by improving access to knowledge, summarising activity, or assisting with analysis. Some are starting to behave more like operational agents that can investigate issues, suggest fixes, update systems, or trigger workflows. All are very different levels of maturity.

A useful way to frame the current landscape is through four broad categories.

1. Planning and workflow: These are platforms such as ServiceNow AI Agents, Atlassian Rovo, and Freshworks Freshservice Freddy. They sit closest to service management, collaboration, workflow, knowledge work, project activity, and internal service processes.
2. Engineering: This includes tools such as Anthropic Code, OpenAI Codex, GitHub Copilot, Google Gemini CLI, Amazon Q Developer, Docker, Inc Agent, and HashiCorp Terraform MCP Server. This is where some of the clearest evidence of MCP adoption is showing up, partly because engineering work already depends on repositories, infrastructure definitions, command-line tools, automation, and controlled execution.
3. Operations: This includes Cisco Cloud Control & AI Canvas, Dynatrace Intelligence, Datadog Bits AI, New Relic SRE Agent, BigPanda L1 Agent, Komodor AI SRE and Ciroos AI SRE Teammate. These tools are moving from visibility and dashboards toward investigation, triage, incident support, runbook execution, and operational remediation.
4. Security: This includes Elastic AI Assistant, ServiceNow SecOps, Palo Alto Networks AI Security and Cisco defensive AI agent direction. Security is already seeing practical AI use in alert summarisation, query generation, investigation, risk prioritisation, and controlled response.

This is not a perfect taxonomy, it’s a starting point. It shows that the market is not developing evenly. Engineering and operations appear to be moving faster toward agent-capable platforms. Security is also advancing quickly. Planning, portfolio, vendor, licence, privacy, and broader governance functions are still less mature from an agentic AI perspective.

The protocol picture is also uneven.

• MCP support is becoming visible, but it is concentrated. It seems to show up more clearly in engineering and platform-oriented tools such as GitHub, Amazon Q Developer CLI, Google Gemini CLI, Docker, Terraform, Atlassian, Datadog, and parts of the New Relic ecosystem. (No real surprise that it shows up in the more developer focused tools.)
• A2A support is much less mature.

That distinction is important. MCP is mostly about giving AI systems access to tools, context, and services. A2A is more about agents communicating and coordinating with other agents. A vendor may have useful AI agents without A2A. A tool may refer to MCP but only support it in a limited or ecosystem-level way.

The language in the market is moving faster than the maturity of many products.

What does it mean from a business perspective?

The first business implication is that “AI-enabled” is not a maturity level.

• A tool that summarises a ticket, drafts a response, or searches documentation can be useful. But that is not the same as a tool that investigates an incident, recommends a remediation path, updates a workflow, interacts with other systems, or executes an approved action.

• The risk profile changes as AI moves closer to action. (Becoming a common theme in my posts.) An assistant that helps someone write a service desk response is relatively low risk. An agent that changes a configuration, closes an alert, updates a record, or triggers a remediation workflow needs a different level of control.

The second implication is that value will show up differently across IT functions.

• Service Management: In service management, value may appear as faster triage, better routing, improved knowledge reuse, or reduced backlog.
• Operations: It may be faster incident analysis or better root-cause identification. In engineering, it may be improved developer productivity, test coverage, or infrastructure automation.
• Security. It may be faster investigation and stronger prioritisation.
• In portfolio management, vendor management, licence management, privacy, and risk, the value may be more about document-heavy work, evidence gathering, comparison, review, and decision support.

The third implication is that governance has to move into the workflow.

• It cannot sit only in policy documents. If AI is embedded in ITSM, observability, engineering, security, and automation platforms, governance has to show up in permissions, approval paths, logs, data access, escalation rules, human review, and audit evidence.
• Quality control also becomes a design issue. With traditional automation, the organisation defines a rule and the system follows it. With AI-enabled workflows, the system may interpret, infer, summarise, rank, recommend, or act based on changing context, which introduces variability. Do not treat all variability as unacceptable. Decide where it is acceptable, where human judgement is required, and where stronger controls are needed.
• Effort savings and duration savings are also different things. AI may reduce the work required to investigate an incident, draft a report, review a policy, or assess vendor responses. But the end-to-end duration may still depend on approvals, meetings, procurement cycles, stakeholder decisions, or change windows. This affects how value is measured. The useful measures are not just AI adoption counts. They are things like process cycle time, avoided effort, rework, quality, user adoption, improved consistency, faster triage, reduced backlog, better knowledge reuse, and stronger compliance evidence.
• Procurement also becomes more important. Buyers need to look past vendor language and ask practical questions - Is MCP support real product support or just ecosystem positioning? Is A2A available, on the roadmap, or simply aspirational? What actions can the AI take? What requires approval? Where are logs retained? How are permissions managed? How does rollback work? What happens to my data?

Those questions are not technical detail for the sake of it. They are how organisations separate useful capability from marketing language.

What do I do with it?

The practical starting point is not to create a large AI governance programme it is to build a simple view of where AI maturity exists across the IT toolset, then increase management discipline as the capability moves closer to operational action.

• Map the current tool landscape first. Start with the platforms already used across IT. What tools support service management, project delivery, portfolio management, infrastructure, observability, development, security, assets, vendors, licences, privacy, and governance? Which of those tools already include AI features?
• Separate assistance from action. Treat AI that helps people search, draft, summarise, analyse, and prepare differently from AI that updates systems, triggers workflows, runs commands, or communicates externally. The control model should not be the same
• Group tools by function before assessing maturity. Planning and workflow tools need different questions from engineering tools. Operations tools need different questions from security tools. A service desk agent, a coding agent, an SRE agent, and a security assistant may all be called “AI agents”, but they do not carry the same business risk.
• Validate protocol claims carefully. MCP support is becoming a useful signal, but vendors use the term differently (do they consume it or provide a server - or both, is the server cloud only or on-prem?). A2A is still much less mature at product level. Ask whether support is documented, available now, production-ready, and compatible with your security and operating model.
• Start with workflows where value and risk are understandable. Good candidates include service request triage, incident summarisation, knowledge search, meeting preparation, procurement support, vendor response analysis, policy comparison, report drafting, and backlog reduction. These are practical areas where AI can help without immediately handing over high-risk operational control.
• Use familiar management disciplines. This is not all new work. Service management, change control, access management, vendor management, security architecture, privacy review, audit, and operational risk still apply. The work is to adapt those disciplines to AI-enabled systems. (ITIL and COBIT anyone?)
• Involve procurement and vendor management early. AI capability is now part of product selection. Vendor assessments should include data handling, protocol support, model options, action controls, auditability, integration depth, roadmap credibility, and exit risk.
• Design for human accountability. Even where agents act, people remain accountable for outcomes. That means humans need enough visibility to understand what happened, enough control to intervene, and enough evidence to explain decisions later.

The point is not that IT should slow AI down. Done well, IT should help AI adoption become more useful, more repeatable, and more trusted. The conversation needs to move from “Does this tool have AI?” to “What role does this AI capability play in the operating model?”

That is one of the questions I’ll be carrying into the next set of deeper dives for each IT function.