Every team building with AI right now is running the same experiment without realising it: dozens of tools evaluated in Slack threads, a handful adopted because someone senior tried them, a few quietly abandoned after a bad production incident nobody wrote up. That is not a technology strategy. It is institutional memory with no institution behind it.
That is why we started publishing the RUBINLAKE AI Technology Radar: a quarterly, evidence-based view of the AI, data, MLOps, governance, and developer-AI tools and practices we actually evaluate, trial, and recommend. This post explains why we built it, what a radar actually does that a spreadsheet cannot, and what our first edition, with 153 items across four quadrants, already tells us about where AI investment should and should not go in 2026.
The gap the radar exists to close
The numbers on mid-market AI adoption are stark. A 2026 Netrio survey found that 82% of mid-market IT leaders report using AI in production, but only 26% say that AI is scaled and governed enterprise-wide[1]. Separately, Salesforce research found 55% of employees admit to using AI tools their company never approved[2], and IBM reports that only 37% of organizations have any policy to detect that kind of shadow AI at all[3].
Put plainly: adoption is outrunning governance almost everywhere. Teams are shipping AI features and agent workflows faster than anyone is tracking which tools are trustworthy, which are experiments, and which should be actively avoided. That gap is exactly where expensive mistakes live. Most companies discover it only after an incident, not before one.
Gartner's own 2026 forecast underlines the stakes: over 40% of agentic AI projects will be canceled by the end of 2027, driven by escalating costs, unclear business value, and, critically, inadequate risk controls[4]. A technology radar will not fix a bad business case. But it does force the risk-control conversation to happen before the project starts, not after the postmortem.
What a technology radar actually does
The format itself is not new. Thoughtworks has published its Technology Radar twice yearly for over a decade[5], and a handful of companies including Zalando and Digitec Galaxus maintain public ones of their own[6][7]. What makes the format useful is the specific distinction it draws that a feature comparison spreadsheet cannot: the difference between "we use this," "we should try this," "we are watching this," and "we tried this and it caused problems."
We organize every entry, or blip, along two dimensions:
Four rings, by confidence:
| Ring | Meaning |
|---|---|
| Adopt | Mature and valuable enough that teams need a clear reason not to use it. |
| Trial | Worth running on a real project with explicit success criteria and an owner. |
| Assess | Promising or strategically important, but not yet backed by enough evidence for production. |
| Hold | Avoid for new work unless there is a documented, deliberate exception. |
Four quadrants, by topic: AI & Data Engineering, Data Platforms & MLOps, AI Security & Governance, and Developer AI & Delivery.
Crucially, ring placement matters more than quadrant. Two tools in the same quadrant can carry opposite recommendations, and that is the entire point: the radar makes an implicit decision explicit and puts it somewhere the whole company can see and challenge it.
What our first edition found
Our May 2026 edition covers 153 items. The distribution alone is instructive:
- 24 items in Adopt (16%)
- 49 items in Trial (32%)
- 60 items in Assess (39%)
- 20 items in Hold (13%)
Fewer than one in six entries has earned our strongest recommendation. That ratio is not caution for its own sake. It reflects how young most of this stack still is. Most of what teams are excited about right now genuinely belongs in Trial or Assess, not in a standardization mandate.
What actually earned "Adopt"
The Adopt ring skews toward tools with multi-year production track records and coding agents that have crossed from novelty into daily-driver status: Claude Code, GitHub Copilot, and Cursor on the developer side; dbt Core and Cloud and Databricks Lakehouse on the data platform side; and, notably, Zero Trust Architecture for AI Agents, Prompt Injection Defenses, and AI Risk Governance Frameworks in security and governance.
That last group matters more than it might look at first glance. Half of our Adopt-ring governance items are controls, not capabilities. We are not saying "adopt more AI". We are saying that if you are running AI in production, a specific set of controls has crossed from best practice into baseline expectation.
What we are actively telling teams to avoid
Twenty items sit in Hold, and they are as instructive as the Adopt list. Prompt-Only AI Governance, where a team writes a system prompt that tells the model to behave and calls that its safety strategy, sits in Hold. So does MCP by Default, wiring up Model Context Protocol servers without a threat model for what an agent can now reach. So does Fully Autonomous SDLC Agents, which means letting an agent plan, code, test, and ship without a human checkpoint anywhere in the loop.
None of these are hypothetical risks. They are the specific shapes we have seen "AI accelerated shadow IT" and avoidable production incidents take in practice, generalized into a pattern so a team can recognize it before they build it, not after.
What we are watching
The Assess ring is the largest for a reason: it is where the real experimentation is happening right now. Context Engineering is still in Trial, edging toward Adopt as more teams report production results, while Structured Outputs from LLMs has already crossed into Adopt this edition. Multi-agent orchestration frameworks, agent-to-agent protocols, and several coding-agent platforms are still earning their evidence in Assess and Trial. We have even placed our own category of agent tooling under evaluation here. Hermes Agent sits in Assess, which is exactly where a new pattern should sit before anyone commits production traffic to it.
Why we are publishing this, not just using it internally
We could have kept this as an internal document. We chose to publish it for the same reason we run applied AI and market-intelligence consulting in the first place: the mid-market companies we work with are making these same adopt-or-hold decisions with far less evidence than a dedicated research team can gather, and far less time to gather it themselves.
A public radar does three things a private one cannot:
- It forces us to write down our reasoning, not just our conclusion. Every entry states adoption signals, risks, and a recommendation, so the "why" survives even when the person who made the call moves to a different project.
- It gives our clients and readers a second opinion they can check against their own vendor conversations before signing a contract.
- It ages in public. When we move something from Trial to Hold next quarter, that is a visible, accountable correction, not a quiet internal memo nobody outside the team ever sees.
How to use a radar like this
If you are evaluating whether your own team needs something like this, the practical rule is simple: start with Adopt and Hold. Adopt items are your default; you need a reason to deviate. Hold items are your stop signs; you need a documented, deliberate exception to use them in new work. Everything in Trial and Assess is where you run bounded experiments: one owner, one metric, one exit decision, reviewed on a schedule rather than left to run forever.
That discipline of writing down the recommendation, attaching evidence, and revisiting it every quarter is the entire value of the format. It will not make your agentic AI project succeed on its own. But it makes the difference between a team that can say exactly why it chose a tool and a team that finds out why six months into an incident review.
You can explore every entry, ring, and quadrant in the full RUBINLAKE AI Technology Radar, including the complete methodology behind how we place and move items each quarter.
