What jumps out at me is not that Forter got 200 people making agents. It’s that they apparently got there by refusing to make the project feel like an AI research lab. That’s the bit I’d trust more than the hype. Most internal AI programs stall because they start by dragging everyone into the swamp: RAG design, model choice, governance reviews, tool wiring, endless “platform” discussions. This talk seems to say: don’t do that unless you have to.
I think that instinct is right. A lot of teams are still acting as if every useful agent must be a bespoke piece of systems architecture. In practice, most internal use cases are narrower than that. People want something that can query approved data, call a few internal tools, and help them move faster. If you can hide the ugly parts, or at least fence them off, you probably get adoption much faster than by insisting everyone learn the full stack of agent plumbing first.
What I like here is the emphasis on non-engineers. Forter’s analysts apparently come from all sorts of backgrounds, and many weren’t even comfortable with SQL when they joined. That makes the “demystify agent creation” angle feel less like a slogan and more like a necessity. If your internal AI initiative only works for people who already think like platform engineers, it’s not really an internal AI initiative. It’s a demo.
The part I’m less ready to accept at face value is the implied ease. “It wasn’t that hard” always depends on what got left out of the room. The transcript itself hints at that: they sidestepped a lot of hard parts. Fair enough, but sidestepping is still work. There’s usually a security team, a legal team, data access rules, and a bunch of awkward exceptions waiting in the wings. The interesting question is not whether you can avoid complexity forever. It’s whether you can postpone it long enough to get people to care. That’s a much more realistic bar.
The MCP angle also feels telling. Custom MCP servers are a pretty sensible way to constrain the problem: you expose approved capabilities instead of asking a model to improvise against your whole internal universe. That’s a better story than “just add a chatbot to everything.” I’d want to know how much of the success came from the protocol and how much came from good internal API hygiene. My guess is the latter matters a lot more than people admit.
The main thing I take from this is that the winning move in enterprise agents may be boring design discipline, not agent wizardry. Lower the activation energy. Give people a safe path. Let no-code and code-based tools coexist instead of trying to crown one of them the future. And if you can avoid building a giant RAG monster on day one, do that.
Reference: From Consumers to Builders: Turning 200 of our Team into Agent Creators in 2 Weeks
