Move Fast and Fix Stuff: Revising Our Agentic AI Taxonomy

Things move fast in our world. In just the past few weeks, we’ve watched a steady stream of Agentic AI releases that change the landscape, shifting what enterprise security teams need to worry about. For instance, just this week Anthropic introduced Claude Tag, which lets teams bring Claude into a Slack channel as a working team member, along with a new agent identity access model that gives the agent its own accounts and permissions rather than borrowing a user’s. Recently, OpenAI laid out its vision for enterprise agents that move across a company’s systems and data instead of living inside a single product. And Google has been pushing hard on multi-agent orchestration with Antigravity and the A2A protocol where one agent can coordinate others to work in parallel.

As things in our landscape advance, we’re learning right alongside everyone else. And part of learning is making sure we present our thinking as clearly as we possibly can.

With that in mind, we’ve decided to revise the agentic AI taxonomy we’ve been using so far. The first two posts in this series organized agents into web-based, SaaS platform, and custom buckets. That structure served us well, but as the landscape shifted, we found gaps that were worth fixing.

Here’s specifically why we made the change.

First, there’s a clear distinction between vendor-created and enterprise-created agents that needed to be called out explicitly, and which depend on where and how the agent is running. These two worlds have very different control surfaces. When the vendor builds and runs the agent, your levers are configuration, identity, and connections to your resources . When your own teams build it, you own the entire stack. And, there are in-between types, such as no-code agentic platforms. These distinctions deserve to be front and center.

Second, we realized we needed to capture the type of access an agent has. There’s a meaningful difference between an agent that runs entirely in a vendor’s cloud and one that has a foothold on your endpoint, with access to your files, your shell, and your local credentials. That difference drives which controls actually apply, so we made it part of the structure.

Finally, we’ve defined a set of attributes to use as a consistent lens for analyzing each type of agent. We talked about data and autonomy in the earlier posts, and those remain central. We’re adding management, lifecycle, and identity to round out the picture. Identity in particular has become essential. When an agent acts under its own distinct identity rather than on behalf of a user, as Claude Tag and custom enterprise agents do, the questions you need to ask change considerably.

We think this new taxonomy is a clear improvement, and a more future-proof one as well. We looked at how things have shifted over the past several months and extrapolated forward, and we believe this model will hold up better as the next round of changes arrives. It already does a noticeably better job of placing newer offerings. Claude Tag is a good example. Under the old structure it didn’t fit cleanly anywhere. Under the new one, it lands naturally as a vendor-operated agent acting under its own identity, and the attributes tell you exactly what to scrutinize.

We’re looking forward to rolling this out over the coming posts and walking through each category in depth, along with the practical controls and recommendations that go with them. As always, we’d love your feedback as we go, so please stay tuned and let us know what you think.