Allie Howe welcome to today's episode of the Insecure Agents podcast. I'm your host, Allie Howe, and today we have Guy Podjarny with us. Guy is the founder of Tessl and previously founded Snyk. Tessl is reimagining software development for the AI era, helping shape AI-native development. Today, we're here to talk about why skill's the new code. Guy, would you like to introduce yourself?

Guy Podjarny Hey, Ali, and thanks everybody for tuning in. I'm yeah, Guy Podjarny, Guypo. I'm a serial entrepreneur, an addict entrepreneur as I think of it. Sort of developer by trade turned product turned entrepreneur, founding a company that made websites faster and turned out to be in the DevOps space in the early innings of it. After that got acquired, was a CTO at Akamai, who acquired us, and then went on to to found Snyk, which is again, probably my first line of my obituary at this point on it. And, a couple of years ago, a little over now that, two and a half years ago, I fell in love with AI and, and sort of saw this picture of where I think software development is going and felt the, the passion to doing it and indeed accepted that I'm that this is what I wanna do, that, that I wanna jump back in and and found found another company.

So that's what I did, and I founded Tessl that you mentioned as my current company. I'm sure we'll talk a little bit about it, but fundamentally founded it to help Help kind of build the the system of record or, you know, the right tools for a new paradigm of development that we didn't at the time quite know what it would look like and and is now kinda coming a bit into view for, for the AI kind of in agent era.

Allie Howe Amazing. And I saw just, like, a couple days ago or this week, you did the AI Native Dev Conference. How was that, and what talk did you give there?

Guy Podjarny It was superb. You know, I mean, I'll give a little bit of context for this. So we-- you know, so, so we believe, you know, that in general this is a new development paradigm coming in here, so we invested from the early days in building a development movement. We think a paradigm is not something a, a vendor sort of like one company decides. It's something we kind of build together. And so we created the AI Native Dev community, which has a content hub and has a podcast of its own, and we have, you know, like, sort of a lot of sort of sharing mechanisms for people to to engage, a Discord community.

And, one of those is AI Native DevCon which we run every six months, and we've run two virtual and then two in person. The last one was this week in London and it went very well. Shout out to to mostly Sam Hepburn on our team, who is the the master behind it. She's awesome on it, but Patrick and Simon on the team did great as well. And so the team rallied. We built it, had about six hundred and fifty people in person at the event, all kind of, curious and passionate about making agents work within their organizations. And so that was great. And within that, I spoke kind of opening it up around why skills are the new code, and in general about the sort of, the emergence of kind of the new software stack for agentic development, if you will.

So I can dig into that a bit.

Allie Howe Sure, yeah. Why are skills the new code?

Guy Podjarny So I, I, I think i-i-in general, when we think about, like, what, what is it that we're developing in, in agent land, right? When we're building agent. There's a whole premise of, you know, we're not writing code. We are-- we're, we're writing the coder, right? We're not speccing the code, we're speccing the coder. And, and, and we're, we're starting to get like recurring tools that enable us to, to build out or like layers in the stack, right? So first of all, we're all building on top of models, right? So we all got this sort of new superpower that is these models that are able to produce wondrous things on it.

And so that, that's the core of it. Beyond that, we, we started building tools or making available tools, and tools allow a model to interact with the world. And so they're, they're kind of what turns a model into an agent, right? It can now have arms and legs. It can fetch information from outside. It can affect the world on the side. And then we have context on top of that, that guides all of that work. And so we'll, we'll come back a little bit to, to context in a sec. But context is, is the, is actually the information or the instructions that go straight into the matrices, right, in the model.

And then we have other, other layers of software that I think they more harness or constrain or structure the model, right? So we have harnesses, Claude Codes and the likes, or something custom you build with Py or others that that really wrap the model, load context from a Claude MD, load this config, running it in a container with some limits, set up some hooks to be able to kind of limit what it can do or like introduce deterministic checks before you commit, make sure that You know, the test coverage is sufficient, right? Or that a security scan has run. And these harnesses compose into factory lines and pipelines that regularly take, say, feature request in and, you know, spit out a working feature into factories, et cetera.

So this is kind of this stack, right? We've got models, tools, context harnesses, factory lines, factories, and I'm sure it'll change. You know, this is AI, right? So maybe as I'm saying this, you know, by, by next week, it'll look a little bit different. But, but within that layer, m- almost all of this is actually software. It's software that wraps a model, and the only piece that literally gets into the matrices is the context, is these lines in files that we create in skills and in rules. And they are the ones that are natively interpreted by the model. So they're the programming language, if you will, for models.

So I guess the starting point for the claim of why context is the new code is, is that they are the actual kind of programming of the model before we get into the frameworks. And then there's, there's a whole bunch of other reasons about why they behave like code and why we should treat them like code. Does that make sense?

Allie Howe Yes, that makes sense. Yeah, for sure. I think it definitely makes sense to, like, treat them as code when we talk about, like, versioning and how, like, different, you know, versions of context get your agent to do different things. And if we're trying to share context across, like, a team or an enterprise having that be something that's structured and maintained and versioned definitely makes a lot of sense to me, for sure.

Guy Podjarny Yeah. And I think, and, and that's, that's precisely it. Like, once you sort of get into the, okay, these are programming the model, like what we're doing here when we're creating the context, a lot of things fall into place about all sorts of security concerns or, you know, software collaboration needs or the likes that are-- that sound awfully familiar. You know, they they, they come from code. So, you know, if a, if a model or an agent runs your context or executes your context by passing it into the model, that context might be malicious. You know, it might be that you loaded it from the internet somewhere, right?

And maybe it's actually meant to, to exfiltrate data from your system or delete your system or do some crypto mining or token harvesting as we see now. So it might be that. It might be, I like to think about negligent skills, which are skills that are very, very, very focused on driving the model to achieve a goal, but they do not have safety instructions, right? Like, update the database to do this. Do not drop the table, right? Or like check this into the repo. Do not commit, create a-- If you can't access the repo, stop, right? Don't create a public repo and upload your sort of secrets to it.

And, so, so there's a bunch of these types of security risks. If you have security risks, you need governance. You need to start saying, "Okay what is it that I have?" So you need some supply chain needs. You need to know, you know, what's what's around. So there's, there's kind of all of that facet. This is, I guess, a security podcast, so we're probably sort of appealing to the audience by saying that. There's a bunch of, like, quality and collaboration system there's a bit of an acceptance element, which is, you know, when you're using a skill and you're gonna use it again and again, you've created the dependencies, and dependencies are so much fun.

You know, they are, they are clearly like the bane of our existence oftentimes in, in the world of software. But they're also the secret, you know, to, to scaling, right? They are the means that you don't need to reinvent the wheel. So, you know, we created dependency managers because dependencies were actually quite hard to wrangle. They conflict, they, they break your application when they upgrade. They have you know, they might be compromised themselves and kind of make it insecure. They-- So, so there's all these challenges around it. So that's why, you know, npm and PyPi and, and Bun and Brew and, you know, Docker's Hub, that's why they exist, is because dependencies are hard to manage.

And so we need something like that for skills, otherwise we can't really properly use them. So I'll, I'll pause 'cause I'm getting a little bit rambly, but like you, you start-- Once you think of these things as software, then the security concerns, the quality concerns, the collaboration concerns, the, the evolution and the fact that, you know, skills will rot just like software rots come into play. So in all of those, like, like we think once you start thinking of context as code, skills is like a little bit of the code name for a variety of types of context. A lot of needs naturally kind of come into place.

Allie Howe Yeah, that makes sense. Yeah, the need to treat the skills as code in terms of like, you know, version control and also the security concerns there making sure we understand exactly what we're like downloading into our environments makes total sense to me. Just really curious to get your perspective since obviously you're the founder of Snyk and you've, you know, seen this with different registries before. If we did have a central registry for skills, which I believe we don't today, correct me if I'm wrong, but I don't think we have a central registry for skills. Registries are vulnerable also. So what does it look like to like, one, are we going to have a central registry for skills and how do we protect it?

Guy Podjarny So it's a good question, and I think skills and in general kind of this world is like moving at a faster pace than any new software stack that we created. So it's possible there will be more hubs. And in general, it's interesting to see how actually most skills are being created in, in, inside an organization, and it's harder to get numbers. We've actually just done an analysis recently. I always have a-- Even as we speak here, there's an agent continuing to enrich the data from GitHub around it. And so if you look around, you'll s- you'll find in the open ecosystem two million skills already, and they're divided across quite a few repositories.

But of those two million skills, there's probably about seven hundred thousand that were installed skills. And then of the remainder, you know, call it, so that's a third, you know, and then of the remainder two thirds, about half of those are duplicates. It's because diff-different repos have been copying skills from one another, trying to create a central place where all the skills are there. The result of that is there is even more of those. So it's probably more like seven hundred thousand original skills posted, which is still a huge amount when you consider it was near zero back in September. So, th-there's no standard spot for it.

At Tessl, we have a public registry. You know, we launched it. We do think we need to treat this seriously. And I guess the, the attempt from a security lens perspective is, is to try and anticipate a bunch of these problems and put some controls in place. So some of Tessl's defaults are anything that gets uploaded to the registry gets scanned for security flaws and gets rated. And when you install something, if it is deemed to be malicious or like a critical vulnerability, by default, Tessl will not allow you to install it. You can override that, but it will block it by default. And if you're in an organization, you can set up a bunch of constraints around it.

The default behavior is to not install things that are less than seven days old so that, you know, malicious skills or things that have been compromised do not automatically get updated. So a bunch of these best practices, you can try to build them in. I'm sure there will be other risks. I do think there are some new types of risks that are interesting, and I don't know how we'll handle them. I think we will gradually evolve there. There's probably gonna be some, some hard-earned lessons. I'll point out two things. One is what I alluded to around safety. And so I think with software, we don't tend to think about safety concern.

The software does a much more defined set of work. While with the skills, I think we will have this notion of how safe are they or how negligent are they, how lacking in safety controls they are. So I think that will be, that will be interesting and, and it's not a measure that, that is clear yet. We don't actually have it on the Tessl registry, for instance, where it's just sort of learning still. And then the second aspect from a security perspective is that it's gonna be very hard to define what correct behavior is. I mean, security generally is the -- or like when you think about attackers, what they're trying to do is they're trying to get the agent to do something that is...

Or attackers in general are trying to get the software to do something that is not the intended functionality. And when the intended functionality is so broad and ill-defined, right, and sort of flexible as it is with agents that that is gonna be quite hard. So I think, I think th-those are, are two similar or like related evolutions that we need to, to have. Trying to define what is a, a well-defined, well-scoped skill that is trustworthy. Like how, how can you trust the skill, I think will be a work in progress. So, so some-- I guess kind of to summarize a little bit, the, the, the supply chain aspect of it, I think we, I think we can do it well.

We're trying to do it well with Tessl, with the right attestation, the right manifest files, the right security scans, the right sort of best practices around it. So, you know, I hope Tessl becomes the sort of the standardized sort of, open public skill registry. It's not it's not a something that has been decided yet. But either way, we can hopefully set this up correctly. But there's a new set of challenges around what is a trustworthy skill that I think will be a learning process.

Allie Howe Definitely. Yeah, that makes sense to me. Yeah, so I think some of the security issues with skills can be very like obvious, like if it's gonna call out to some like, you know, rogue URL or throw your secrets like over there or like maybe call like the AWS like metadata service URL or something, like that's kinda that would stand out, I think, on some scanners, and that's easy to catch. But the safety aspect is really interesting and harder to catch, I think. And something that demonstrates this for me is Google DeepMind's AI agent traps papers where they talked about how different sources of context very well placed into an agent can alter the agent's behavior, and sort of elicit like cognitive bias within the model.

So they talked about like if your agent gets the context from several different sources to say, "Hey, you know, so, so and so is like the leading industry standard," or, "This product's the industry standard," then you can get the LLM to like believe that, and that's a very- Yeah. sneaky attack versus something that's very like I guess overt in my opinion.

Guy Podjarny Yeah. Yeah, I, I, I agree that it's very hard, you know, like a prompt injection. In general, in, in context, there's no, there's no separation between the control and and data planes. And so right away, there's no way to know what is it being injected versus what is content. And then you have the sort of infinite possibilities of how the model will behave and infinite possibilities of inputs. There's even the behavior that is weird because we're also quite ambitious about what we have agents do. So, you know, if you have a, a skill that sets up, you know, a testing environment for you, right? And so it installs a bunch of things on it.

It goes off to some APIs using your credentials and fetches information and does those... Is that malware? Is that like a-- It sort of, it looks exactly the same as something that does it maliciously. So some of those are detectable and some are not. I do see You know, like, a, a part of this is, is, is part of the solution is just observability. You know, just, just track, like do you even know when this happens? So start by identifying that. Another aspect is, of course, you know, like identity and, kind of minimizing permissions and things like that. So, you know, a lot of those hygienes I think are, are in place.

Then you've got a, a bit of a layer of can you do like an inline prompt ejection and things like that, which some of the AI gateways enable you to do. So, so that's a little bit useful. And, I, I think what, what is also emerging as a safety measure is just moving some of the controls into the harness. And so increasingly the, the harness is what harnesses the model. It, it what sort of limits it, and sometimes it does it to drive success, and sometimes it does it to constrain the model and, and, and keep it from, from doing certain things. So I think, I think that is another interesting vehicle for security controls.

Today it's being done for things that are fairly arbitrary, you know, like some, for, for just giving a Tessl example, obviously some people use it to, to prevent skills from being loaded from anything but Tessl, right? So all, all your skills are always loaded from Tessl. But, but you can also use it for things that are quite elaborate. And I think what's really interesting is layered small models. And so for instance, Claude Code's auto mode uses in the harness, it does some inference. It calls the models, some small models to look at the context and sort of the rules that you have set up and all that to actually enforce things outside the flow.

So it's a little bit of a separation between the control and the data plane, 'cause now you have something that is in the harness that isn't getting those inputs from that malicious cognitive bias example that you talk about. But is still adaptable and and can create a more arbitrary rule for this environment using the LLM power.

Allie Howe Yes, that makes sense. And it'll be interesting to me to see how the industry works together to sort of sol-solve this problem, because I believe it's like not one, not one vendor, not one solution can just like solve this in one go. What's really interesting to me was what you talked about with the, the, the guardrails or the like the runtime controls that are within the harness itself, and those are only as good as the context that they have in terms of like, you know, what was the agent's mission? Like, does it make sense for this agent to go out and use these credentials to talk to this tool or whatever?

Okay, like, you know, you got these instructions, the reason it's doing this in the first place is because of like the skill and because of maybe like Tessl or something, we can see like the skill is like this level of trustworthiness. So like we can use that to influence the runtime, AI runtime security software that we have in place. Is that something you see like Tessl fitting into?

Guy Podjarny I guess kind of to your, to your starting point over there The, the, the thing we always avoid as humans is defining what correct is, right? It's like: "Hey, what, what do you want for your birthday?" It's like: "I don't know, like you, you figure it out," right? It is, you know, like take all the information you know about me and just sort of make good decisions. Like I don't wanna bother defining, you know, what correct is. And, you know, how much of that do we have around, you know, what is quality code? You know, what is production ready? What is the level of risk that is acceptable?

What is, you know, a good business outcome, right? Or sort of a happy customer. It's like all these things are so hard to define that we revert into this, you know, you'll know it when you see it, right? Or like, I don't know, but Ali knows her, her taste is good. And I oftentimes think that taste is just, you know... It's, it's basically a perspective you haven't bothered writing down. You know, it's sort of, it's not, it's not a magical thing. It's a thing that you have not defined and therefore you're relying on, on some sort of, nebulous human judgment to do. Once you do sit down and define it, then I do think that it's a little bit of sort of skills and agents all the way down.

So, I mean, if I, if I think a little bit about the, the Tessell lens, but this is more broadly correct. You know, Tessell-- what we think of ourselves as a, as a platform for, for the development of skills and harnesses, right, and factories. Like basically we are the sort of agent enablement platform to make the agents succeed. And so we have an upcoming Tessell agent, still in early preview, for instance, right now, that helps you learn continuously things you can do with your agents. It's just optimized and tuned for this environment to, to create flows that find problems or gaps or your needs and then start instituting those into the harness.

For example, run the Tessell agent to say, "Hey, add code review to my system." And so it would run the code review. It'll add a GitHub action with the right, you know, launch of it, and it would look maybe at the last 10 pull requests or something, right, and create some instructions and set those up. And then once you've done that already, you're, you're pretty good, right? Like you already have some review. Now, your review would sometimes Work and sometimes not work. And so you'll run another test L command to say, "Hey, set up an automation review that would run on a daily basis. Every day, look at the previous pull requests and sort of improve those as, as you run."

And so you'll im-you'll improve it from that perspective. And then every now and then you'll sort of see a, a problem that came up with the review, "Hey, can the agent run and modify the harness and introduce some hooks to say, 'Don't allow these things to play?'" and we have two types, for instance, of enforcements. We have more of a linting style. We call them verifiers. Fast scan that will check whether a a type of activity was correct or not quickly with some regexes and, and, and light models. And so that will be something you can run, you can shift left, right? You can do this regularly and often as kind of part of the development, and then you can introduce some of that learning into, into that sort of pull request agentic review, right?

That, that you run along. And so you can, you can kind of run those loops on it, right? And, and because we run it, we run it in like a VM style, test a launch command that will wrap the, the, the environment. So you know you're capturing the logs and you're associating them with the skill and therefore, you know, and as you, you, you can relate the logs to the skills, you can build increasingly evals that allow you to reproduce problems, to reproduce the test. So as you modify the skill, as you evolve it, you can say, "Does it work well? Does it not?" So this is useful because you're preserving knowledge and you're preserving that element, but also it allows you to now say, "Okay, if I make modifications, can I, can I fix problems?

Can I introduce hooks? Can I introduce other harnesses? Can I change the context?" And over time you can also add-- do things like a, like a cost optimization, right? Like I've been running all this stuff with Opus and my budget is depleting. Can I, can I try this with like GLM 5.1? Does that, does that work well with an open and cheaper model? And if, if so, then if I ran it with the right kind of launch command, maybe I can auto optimize it. So all of those are, are basically harness optimization loops. I gave an example of how you would do it, you know, with the upcoming agent, but, but it, they are people do this, you know, as a, as a self-learning system.

OpenAI has a good blog post around this. So I don't know if I'm like directly answering your question, but that's how I sort of see it. Like it's agents all the way down, and then it's the combinations of the harness at a variety of like different harnesses, right? Your sort of local harness with the hooks, the har-- the system harness that you have in the pipelines and such that will will enforce it with, with the human's job being defining what correct is assisted. But at some point, someone needs to make a judgment call that says this is legit and this is not legit.

Allie Howe That makes sense. And yeah, I feel like that's very valuable too, because I think a lot of people in like a larger enterprise just rely on someone's taste and be like, "Oh, they know what, you know, what good is, and I'll always be able to just ask them." But what would it look like if they were, you know, prompted by an agent or they were helped by a Tessell to, you know, take that taste, write it down to a skill use evals to make the skill better and then also be, use the Tessell registry to be able to share it across their organization? No, I definitely see the value there.

That's super interesting to me for sure. And especially like, you know, from the versioning perspective, we talked about the security perspective as well. Does Tessell also help with the problem where like, okay, like maybe this skill or this taste works exactly like for this person's workflow, but I work like slightly differently. Like could Tessell help take an existing skill made by one employee, make it more tailored to another?

Guy Podjarny Yeah, it, it's a good question. Thanks for the like I, I, I like I, I f- I feel like we've been saying the word vibe less recently. And I, for one, am, am sort of happy about it. You know, there's a, a, a, a, I think when we were using things sufficiently lightly or, or insufficiently like single player mode the notion of like just sort of vibing it and sort of feeling like it's good enough was much more satisfactory or sufficient for it. Now as we go into multiplayer mode, it starts turning into works on my machine type syndrome of it's like, I don't know, I don't know what you're talking about.

Like, it works on my machine. And so, so we are, we are seeing that the, the need or sort of that pain emerge. I think from a Tesla lens, what we, what we do so maybe allow me to like nerd out a sec on on just sort of like thinking of skills as, as code. In my talk, I talk about sort of five different types of tools that you need that we sort of alluded to many of them over here to be able to, to have them be reliable software that you develop. So one of them is static analysis. And so there you're looking-- You're not running the skill, you're just inspecting the skill, probably agentically, although as I mentioned, we have this linting faster one.

So, you know, you're inspecting the skill and doing it. So there's, there's the default linting, there's the default review that just looks for anthropic best practices and things like that. But then you can define your quality version of it. So already that's one place in which if you're saying, "Okay, this needs to work across Codex and Claude and Cursor," then now you can introduce, you know, some, some questions and some assessments around that. So static analysis, easiest to apply across all your skills 'cause it doesn't need to run the skill. Then you've got tests, you know, which are a pain in the butt, right? And nobody likes to write tests, but we've sort of had enough muscle memories in industry to, to feel how, you know, what happens when you don't write tests, right?

Like it feels good when you ship the first version and very quickly it stops feeling good. And, and so the skill equivalent or the AI equivalent is evals. So you have to define a little bit of an executable environment test to actually run some piece of your code and say, "Here's the, here's the environment, here's here's the, a task for the a- for the agent to do, and here's some judgment criteria of what correct is." So that's another example where you can run, you can run sort of less or more comprehensive evals. But for instance, if you know that in your team this skill is being used across different types of agents, then you can ca- take a skill, create a certain task and run it with different different agents and see whether the, the criteria comes out.

You can also do things like integration tests. So you can run what we call a project eval, which is take a, an existing repo that has 20 skills installed and try to maybe even run the same task or maybe run more comprehensive task, but run it in the real context environment of the surround. It's a little bit more expensive, it's a little bit more involved to maintain, but it runs there. Now from there, you get into things that we talked about, like you need security testing, you need package management and versioning, which I appreciate you sort of mentioning a few times on it. 'Cause eventually, if you don't know to associate your logs and your learnings and all that to a certain version, how do you know that, that you've improved them?

Like, you know, you have to relate to them to, to a point in time, a point in the, in the version stream And once you release a new version, you need to know that it got rolled out. And then lastly, you need observability. So, you know, a lot of these things I, I was alluding to, you look at the logs, you do all those things like that is the acceptance that we don't know in the lab everything we need to know. We have to go to runtime, and runtime i-in, in the world of agents is, is the coding agents, right? Like, is there, is there actual interaction?

Actually not just coding, frankly. This is true for any agentic flow. So, so I guess that's how we would solve... We, we don't magically-- W-we, we do technically in the package management have obviate some cross-agent stuff, right? You create a skill once, you create a-- We have to have a Tessl plugin, and so you create the plugin once, and when you install it, if you have Codex, we'll install the Codex. If you have Cursor, we'll install the Cursor. So we take away some of that pain, and we do observe that pretty much every organization is a cross-agent organization. We don't think that changes over time.

But if you want to ensure kind of quality, then you use one of those different tools.

Allie Howe And then it's interesting to me today, you're not just focused on skills, it looks like from your docs. You're also focused on private context, like proprietary agent skills that a company might make, internal APIs, their own security and compliance rules, and architecture conventions. Why is it important to capture that context as well?

Guy Podjarny Yeah. I think skills is a bit of a shorthand, you know, for it 'cause everybody's doing it. You know, if you if I look a little bit at Tessl's history, so we started from-- we talked about spec-centric software and say, "Okay, you have to define some aspects of how you want your product to work." And then over time, we, we learned that we have to go from speccing the program to speccing the programmer. So as agents came out, turns out reading the specs is only one of the things you want your, your devs, or in this case your AI devs to be doing. You also want them to know what are your policies and practices.

So it's another kind of whole bucket of it. You want them to know some of your processes and methodologies. And so today, I'd say that those are like the primary types of context that we're seeing as we, as we extend that. And so those are primarily like opinions, policies, practices. This is how we got in a room. We agreed that this is what our API design would look like. This is what our security policy is. This is, you know, how we handle whatever commit messages. So there's no reason for the agent to know that, right? You have to kind of write it down into those.

You have specs. Specs are dual a little bit. It's like specs around what you are building right now, so you'd be better informed about what you're building, so you build the correct things. But also specs of products you're using. So it's kind of documentation, right, of, of APIs and such. Especially important when you work in a fast-moving environment, which might sound familiar if you're working with agents because APIs change all the time and, you know, agents are always a little bit outdated. And then the last bucket is these workflows, right? And sometimes workflows are a means to help the agent. Like, you know, here you do incident response.

Don't just try to solve the problem. First collect the data from, you know, my Datadog and, you know, from whatever what PagerDuty sort of told you over here and, you know, from the latest change log, and then look at the data. So sometimes it's to help the agent, and sometimes it's to, to get consistency. You don't want the agent making it up every time, right? You want to be able to say, "Every time a security incident has occurred, I always collect these sets of information. So I don't care, agent, that you're sort of brilliant and you can do this yourself. You know, you need to follow these instructions."

So these are like-- this is one dimension, is like these sort of three types of context. And then the other type of context-- the other dimensions for context are how they're shoved into the context window. And so they go from the most aggressive rules, so stuff you'd put into Claude MD, Agents MD, that would always be there. By the way, not always adhered to, but always in, in sight, you know, of the of the LLM. You-- then you have skills that are either loaded on demand, like they're available for the user to slash command them, but they're hinted at, so they take up some amount.

MCP slightly falls into that bucket as well if you look at the tools. And then the you have passive context like Architecture MD or oftentimes specs about your own product are sort of manipulated. So I guess we think of all of that as context and we make available all of those in our, in our plugins, and we sometimes use the shorthand of skills just to represent a reusable unit of context. I'll slightly say that at Tessell we do actually go beyond beyond context. We do allow you to also distribute like broader plugins that might have hooks in them, might have commands in them. We intend to expand into tools and others.

And so we go more broadly. The world moves so quickly that updating messaging is a little bit a little bit hard. But we think all of those are, are units to be able to tune your harness to guide your agent as you build it.

Allie Howe No, that's a great answer, and it, it makes sense. We're definitely shifting to harness engineering and skills being a new unit of software that helps become like a dependency for that. Makes a lot of sense. So it's really smart to start thinking about, like, how do we get these units and new units of software version controlled make sure that we scan them for security vulnerabilities. And it makes sense given your background at Stake you're very well positioned to be, to be doing this line of work.

Guy Podjarny Yeah. I mean, I'm-- I guess I've always been passionate about sort of software development and software development that is, that is done right, I guess, about it. I don't know. I don't know what what that says about me, but you know, that, that's sort of been a bit of a passion. But I feel, look, eventually I like to say that like in everything in life, there's, there's there's how hard something is and how much you care about it, right? And you need to care more than it is hard for you to do it, right? And that sort of said this in a few podcasts as well, just like, you know, that's true if you're going on a diet, right?

Or if you're, you know, wanna watch a movie or if you want to, you know, like keep your code secure. So all of those things end up being an equation between how much you care and how hard it is. And so I think as a tool provider like our, our job is to make it easy to do the right thing. And if you, if you do that, then people do it. And if you don't do it, the other measure of just getting you to care is, is such a slower burn. Like it is also important, we want as a community to educate people to what the correct practices are.

But that's a lot, lot harder. And, I guess AI adds another dimension to it, which is we don't know what good looks like yet. We are-- And what, what good looks like today is actually quite substantially different than three months ago, let alone sort of six or 12 months ago. So, anyways, it's an exciting journey.

Allie Howe Definitely. Yeah. It'll be interesting to get to the best practices around, like what does secure by default look like, so we can make it super easy for developers to build secure agents, like you said. Because yes, no, I definitely have lived the like software engineering to security engineering arc, and I've definitely seen that the best solutions are the ones that are the easiest to use and also like the most effective for sure, that enable developers, they don't block them.

Guy Podjarny Yeah. I think like some of this we're gonna have to learn the hard way, right? Like, some of it might be, you know, some, some notable breaches and, and it's not like those headlines are starting to come, right? Like production databases are done. I was just in a set of round tables yesterday with someone talking about yeah, they had, you know, one, one production outage, you know, caused by the agent, and they're actually quite proud that it was one production outage, you know, during that time. But, but it's just, you know, these, these actions occur and I think the security breaches are, You know, they're gonna become a little bit more, more prevalent.

So, so some of those will happen. I guess part of it is we-we're trying to prevent it from, from creating the sort of backlash of like, "Oh no, don't use agents." I, I think that ship has sailed, no? Like, I don't think anybody will truly revert back at this point. The, the momentum is too strong. So what are the best practices? Let's sort of, match that up. But I know. We'll we'll see. I, I do think that private private context or like, you know, the definition of what correct is becomes a core asset for organizations 'cause oftentimes a lot derives out of that. Like without that, you're, you're just, you're just hoping the agent does the right thing, right?

If you, if you start defining those. And so I think that becomes the core competence and-- or like maybe the core asset for organizations to build is their workflows, their definition of rights, their management of the degrees of freedom that they give a model with their harnesses versus their models. The the level, like the, the set of tools that they have to be able to save cognition, to sort of spare tokens, you know, and and do things more deterministically. So you kind of wrap the probabilistic model with the right tools to make things more efficient and more deterministic and the right harness to constrain it and limit it, and then provide it with the right guidance to, of what correct behavior is.

And I think you can achieve some pretty amazing things. And I think that is really that's your, your new workforce, right? So, so your, your market power, your, your competence, your competitiveness becomes very dependent on that. And I think as that spills into the open ecosystem as a, as a... What, what do we do in the open ecosystem? We try to lift all boats, right? Like we're trying to to create these types of practices and and, and tools and harnesses that everybody can use. And so it's no longer like one organization's unique aspect, but rather everybody can tap it and everybody can get better. So that sounds awfully like software to me.

But I think that's what we need to be building.

Allie Howe Besides the Tessell agents, is there anything else that's new and upcoming with Tessell that you'd like to share?

Guy Podjarny At a high level, we see this maturity journey that organizations go through that ends up going these, through these sort of three routes we're trying to satisfy. And so the, the first concern when, when an organization comes along and they start using skills, which is interesting, right? 'Cause I'd say in December, you know, when we were talking to organizations, we were still saying: "Hey, you should, you should create context. Context is your agent experience. It helps guide your context." Like, "Oh, that's interesting. You know, here's some data." Interesting. And then come February, we come along and there was like: "Oh, we've been creating skills." "Oh, that's amazing, you know.

Do you know how good they are? You know, how can we, how can we kind of help figure it out when you modify them? Do you know that you didn't break anything on it?" So that was the conversation. And then come, come May, so these are like three-month increments, we come in and the conversation is like: "Ah, I'm creating too many skills. Like, I've got too much-- Like, I have to rein this thing in. Everybody's creating this thing. They're all duplicates. I worry that they're malicious, you know, they're gonna do that." and so who knows how long what I'm about to say lasts, but but at the moment, what we're seeing is the first concern that organizations have is around security and governance.

So it's just to say: "Okay, well, help me rein that in." And so we have a set of capabilities there to say "Hey, we're gonna crawl your GitHub repos. We'll find all the skills that you have. You have more than you think. And we'll sort of score them, we'll rate them, you know, click a button, we'll index them into the registry." You can now-- Then, then we give you like a set of these policy controls to be able to say when you install them, only these things are allowed to be published, only these things are allowed to be installed. Maybe you set up some MDM-based sort of, constraints to say only load them from Tessella.

So there's something, a set of that world of just be able to govern what you've got so, so you can move forward. Then there's like a standardization and reuse. So what people are seeing as they get into, you know, everybody created skills, and we're not that original. Like, most people have the same ideas for skills, and so everybody's creating the same skills. You know, if I create a skill and, you know, like there's three others, right? That has to do with the incident response, and you, Ali, come along and say like: "You know what? I'm, I'm smart. I don't wanna recreate it. I wanna reinvent the wheel.

I wanna use one of them." How do you know which one of them is, is better? How do you -- Right. Or if you propose a change to my skill, how do I know if the change you proposed is making it, like, better or worse? This is-- It's like sentiment. It's like I trust your judgment, you know, type thing, right? Versus... So, so that's where you get into, okay, some quality reviews, some deduplication capabilities, the eval platforms, the versioning, you know, like all of that stuff falls into that standardization and, and reuse. And people are starting to feel that. And then the third bucket is the part that like as, as geeks, you know, we sort of get excited the most, which is this continuous optimization and life cycle.

So it has the sort of the carrot and stick, you know, the, the stick being skills will rot. If you create a skill now and you do not have a plan to maintain it, I almost guarantee you that in three months' time it will be anywhere between useless and harmful because probably the models have changed, probably the APIs it's using, you know, some of them have changed. Maybe your practices have changed, you know. So, so you have to have some maintenance. And so there's-- that's the stick. You have to think about the maintenance of them. And then the, the carrot is if you do use that, you can actually turn maintenance into optimization.

So you can turn You know, this log observation and this automation into something that doesn't just keep the skill good, it actually makes it better and better and better over time. And so that's where the Tesla agent and all those capabilities kick in, you know, the observability. So this is the, I guess, stack, but also a bit maturity for organization. If you, if you don't know where you're gonna store the skills and how you're gonna be able to relate logs to them, and then it's hard for you to jump into that continuous optimization. You can do it at like small scale but it's quite hard.

So I gu-- I don't know if that makes sense, but that's, that's how we think of the world. That's how our world has been evolving.

Allie Howe Yes, definitely. No, I've definitely seen that play out too, where you create a skill and then like three months later, it's very much like out of date or it doesn't quite work the way you wanted it to anymore. So yes, this continuous optimization workflow makes total sense to me and something I'm looking forward to continuing Tesla for. But yeah, thank you so much for coming on today. I really appreciate it. Is there anything you'd like to leave our audience with? And where can they connect with you, they'd like to continue the conversation?

Guy Podjarny Well, thanks for having me on. I guess I'm, I'm passionate about doing this as part of the community. So, of course, go check Tesla out, you know. If our product's awesome, tell us. If you think they suck, also tell us, you know, so we can improve them. You know, we, we, we would like to know and improve them. So, you know, we're just on tesla.io. But also just be part of our community. So on tesla.io/uhai nativedev or AIND you will find a lot of useful content from smart people, not us that are sharing their practices, their learnings. It's on our YouTube channel. Join the Discord.

You know, come to the next DevCon. The next one is in November in New York. It'll be amazing. So, so just sort of join those and w-- I think people underestimate how much their learnings are useful. So just really, really keen for people to share their their their, their knowledge, their sort of learnings on it. So we're, we're giving some stages for it. We have our own podcast. Yeah, you should-- I guess we're on a podcast. You know, if you're a podcast listener check out the AI Native Dev. We've got a couple of fun episodes coming from actually a great conversation with OpenAI Ryan Lopopolo that was just now at the event.

But I, I think just, just participate in the in the conversation. Nobody has the answers. Many people think they do, but nobody has the answers. So it's all about the the conversation and the, the joint learnings.

Allie Howe Amazing. Yeah, we'll definitely continue to follow the community and the podcast. I do listen to the podcast. It's fantastic. So yeah, definitely recommend that, and definitely a fan of, like, a rising tide lifts all ships. Intrepid agents has that same value.

Guy Podjarny Yeah. No, and, and I, I love the podcast as well, and I love the... In general, like, I guess I didn't say that, like, identity is oftentimes kind of at the core of all of those. You know, it's more sort of on the, the key card side. And y- y- you know, just so, so much infrastructure sort of still needs to be built up for us to be able to deal with this. But hey, that's part of the excitement here, so.

Allie Howe Yes, absolutely. So exciting. Well, thank you so much, Guy, for coming on. I appreciate it.

Guy Podjarny Thanks, Allie.