There's a big problem happening with companies adopting AI right now. They don't understand the full landscape of what tools are available or even what tools have already been implemented at their company.

Leadership is excited. Engineers are excited. But they're excited for different reasons and they're not talking to each other. For a lot of folks they're either nervous to use AI or there's some other value system at play. The tooling is changing dramatically day by day, and that's created a landscape where nobody really understands what's happening.

The end result is that most companies are either over-engineered or under-governed for what they actually need to do and where they actually are.

Right now pretty much every company out there has engineers tinkering with AI agents. Almost none of them have a governance strategy. No audit trails. No identity management. No policy enforcement. This is worse than previous iterations of shadow IT. It's worse because agents act autonomously. They don't just store data. They do things.

The OpenClaw Wake-Up Call

You need to look no further than what happened over the last couple weeks with OpenClaw, formerly known as Clawdbot. This open-source personal AI agent was the fastest project ever to hit 150K GitHub stars.

This application runs locally. You saw folks saying they were buying Mac Minis to run it, some running it in VMs, some in the cloud. It interfaces with a ton of different communication programs: WhatsApp, Telegram, Slack. It can run shell commands, control your browser, send emails. And it does it all autonomously, in a loop.

CrowdStrike, Cisco, and Palo Alto Networks all called out the security risk here. They were very clear about how bad this is if deployed on corporate machines. But here's the thing: it's just a symptom. A symptom of companies wanting to move quickly and people wanting to get things done without really knowing the right way to do it.

The core problem is that there's no shared framework for thinking about where your AI workloads should live. When I'm evaluating where to build an agent or an AI workflow, the first thing I look at is maturity fit. Not what's the most powerful tool, but what's the right tool for where this actually needs to operate. I think about it as six layers, ranging from the simplest and least governed to the most enterprise-ready. It's a simple mental model but it's been useful for me and the companies I work with.

 

Blog Image

 

Layer 1: Direct API

The first and least mature layer is just direct API calls. Raw model calls to Claude or OpenAI, managing your own state. I use this myself. I run research agents locally that help me keep up with what's going on in the industry. I have a couple of AI workflows that help me with day-to-day things for my business. These work fine for me. But they're not multi-user, nobody else can use them, and there's no clear audit trail.

This is the least mature approach, but it's also the right solution for some things. Not everything needs to be enterprise-grade.

Layer 2: n8n

The next layer of maturity is n8n, which is a visual workflow automation tool. I like to think of it as an open-source alternative to Zapier. It was really powerful even before AI. You can create workflow automations visually end to end and it integrates with 500+ different tools.

When it comes to agents, n8n can host AI agent nodes so you can build end-to-end workflows that have AI automation as part of the process. This is business process automation. It's a significant upgrade from direct API calls. But it's stateless. Every time you run it the memory wipes unless you're taking extra steps to prevent that. Still not very robust for agentic use cases.

Layer 3: OpenClaw

The next layer is the OpenClaw level. This is a persistent agent that's always running. It stores memory across sessions. It's always on, multi-channel. You can text it, talk to it on Slack, email it, and it can run multiple different things simultaneously.

This is essentially a power user tool right now. It is not enterprise ready by any means. There are a ton of security concerns and it's just not built out to the level where it's appropriate for a business to rely on it for much besides experimenting. I say that as of February 16th, 2026. That could change. But right now it's a very young project.

These first three layers are what I'd call the more immature end of the spectrum. They each have their place, but they share a common limitation: they weren't built with enterprise governance in mind.

Layer 4: Code-First SDKs

The next layer is using code-first SDKs. LangGraph, CrewAI, or if you're on AWS, Strands. This is for teams that are looking to build agents as a core part of their product.

This is a level where your engineering team needs to be doing the heavy lifting. Not a product person. Not a leader who has some free time. These tools give companies full control. They can write custom agent logic in Python. It's much more powerful than n8n or direct API calls. Definitely a different model than OpenClaw. But it's not yet the managed level of control that the more mature layers offer.

Layer 5: AWS Bedrock Agents

The next layer is AWS Bedrock Agents, a managed solution. I like to think of this as the Fargate for agents. You're able to use Bedrock models, AWS tooling, configure from the console. These are really good for scoped agents like support bots or internal QA.

They get to production fast with minimal ops. You're taking this managed layer that AWS built and deploying agents effectively on top of it. That's really powerful for the right use case.

Layer 6: AWS AgentCore

The final layer is AWS AgentCore, which to me is enterprise infrastructure for AI agents. All the bells and whistles, but also a lot more technical implementation.

This is how you build composable, distributed AI systems. It's model-agnostic and framework-agnostic. One of the key things AgentCore provides is policy enforcement at the infrastructure layer. It's not just about having good prompts. There's actual governance around what agents can and can't do, enforced outside the model itself.

There are strong features here around observability, persistent memory between sessions, and identity delegation so agents can log into different services as different users. I would assume this is mostly being used at larger companies and especially in regulated industries right now. Companies with multi-agent deployments where there's a ton of orchestration that wouldn't make sense to roll your own. Also for companies where governance is a board-level concern.

Knowing When to Level Up

Those are the six layers. It really comes down to two questions: when is it time to level up what you're doing, and what tools should you use for what you currently need?

There are a ton of different levels of maturity across companies right now. Most are somewhere in the first two or three layers. Some should be higher. Some are higher than they need to be. The mismatch in either direction is where problems happen.

Over engineered solutions move too slow and burn money.

Under-governing creates the shadow agent problem I described above.

The right answer isn't always to move up. Sometimes Layer 1 is exactly where you should be. The wrong answer is not knowing which layer you're on and why.

I've got some demo content coming that walks through how to set up some of these layers in practice. If this was helpful or you're navigating this yourself, I'd love to hear what you're seeing out there."