Hello Yeti

Wow! It's been a while since I have blogged here! I honestly have no excuse so we'll skip all of that and jump right into what is inspiring me to revive things here.

For as long as I can remember, I've had a deep fascination with artificial intelligence, neurobiology, and the idea of bringing technology to life. Not just making useful tools — actually breathing something resembling life into code. But AI was always out of reach for me. I'm not a data scientist. I don't have the patience to train a model from scratch or spend years buried in research papers and tensor math. So I settled into the areas of technology that were more accessible to me — and honestly, there was plenty to keep me busy.

I got my start on a TRS-80, and over the years BASIC became like a second language to me. That evolved into a career spanning just about every corner of the industry, but the through-line has always been the same: I'm an entrepreneur driven by my own necessities. I don't start with market research or business plans. I start with something I just want to exist — something that solves a problem in my own life or scratches an itch nobody else seems to be scratching. I build it for myself first, make it work the way I want it to work, and then — almost as an afterthought — I open it up to the world.

Over time, if you subscribe to this blog and keep up on my ramblings, you will begin to piece together how I think and learn when I am throwing spaghetti against the wall and when I am really targeting something specific. The project that I am re-opening this blog with is a little bit of both.

When OpenAI released GPT-3.5 and I sat in front of it for the first time, I had one of those surreal moments where the universe just collapses into a single point of clarity. It was the same vision that had haunted me since I played the Adventure game on the TRS-80 — computers that can think alongside us in a form of augmented evolution.

I knew that it was mostly smoke and mirrors, but I didn't quite understand what was happening under the hood yet. At Microsoft, I have been focused primarily on security, so that was the first lens that I applied to this new world that I was staring into. I began thinking through the implications of removing technical skill requirements from the art of hacking, and my excitement quickly turned into a shiver down my spine for the dark uses of this technology.

The ability to speak in your natural language through a prompt and watch functional (mostly) code come out the other end felt like a game changer that will never stop changing the game. As these models evolved and progressed, we started introducing RAG (Retrieval-Augmented Generation), context window engineering, and tools to these agents to afford them more power and capabilities as assistants for our work and daily lives. And then came MCP to tie those all together into a single context and tool provider to an entire swarm of agents all acting autonomously.

The security aspect of this was haunting me as all of this was exploding into use across the entire world faster than I have ever seen any technology adopted. It was all happening too quickly, with too little oversight, and every vendor was interpreting what "Responsible AI" meant in a way that would position themselves in the marketplace where they saw fit. MCP was going to really change the game for how quickly these agents could sprawl, and it became very obvious to me that this is where the new attack surface was. If someone can compromise a well-connected, trusted MCP server, it's game over for every agent that consumed its services.

That week, I wrote a whitepaper at Microsoft detailing these concerns, released internally only. I didn't have this blog at the time (shame on me) or I would have posted it here as well. My whitepaper detailed the need for a central registry for MCP servers as a control plane where you can observe, govern, and secure them as a whole. While I can claim no credit for Agent 365 (I am quite positive nobody on that team read my whitepaper), much of what I wrote is now in that product, and what isn't there yet will be eventually, I'm sure.

But then I started rethinking the whole "MCP thing". MCP does solve a much-needed problem in a mostly effective way, but it doesn't solve the problem well enough for situations where you have hundreds of specialist agents and you have one set of tools that you want to offer each of them based upon their current task or current specialty. MCP doesn't understand WHY your agents want the tools that it has. It will offer the tool to the requester even if it's the wrong tool for the job.

Another shortcoming that I see with MCP is that the tools execute on the MCP server instead of the agent that is responsible for the work. That requires an authentication flow that can get messy and become a treasure trove for threat actors attacking this new and very attractive surface.

So as a proof of concept, I decided to break out Visual Studio Code and create an agentic platform from the ground up to see if the idea in my head would solve this issue. I called this idea "Tool Crib". I fashioned it after a concept I learned in my younger years working in machine shops. If we were working on a part or a machine and we needed a specific tool to do the job, we didn't need to know which tool it was or even what it was called; we would simply walk down to the Tool Crib department, tell the attendant what we were trying to do, and the attendant, who knew every tool in the shop, would go to the back, fetch it for us, and then give us some quick instructions for how it worked. We would use the tool to complete our task, then return it back to the tool crib when we were done.

That is the lightbulb moment that went off in my head. These MCP servers and any other loose tooling should all reside in a Tool Crib service! Agents shouldn't need to know what MCP servers are out there doing what in every single context turn. They should only need the tools in their context window for the exact thing they are doing at that exact moment, and when they move on to another task, they should return that tool and check out new ones. That keeps the context window nice and clean and doesn't open up opportunities where the agent could use the wrong tool for the job. It also creates a single governance and observability plane for ALL tools that are allowed to be used by the system no matter what MCP servers and loose tooling is out there. If it's not in the tool crib, it doesn't exist.

So here it was — my new creation, born out of my own desire for it to exist ... my agentic platform that I called YETI. YETI is my personal AI — built for me, by me — and she's already woven into nearly every aspect of my daily life. Over time, I turned this little proof of concept into something that has become one of the coolest projects I have ever built, and I can't wait to tell you more about it in future posts.

For now, I would love to hear what you have to say about my thoughts on MCP, AI security, and any holes you can punch in any of my views on this. I am still learning and re-learning every day so I value all of your thoughts!