“If you put too much friction in front of people, they're just going to do unsafe things because that's how humans are, right?” Sharadh Krishnamurthy · Lenny's Newsletter

I'm going to do two things. I'm going to show skills and I'm going to show projects, right? So when I come to say skills, we have this thing. It's great. Everyone loves the dashboard, but I don't want to be creating this dashboard and paying a bunch of tokens and time every time. So the thing that I think Kai did really well and one reason for its product market fit was I can create a skill that basically takes what I've done this session and packages it up so that it can become a load-bearing, repeatable workflow, right? And that's when the AI goes from here's something I'm just like iterating with on the site, like a chat interface, to here's something I can trust to run my, to sort of like run my business or run my workflows or help me. Help me do that. And a little bit after, you're going to see this kick off this like skill creator skill. It's a skill that the harness has that's going to go in and create, like take all the things it's learned from the session from its interaction with me and package that up nicely into something that I can just like pull up at any time. And we'll talk a little bit more about how we do these skill retrieval. I think that's a really cool part of the system as well. But while that's cooking, right, let's actually look at this other thing I love about how we built Kai, which is this notion of projects, right? So the thing about projects is there's so much stuff happening at Stripe. We have like 2,000 skills, right? Projects are this really nice packaging mechanism where we can draw a boundary around those skills and say these are what most people who are doing this workflow must be using. We have projects that are created for projects, like short-lived things. We have projects created for teams, like the people team has a super secure version of Kai in a different project that's backed by a totally secure backend and stuff. The thing about this is, again, it lets one person or a few people who are DRIs of the space to figure out how to get the agent to perform well for everyone. The really interesting thing I have on projects, there's this thing called settings that, like I said, you can use it, you can use a custom agent to power your project. It doesn't have to be Archai, which is pretty good and general purpose. But let's say you have something really bespoke. You can use all the same features we have, but just backed by a different API in the back end and a different harness, right? So really, again, when we talk about AI at the enterprise, there's going to be heterogeneity. It's going to be a lot of different cases. And building this in layers so we can give maximum leverage and customizability. One of the cool things about projects that can be very concrete for people is the idea of tool policies. Now, I mentioned the people team. Let's say you're a person on the HR team who's dealing with a bunch of sensitive information, right? You really don't want the agent to send up a Go Rogue and put that sensitive data into some public Google document that all Stripes can access. That seems like an accident waiting to happen. We don't like that. But you also don't want to tell them, oh, you can't use any tools because your workloads are too sensitive, right? So what projects let us do is to say, for this workflow, I'm going to set up a tool policy that says, in this case, I said the run Hubble tool so that I don't inadvertently put some confidential information into the demo, right? But we could test this out with some other tool. And it's going to kick off what is a human-in-the-loop workflow. So create a calendar invite for me and Wang tomorrow at 11 a.m. Pacific, right? And I set this up ahead of time just to show what a human-in-the-loop flow would look like. But you can see it extends to any other kind of tool. What this is going to do is going to tell me, hey, should be familiar to most people who've used like Cursor or the other, you know, big products out there. But I want to do this, right? The interesting part, and why this isn't the fun part. The fun part is what I showed before, which is that someone who is the DRI of a space can decide that certain tools are kind of sensitive for the workloads that these people are going to be using. So we need a human in the loop to confirm if that action can be taken by the agent. Agents are really good. They're very creative. So we've got to put some restrictions on them so they don't go rogue, right? And projects help us decide. I'd also don't want this to be happening for every person at Stripe. That would be kind of frictionful. So projects are again drawing the boundary around it.

Yeah, I love this because I think a lot of the existing tools let you maybe configure some of this at the individual level, but then it applies to every session. It's not contexted to what you're working on, and you can't share that permission set across different users. And so what I think is interesting about CHI is the permission and context boundaries are very purpose-built for how your company works on things. And I think, you know, when people are asking themselves either, should I build something myself? And does that make a lot of sense? Or do I need to pluck something off the shelf for my enterprise use case? Again, you need to ask yourself how much appropriate or inappropriate friction will this put in everybody's day-to-day work? Because at the end of the day, what you want to do is make everybody's life easier without causing chaos or trouble. And you want the management requirements to go down really low, right? You don't want everybody to have to think every task, like, do I need to turn on this connector, off this connector, connect to this data? And so I do think one of the benefits right now of teams building their own thing is. They can really think about bespoke agents for bespoke use cases, but kind of hide all that complexity from the end employee, the end teammate, and just let them get to work.

again.

This is what happens if you prepare too well for demos. This

is when you do it live. I mean, we believe you. I think what you're showing here, great. You have kind of a skill creator skill or tool. You have a specific spec that you're using to ensure that it's both written well generally for agents, but also written well very specifically for the Kai harness. And then I love this idea of a draft kind of skill editor that you can test and edit and optimize and manage. It's quite nice. I know people just love fussing around in Markdown and Python files, but just a little quality of life UI here can go a long way.