The Agent Harness Battle That Will Shape Every Builder's Stack

Everybody, welcome to the Self-Aligned Podcast. Uh, we talk about AI on the front lines of AI, being AI builders ourselves. My name is Robert, co-founder of Epistemic.me. We build Clarity, which helps AI builders solve for the problem of right context, right time, scalably. And I'm joined by my co-founder and CTO Jonathan McCoy, um, who's also an AI nerd. And in this pod, we are introducing a series of Self-Aligned called Your Weekly AI Clarity. So we're just going to be like all the other AI nerds and builders out there, reacting to the hottest news in AI and giving our own takes of the implications for AI builders, uh, in the micro and in the macro. Today we're looking at the next evolution of the Agents SDK, uh, from OpenAI. They just dropped an open source SDK with some new standards and schemas to give us language for building agents and harnesses at scale in the enterprise. Next, we'll go through Amazon Bedrock and their partnership with OpenAI for said SDK. Cursor also dropped an SDK for building agents and harnesses right in the same week. So we're going to kind of take a look at the differences. We'll go into a deeper dive of the anatomy of an agent harness. From the perspectives of two big players in the AI game around evals, LangChain and from Arise. And then we'll look at headless agents. So unlocking scalable automated agents. Cloudflare came out with some stuff. Salesforce announced that they're going full headless. Um, and then lastly, we'll touch on a new video from Y Combinator about how to build an AI-native company from the ground up. So to start with, uh, in this we're just going to be reading and reacting to things, uh, and we'll share our screen as we do that. You'll see here we have OpenAI, the next evolution of the Agents SDK. Jonathan, I guess, uh, you and I have talked about this in our team meetings, but any big things that stand out to you with the new Agents SDK from an AI builder perspective?

Yeah, I think, um, Yeah, so OpenAI released this update a couple of weeks ago and it was an evolution of their SDK. I think one thing, it's, it's open source. And so there's Python versions available on GitHub, which is cool. And the other thing is that they're announcing a partnership with Amazon AWS Bedrock. So you can use the same harness to deploy your agents on Bedrock. So that's a pretty empowering set of capabilities. I think What I was— the first thing I took away is just like how simplified the agent harness was. And you've heard like the word harness, harness engineering has come up a lot. Sam Altman himself is saying like how critical, you know, building the harness is to getting the models to work and how it's just kind of embedded now. And so, yeah, there's a lot of great tools they provided here. I think maybe the first one I was drawn to is the sandboxing capability and creating environments for your agent. That you can run and test them out in a sandbox environment.

Yeah, and we actually have been thinking about this ourselves and building Clarity API to power the context intelligence layer that we see forming for enterprise teams in the future, which is, where's a sort of incubation area where you can make sure your agent grows up from zero to one before you release it into the wild, right? And then OpenAI came up with, here's sandbox. Like, let's just reuse the term from the traditional software development lifecycle. You have a sandbox, same idea for agents. So this was really great because we've been revving on a milestone in our product roadmap around this, um, and this gave us much better understanding of how this might work, uh, for like an enterprise team trying to run a sandbox agent and then getting it out to production. Um, I'll share a couple screens here On the left is Harness in compute. On the right is Harness separate from compute. And it's essentially the left side basically says, hey, like, you want to run this agent with a Harness inside a sandbox, it's convenient for prototype. But as it says here, it puts orchestration and model-directed execution in same compute boundary. Super important, I would say, for enterprises because you have a lot of compliance and regulatory requirements where you would want this thing incubated first, right? And from a developer experience perspective, it makes a lot of sense to have this orchestration execution in a lower environment, but also in a very informed way and highly considered way. So they even talk about this intercept call. So a coding sandbox cannot execute untrusted HTTP requests. Makes a lot of sense. We've seen some production environments go down this week from letting an agent YOLO a prod database. And let me go down here. There's like the section on when to use a sandbox. So Jonathan, you've been thinking about this for our own Clarity API architecture. Do you want to say more on that? I haven't caught up with you on that actually. I'm sure you've evolved your thinking since we first looked at this in regards to our own work.

Yeah, I mean, we've been talking about, you know, agents and using evals for, for sort of agent readiness and calling that incubation. And as I got to understand the sandboxing capability, I think what I was trying to do there is kind of distinct from the sandbox, which really is just like separation of concerns and lets you like test the runtime environment and all of the context that you need to do that. So I took this as like more of We need to know it because it's an OpenAI best practice and it's like just kind of, you know, a methodology that is being evolved to, you know, test your agents before, you know, in a sandbox environment before you like sort of throw them out in the wild to run. And so I think some of the key concepts here, like the separation of concerns that they are talking about, are things that like every agent builder is going to want to know. That's how I've, you know, brought in my own learning.

Yeah. Yeah. And towards that, there's clearly going to be an agent builder consultative ecosystem, right? That's what we're getting at with the whole Amazon Bedrock managed agents. And within here as well, oh, here, they're trying to sell me on stuff. Within here as well, Jonathan, you have found that, let me pull that up, that there is indeed like a services layer being formed that OpenAI and Amazon, I'm reading the tea leaves, but I really see a future where it's not just the McKinseys and Accentures of the world. They're really trying to form this standard with great language and direction for what is best practice so that enterprises themselves could build agents that are production-grade. But also anybody who's running an AI consultant shop could do the same for enterprises. This makes a lot of sense to have a standard that is open. And so they have these SDKs here. Here's the TypeScript one and here's the Python one. We'll link this in the show notes. The Python one already has 25,000 stars. The TypeScript one has 2,900 stars. That's interesting to just note the differences.

I think they might've just released the TypeScript. Like it wasn't released a couple weeks ago.

Oh really? I, oh, okay. Yeah. I mean, there's, things are moving at a mile a minute. I thought they released it right when they came out with it. Or at least I saw it at the top of their documentation here. I just assumed that people are just liking the Python SDK more, was what I thought. But I think you might be right. Maybe it's like just released a little later, the TypeScript one.

Yeah, it's hard to keep up.

It is really hard to keep up. There's something else on this that I wanted to go into. Details about becoming a certified AWS partner. Basically, you can qualify your small firm for an AWS certification to work with customers on Amazon Bedrock Managed Agents. And you'll generally target one of two main designations from them. AWS Service Delivery Program, specific to a particular kind of service, or the AWS Generative AI Competency, which is broader, more prestige. So one is more niche, one is broader. You'll get different kinds of business. And something that's interesting for the AI builders out there who are taking a forward-deployed engineer approach, as we are trying to go to market to build clarity and get the product-market fit for our startup. We're taking these enterprise service contracts to deliver agents greenfield or make brownfield agents better, objectively and measurably better. Those are hard problems we're seeing in the enterprise space. So we saw this and obviously we're thinking like, How do we get access to this deal flow, right? Like, and I'm sure other people are thinking it too. So it's interesting. They have some requirements now for builders to understand. For the AWS Service Delivery Program, the specific more niche one, you need 2 case studies. For the AWS GenAI Competency Program, which is broader expertise, meaning your firm has proven broader expertise across the generative AI development lifecycle, strategy, security, application development. You need 4 case studies, and at least 2 of them have to be public. And then they have a different tier, which is like partner tier, uh, for launched opportunities. Um, they had this cool pro tip for small firms: if you're a minority-owned, women-owned, or veteran-owned business, you may qualify for the AWS Think Big for Small Business program. That's pretty awesome that they're opening it up that way. And that gives us a specific target, right, Jonathan? Which is let's get a couple case studies out there and then we could hook into that deal flow, essentially. At least that's how I'm seeing it as CEO.

Yeah, I thought that it was good. You know, like what should our case studies look like and what kind of rigor does AWS apply for vetting partners? Probably a good thing to understand. You know, because we have several case studies at this point.. And I think like stress testing them against the requirements for AWS partnership is, is probably the same lens that like somebody that we haven't built trust with is looking at our company with, you know, like, uh, what, what are the case studies? What, what have you done? What can I expect from you? Is probably the best way to communicate, uh, capability.

Definitely. So yeah, we're just scrolling through this like AI, AWS AI companies partner solutions. So you can see the different partners here. I'll just click, uh, is this the right— oh yeah, okay, yeah, let's click this. And you could just be on this marketplace if you have, uh, the requirements met. And obviously there's a lot of traffic going here from enterprise. So it looks like some people are doing AI-driven retail and e-commerce, more specialized AWS generative AI strategy. This one looks like they have case studies. You can create a proposal from here. That's cool. You can request an offer. They have a one-page overview. What does this look like? Okay, interesting. So it looks like they even have like, just not even we'll build it for you, but just we'll help you create some strategy around it. I'm always a little wary of that where you're just selling a deck essentially. Right. Yeah, let's look at this though. This Kalent has 34 case studies. Consulting services, life sciences, resilience design, healthcare. Okay, let's look at one of these case studies and see what this looks like. So it's a blog post on this firm's website. The particular challenge: de-identifying protected health information. Just zoom in. Kalent designed and implemented a comprehensive AWS-based solution with two main components. HIPAA-compliant medical image de-identification, life sciences MLOps infrastructure, some level of governance, and it looks like results. So cost efficiency, 10 to 20% reduction in trial executed costs. Okay, so that's cost savings, accelerated biomarker development. That would make sense for their space. Doesn't look like it gets too much into details, but it does name the problem. Yeah. And it doesn't, it doesn't name even the client. So you can even have the, it looks like AWS is accepting that, like, doesn't have to be a named client. It could be anonymized case study.

Yeah. They think they can be private or public.

Yeah. Reading this, I can't even really tell what they did. Did they just ship a deck? Okay.

This kind of reminds me of like playing the grant proposal game if you're an academic.

Yeah, definitely.

And this is, it's just a way of attaining credential so that other people get signal for like, you know, what what your background is.

Yeah, totally. So the— oh, and I see Pinecone here. That's cool. Pinecone vector database. Um, yeah, so that's, that's really awesome. I— this gives us and other AI firms doing consulting, like, services plays a specific target for, uh, your motion of landing your first couple case studies in this shape of requirements. Looks like it could just be anonymized case studies to meet this one. Um, but problem statement, the solution, and the result was really what I saw there. So that gives us a good kind of idea for, for what it takes to get on their marketplace as a certified partner or designated partner. Glad we could dive into this a bit more. I'm gonna— we have some case studies already, so I think we could just ship those over and see if we could just be hosted on the marketplace. I'll take an action item for that. And that could just be a potential other acquisition channel for us.

And it's, it's just particularly interesting now that it's not just that you can use the whole AWS infrastructure, but that OpenAI directly met the Bedrock offering with their Harness. You know, and so I think we're all, you know, 2026 is all about agents and getting agents live and working and useful., and this, this AWS Bedrock, like, partnership seems like a pretty big deal, um, that they just— both OpenAI and Amazon were seeing what their customers wanted to, like, simplify the process of deploying agents. And it— and that's— so it's the first peak time that piqued my interest in, like, being an AWS partner was seeing this, um, and seeing this capability because I was just like, oh, it seems like a no-brainer. It seems like the thing that customers have been asking for for a while, it's finally available.

Yeah, the implication meaning there are OpenAI customers and there are AWS customers. There's an overlap in just a desire for, can we just run this stuff in AWS cloud but then have the technical capabilities of OpenAI with some solid standardization and direction to make the agent building easier? So I pulled up this diagram. So this is what you mean by OpenAI harness, right? Like this area. And then obviously at the bottom, OpenAI has a vested interest in this. It's like, well, yeah, if we just get all the AWS customers just using our models, uh, with our harness, that's pretty sticky.

And don't forget that, uh, OpenAI couldn't partner with, with AWS until just like last week, or, you know, whenever they came up with the deal with Microsoft, because Azure had exclusivity, to work with OpenAI until this deal was struck. So, um, that's why it's a big deal. Like, you get AWS and you also get the, the best, uh, OpenAI harness for using their models in agent, uh, situations. So that's pretty cool. It's wor— it's worth learning about and paying attention to as a, you know, as a builder.

I would, I would agree with that. As a builder trying to make money in this era, like, I think this is definitely worth paying paying attention to. It's a, it's a strong market signal from enterprise that there's demand in this direction. So that's pretty cool. Um, anything else on the Agents SDK and this Bedrock topic before we move on to the Cursor SDK?

There's a lot to go into. I— my, my recommendation is just like, it's worth learning, learning about, reading about, uh, and building, uh, some prototypes with. Yeah.

One thing I'd say is kudos to the OpenAI team to make this developer documentation page easy to read. I also really love this terminology at the start here. You have this really nice quick start. You can easily link to things. We clicked on the sandbox agents one because we were like, oh my gosh, that makes so much sense to sandbox your agents, run it, run workloads in a container-based environment, have controls and separation of concerns around it. I thought it was also interesting that they've named particular agent cases. You would probably want some sort of specialist agent. So if you have a bunch of specialist agents, then you need an orchestration agent. And they've codified it here in my mind, where for the last year, AI builders have known this to be a problem, which is when a user talks to your agent interface, whatever it looks like on the UI/UX, affordance, then there's going to need to be a layer, which is what is the user trying to do? And obviously if they're trying to do many things in your particular domain across your workflows, you would need to hand that off to the right agent to handle that and with the right harness, right? So it's becoming clear, like you need a harness around the orchestration layer. And that, that's becoming codified best practice. That's, that's something else that I thought was cool.

Yeah, that's a really great point because you had orchestration and handoffs and they made it like really simple, you know, how to use each one. And well documented.

And could I intermingle or intersect the terminology and ontology they've provided here? That's, that's what we started doing. So, and then obviously read it. I'm reading this a couple times, actually, like pretty slowly, even outside of this podcast to better understand a lot of these terms get inculcated into it, because it's looking like it's going to be the majority of developers are are gonna be thinking with these words. So it's good for us to know if we're servicing enterprise clients that have developers that are using, you know, the GPT models and are deploying on AWS Cloud, we better know the terms. Cool. So let's move on to Cursor SDK. I actually haven't really had the time to dive into this, so we'll just take the time here. Jonathan, have you looked into this more than the tweet that I have in front of us?

Not a whole lot. Like, I just looked at the documentation at a high level.

Sweet. Let's just look at this then, this video. Pretty sweet marketing video. Already, already think that's cool. Also, they're showing you could swap out the model, you could swap out the cloud, run it in cloud or not, and it's just that easy. I think that's what they're trying to convey with this, which is they're trying to make it easy for AI builders to have composability, I think, with their tech stack and flexibility there. Let's take a look at this. Cursor SDK offers developers an agent stack out of the box. You can run agents locally or deploy them in our cloud. Okay, so they have their own managed cloud, they have their own sandbox, a harness around an agent loop and the tools, uh, that it would need to call. Or you could run them locally on your workstation, and then you could choose whatever models. Well, that's interesting. Are they still— are they calling—

oh, I was just saying you can, you can take the, the native, uh, Cursor agent and run it anywhere now with the same, uh, context and tools and runtime environment. It's pretty cool.

Yeah, let's take a look at this cookbook actually. Oh, and they got some customers on it. Rippling, Notion, C3 AI, and FAIR are using the Cursor SDK to build custom background agents, take bugs from ticket to merge-ready PR, and maintain self-healing codebases. That's sort of the panacea for all AI builders that I know, and developers, is self-healing codebases. Anybody who is building self-healing codebases or has achieved this panacea, I want to interview you on the pod. If you're listening to this and you're at Rippling, Notion, C3 AI, or FAIR or anybody else, let me know. I'm really curious and I bet other people would be curious too. How are you doing self-healing code bases?

Yeah, so that's a version of the closed loop agent that you want. Like everybody's talking about like, you know, how can we get our agents to be closed loop? And the self-healing version of that is the, is your coding agent is closed loop to a code base. So, it's kind of aspirational. Like, this is what we want all of our agents to be when they grow up someday. But, you know, we'll talk later. There are some limitations to what can actually be closed-loop and what needs human-in-the-loop, et cetera.

Yeah, yeah, totally. And when we say self-healing, the way that I'm understanding it, I wanna hear from you, is that there is some target outcome of a quality bar for the codebase. That meets the real world in terms of economic value, AKA, do users come back, use it more, are they retained, do they engage with it more, do they pay more, and ultimately, like, keep using it, refer other people. Those are some of what I mean by, like, business outcomes or economic value. And then there's tied to that, obviously, if your quality is really bad, you're going to have lower economic value out of your codebase. If the codebase is a software asset that your company sells, then you gotta make sure the quality bar's high. And I like modeling, like, in my head, I'm like, just think of this as a staff engineer running at 24/7. So what would they do? Bug comes in, they triage, and hopefully they get a fix out fast, right? To maintain the quality bar. So self-healing to me kind of means that, making sure the business is still making money, making more money, tied to the health of the codebase, the quality of the codebase. Is that how you think about it, Jonathan, for self-healing codebases?

Well, I think there's some specific, like, you know, here's a code base and it has, it needs to be healed as in it has an error somewhere. And you're going to see that in your production logs. So, you know, like the code being expressed in the real-time runtime environment, you're going to see that in terms of bug reports from your users. And so to me, that's what self-healing means is like, it can take those errors and you could just like have a background agent running with Cursor that automatically promotes a fix, a PR, deploys it to production, and then checks the logs to see if it actually did fix that bug. So I think it's pretty concrete if you just think about what are the error sources and what needs to be healed. And that's what this SDK does is like, right now you can use Cursor in your IDE, you can use it in your CLI. This SDK makes it so you can just take it and put it and run it like in the background on a server and it, it can be monitoring your logs and fixing things without, you know, necessarily even human intervention. That's really next level.

Yeah, that's the panacea for sure. Really interesting. That kind of gets into later, like, cuz this thing costs money, right? So if you're running it 24/7 and it's making decisions, we get it sort of into the economic agents as economic actors conversation, which we're gonna talk about later with headless. So we'll go into that in a sec. But this is cool. Okay, use the full Cursor harness. Agents launched through the SDK benefit from the same harness that powers Cursor across our desktop app, CLI, and web app. Uh, there's sort of a, there's sort of a story here that Jonathan made me privy to around— because there's so many things happening all the time, like we're catching them all the time and we're both catching each other up all the time— which is, hey, you could use that same harness across anywhere now, uh, to do that self-healing sort of case, uh, in other cases too. So what do you get with that? Intelligent context management, codebase indexing, semantic search, and instant grep help agents get to the right outcome faster and more efficiently. That's what Cursor is promising. MCP servers— agents can connect to external tools and data sources over Studio or HTTP, either through a.cursor/mcp.json config file or pass inline on the call. Skills makes sense. Hooks makes sense. Subagents makes sense. Build on any model, so there's that composability and flexibility for developers in their tech stack choices. Oh, this is cool, the use cases. This is great. They named this in their tweet, but let's, let's go in order. Fair cursor offers a great cloud experience for running many agents in parallel from the editor and CLI. We're excited about the SDK as a path to running our own programmatic agents on the same cloud runtime Without managing VMs or working around memory limits to keep our codebase healthy without constant developer intervention. That's by Senior Engineering Manager at FAIR, George Jacob. Rippling's building Slack bots, customer support automation, and a harness for internal background agents with Cursor SDK. Interesting. And they name the flexibility, access to runtimes and models, It lets them consolidate deployments instead of wiring up different interfaces for different workflows. That's certainly something I'm hearing on the internet is just, uh, as a pain point. So it's cool that Cursor is meeting that. Notion. The Cursor SDK lets us, lets us hand off work in Notion, specs, plans, and bugs to reliable cloud agents using the right model for the job without breaking flow. An engineer can log a bug in Notion, hand it off to Cursor, and get back a reviewed PR without leaving the page. That's pretty dope.

That's a pretty sick—

Yeah. C3 AI. I am quite interested in this. So they have C3 Code, which is an AI application builder, which lets you describe what you need in natural language and handles the rest with autonomous coding agents, the design, the config, the testing, and the deployment. So Cursor SDK gives them control over where these programmatic agents run, what models they call. And that's critical for their customers in the enterprise at scale for strict governance and security requirements.

This is interesting. I read this like they're kind of like a wrapper for Cursor SDK. Yeah, you know, like their whole product can just be a wrapper that adds additional functionality on top of that. That could—

Cody, dude, it's wrappers on top of wrappers on top of wrappers on top of wrappers. That's it. Yeah, wrappers all the way down is the way the world's going.

It's the new stack.

Yeah, it is the new stack. We had the Cursor SDK running our own infra in under a day. Okay, that's something I was looking for, which is with all of these new drops, how the hell are people keeping up with implementing this in production, right? Uh, because the world used to be like, all right, let's test this shit for 3 to 6 months, we'll have like a 2-month pilot, then we'll get into what does production look like. It's like, how do these people get it done in a day? That's really cool. And they're already serving customers. Wow. Yeah, interesting.

Well, it seems like a case where they probably had the inputs and outputs just kind of like where they had their own agent working or something that was already derived and they could drop cursors in as a replacement. This is pretty impressive.

Yeah. Yeah. And I think that the meta there is in this world where everything is changing all the time, you want ultimate flexibility where you just drop in a model or runtime or whatever. And it goes back to that overall thinking, which is the data is the moat or the evals are the moat or the harness is the moat. So this is cool, uh, Cursor making it easier for people to use their own harness. I heard about this Kanban board concept, uh, it didn't— I saw some sort of demo on it. Let's see if they have that in here. I don't know if they do, but I, I saw a video about how Cursor has, uh, for their, for their cloud agents, their cloud agents work from a Kanban similar to how an engineering team would. So then the human could be in the loop as well. I thought that was such a cool developer experience choice, actually, because they could easily not design it for humans, this kind of thing. But they clearly thought about, oh, it's agents plus human in the loop. Interesting. I don't know what this means. DAG task runner. Decompose a task into a JSON DAG, fan it out across local subagents. All right, we gotta, gotta test this out. There's so much to test out. Okay, so that's really interesting. Now we got some competition for this agent SDK, um, play. You see what OpenAI is doing with their agents SDK, and now you see what Cursor is doing. I'm really curious about the whole, like, you could just plug in that Cursor SDK and Harness in a day in production at scale. That's pretty wild to me. That speaks to a trend which is switching costs are going to be low in the future. They're infinitely getting lower as time goes on. I think that's something to look out for in the enterprise space.

Yeah, what do you think of this term harness as a service? Because I think you're looking at OpenAI, you're looking at Cursor, you know, is this just the new form factor of service-based offerings?

So I'll speak to it from my vantage point, which is, you know, I think anybody that says that they know everything in the AI game, like, doesn't know shit. And they're just, you know, like, pumping themselves up. I don't know everything. But I'll say, I put out content about AI, and I try to get signal from market about what AI builders are struggling with. And on Threads in particular, lately, I've been getting lots of questions about how do you build a harness? That's the latest hotness, which is The harness is the moat. You could do what Cursor did, which is outcompete Opus in SWE benchmarks. I believe that's what they outcompeted them in with an open source model, Kimi 2.5, plus a really robust harness fed from their curated collection of developer data, how developers code, different kinds of use cases around coding, front end, back end, bug fixes, et cetera, triage. So if that's proven, there's this meta, which is every AI business is trying to think, what can't the frontier models do? AKA, what won't they eat up in the world and where will I survive? What's my little island to build a moat around? So harness-as-a-service, let's, let's thinking about that. I'm combining a few data points, which is everybody's looking for the harness now for their domain-specific economically valuable problems. Which is their island or their moat against the frontier labs. AKA, can I go deeper in a domain than a frontier lab can? And I think that that's like, that's sort of, we're seeing this actually in our pipeline. Like, we see prospects who come to us with that question. And they're like, we have, we see this opportunity. You know, there's, there's a lot of fear implicitly around, especially in the startup world, like seed and Series A, level companies are like, how do we get a harness around our economically valuable workflows? Okay, so if the engineering team is under that level of pressure at a startup kind of environment or a company to get that harness up and running, to get in that virtuous cycle where the harness gets better as the users use it, then it would make sense to me that selling the harness as a service is a great play for these bigger players because it gets them sticky in their ecosystem, right? Another thing I'm riffing here, but I wonder if they've released this open source and it's sort of the drug model where it's like, hey, here's like a hit, and then, you know, at some point you're gonna have other problems, and then we'll upsell you into enterprise offering for this, right? So those are some of my thoughts. I would imagine some really smart AI PMs at these companies like Cursor and OpenAI and Anthropic are thinking about that, where it's like, oh, if that's the problem in the developer experience, to go find your moat, go build your moat. Then if we offer that as a service, we get people hooked early. What do you think?

Yeah, it's just interesting how fast it's moving. I think, you know, like Cloud Code is a harness that Anthropic sold, right? And now we see the harness idea getting abstracted out And, uh, right, like, you know, so then you could build a harness on top of Claude code also. Um, and I think if you, if like, like, let's say there was an opportunity for like, there's a certain class of agents where we take OpenAI's Agents SDK and we just specialize the harness in particular directions for like, you know, say a medical data agent or something like that. Um, and it's just like, it all, and I think that you could say Hey, we have this harness for sale. You can run this version of agents within it and you're actually sort of like, you know, marketing and selling the agent harness itself. It seems like maybe that's kind of like where we're going and we're going to see these big players come out with their versions and probably like specialized niche versions and they're all like creating ecosystems for the types of agents that need to run in particular environments. But, you know, right now we're getting some really great best practices out of the labs and out of the foundation models about how we're supposed to run it. But I think as the rest of us learn how this works and say this, that we probably will see like more packaged open source harnesses, more for sale harness as a service type of offerings. And I think Cursor's just kind of like, uh, you know, an example of like what we might see more of in the future.

You know, that makes me think— I appreciate that perspective— and it makes me think that if harness as a service is here to stay, and then Is there going to be— we've talked about agentic marketplaces in the future, meaning if you have an agent, could you just lease out the compute of that agent for somebody that maybe doesn't want to go build it, but they need to pay for usage of an agent that's already good at a particular thing? So then it's like, is there going to be a harness marketplace? That's what I'm now thinking of.

Yeah.

In the future, it sort of makes sense to me. It's like, if I'm OpenAI, how can I dominate the harness conversation or Cursor? How can I dominate the harness conversation and get people using a certain standard? Then in the future, I get a cut of every transaction of people using different harnesses. For example, if you're building an application, I like to think about the health code coach application, because that's where we kind of started as a company, where personalization, it's more personalization-sensitive health. If you're trying to lose 10 pounds, I always think about this, it sort of depends why you're trying to lose 10 pounds. That's how the agent meets you at your goal. If your goal is lose 10 pounds for let me fit into my tuxedo so my future wife doesn't get my ass, little, little different than a goal of I just got a diagnosis for heart disease. From the doctor, I feel like I might die. So, so you're going to have a different impetus, and therefore the agent's response to that query based on that individual user's goal is going to be a little different, I would imagine. Like, from a product design perspective, like, it, it should be sensitive to that. I call that personalization sensitivity, and that's, that's what we sort of specialize in. Okay, so, so for that, for that case where it's an AI health coach trying to coach you to lose 10 pounds, there's sleep, there's diet, there's exercise. So there's a question there of what's the harness for the best training protocol exercise-wise. Somebody will probably build a really good one for that. What's the best diet, you know, protocol? And you probably have some sort of diet agent that comes up with a protocol for you. You want to harness around that. In the future, I see maybe a proliferation around the edges that the Frontier Labs can't really get to if people get that niche into these harnesses. But if I'm the Frontier Lab and I'm thinking I want a cut of all of those, then yeah, it makes sense to release a standard and then get people hooked on using that standard. It's really well integrated in their code bases and it's helping people make money. Um, and then from one AI health coach, the user's experience is I don't have to leave to a diet coach, I don't have to leave to a exercise coach underneath, the engineering team could just solve that by plugging and playing a different harness. And maybe a different team specializes so deeply in something, like Cal AI might be like, well, that's a great harness for taking a picture for the user. We kind of want to solve for a different part of AI health coaches than that specific niche. So maybe we'll just pay for usage of their harness. I could, this is, This is me riffing a hell of a lot, but I could see a sort of play there around that. I wonder if that will unfold. What do you think, Jonathan?

Yeah, I think to the extent it helps build agents faster, that seems to be like, you know, there's an appetite for agents that are going to do things that are very specific and to the point that you can have specialized harnesses do that as a forward-deployed engineer or a consulting service. You can say, yeah, these are the set of harnesses that we have that are mature, that are ready to spin on agents quickly that can do the set of things that you need. But I also think you probably have upcoming, you know, AI tools and agents that are actually like leveraging— they have a language of harnesses, right? That they say like, oh, okay, I need to spin up a subagent. Let me utilize these harnesses in order to like create the subagents that I need in order to complete the task. And it could even be a bespoke thing. Um, yeah, so yeah, the, uh, it's hard to tell where it's going to go, but I think it's a powerful abstraction, you know. And let's remember how we got here. It was like prompt engineering and then context engineering, and then once you— when you have the agent with the toolchain calls and you need to run it like, you know, in a runtime environment, then you need the harness. Um, and so it's just a continuation of like the evolution.

Yeah, you'll need harnesses actually. Um, depending on your service area. I think that's a good—

Yeah, it's a harness per agent, right?

And just to wrap up that use case, if you have an AI health coach, and we've designed one in the past, there'll be different use cases depending on the user queries, right? It's like, help me make sense of my health data, different kind of agent. Like, let me parse through your PDF and blood panel and then get back with some sort of report versus give me a protocol for exercise and then tell me why that would be good. That would be a whole other set of agent plus harnesses. That's a good point to then intersect with this conversation of what the fuck is a harness. And the Anatomy of an Agent Harness was an article, a blog post that came out from LangChain. This came out a month and a half ago. And then this was from LangChain. And then Aparna, uh, made this X article, What Is an Agent Harness? And she basically was like, hey, I disagree with the LangChain post. I think the post is really confusing to the industry in that it calls LangGraph a harness. LangChain is not a harness. LangGraph is not a harness. These are frameworks designed for humans to build agents. They give you abstractions, configuration options, and a lot of rope. You wire together chains, define state graphs, pick your retriever, and configure your memory. Dozens of knobs, dozens of ways to get it wrong. The fundamental assumption is that a human architect will configure these pieces correctly. There's a quote, "If you're not the model, you're the harness." And she says, "What does that even mean?" And then she claps back and says, "It's a weak argument to cover the earlier 1.0 agent frameworks in the new harness terminology." This is really cool. Have you read this? I think if not, we could take the time to read this right now. I think it's a useful—

I haven't read it yet. No.

Yeah, it's pretty articulate. Let's just do it right now. So, I'll just read it out loud for those on the pod. A harness, per her definition, starts from the opposite direction. The modern harness was not designed top-down from extractions. It was born bottom-up out of coding agents solving real-world problems with working agents. Cursor, Cloud Code, WinSurf, Codex are all harnesses. These products started with a concrete problem, make an LLM write and edit real code across real repositories. In solving that problem, they independently converge on a remarkably similar architecture, a while loop that calls tools, a context manager that compresses history, a permission layer that keeps things safe. The same patterns discovered separately over and over again. We arrived at a number of similar architecture decisions building Alex, our in-product agent for Arise AX observability and evals platform over the last 2 years. Also coming to Arise Phoenix, our open source software, soon. Different domain, same bones. The abstractions that define these common architectures are what we call a harness. A harness is the current architecture born out of general purpose agents designed to solve a wide swath of problems out of the box. And she has this really great diagram here of Harness 1.0 architecture. So system prompt assembly at the top, your CloudMD, your Git context, your environment, your tool list, and then the iteration loop. So this is the while loop that she's talking about. Within this is a certain level of context management for budgets and auto-compact and context window management, the tools and skills registry, what could it actually call? And do, sub-agent management for isolated sessions and spinoffs to solve particular problems to bring back to the main, and then permission and lifecycle hooks for rules and policy. Underneath that is session persistence and recovery, what some people would look at as some level of memory. And then she goes further, Harness architecture. Two things make a harness fundamentally different from a framework. First, a Harness works out of the box. And this is kind of what we're talking about earlier, which is why I'm thinking maybe Harness Marketplace is the play in the future, right? First, a Harness works out of the box. You don't configure a Harness into existence. It ships as a working agent with a fixed architecture. The iteration loop, the context management, tool registry, and the permission layer, all wired together, all already running. There is no assembly step. So this is all out of the box. That's what she's saying. Second, the bigger shift. A harness is not designed for humans to build agents. And this is like her big juxtaposition, or I guess I should say contradiction, to, to what the original LangChain article was about. A harness is not designed for humans to build agents. A harness is designed for the agent to accomplish almost any task. The model reads instruction files and learns your project. It discovers available tools and composes them. It writes its own skills to extend what it can do. It spawns subagents when the task gets too big. The human provides the goal. The harness figures out the rest. I'll pause there. Any reaction so far, Jonathan, to that before we get to the rest of the modern harness conversation that she lays out?

Yeah, I think it's pretty strong opinions, pretty strong language. I think it's really helpful. And like, you know, Arise is a tool that is fairly mature in its own right, and they're on the bleeding edge of how to make, you know, your AI tools work. So this is— yeah, this is really interesting perspective. And I think she's taken some turns here that I didn't expect.

Yeah, I love this, which is when I read this, I was like, I want to talk to Jonathan about this because we're all about goal alignment, right? There's your— there's the human's goal at the individual n=1 level. Why do I want to lose 10 pounds? I want to lose 10 pounds. Why? Right? Like underneath that goal. Then there's the goal in your head as concept, and then there's your sort of stated goal, and how does the agent sort of understand that, right? So the human provides the goal, the harness figures out the rest. When you think about an individual user experience, like for example, if I as an engineer am using an AI-native workflow, I want my pull request to contribute code to my codebase as a software asset that ultimately provides more economic value to my company. And ultimately in between the economic value, AKA dollars in the bank, is a good user experience, is better, is good quality, minimize regressions. And so that's actually one of the things that we're finding is getting the goal of the stakeholders of a pull request or code changes and stuff, that's a difficult problem to solve. How do we align the goals of code changes to the stakeholders of those code changes? In that context for a coding agent kind of use case?

Well, I was going to point out that I think she's— is she specifically referring to harnesses for coding agents in the scope of like her definitions here? And like, and that is one thing that's confusing is I think most of the agent harnesses, the idea of the harness developed out of coding agents. Coding agents are the thing that like most best articulates the use of an agent. But if we, if we were building agents for say, like, you know, understanding customers and like how we use them for personalization. And we might have a user-based agent with a user-based harness that is recommending, you know, personalization in context of a chatbot or something like that. You know, is this— is she meaning for her definitions to apply to the harnesses for the rest of us, or is she just really talking about like harnesses for coding?

Yeah, that's a good question. We'll get into it more. She has this nice, uh, little transition. The components of a modern harness. Just as computer architectures matured in the '80s, we expect harness architectures to mature over the next couple years. Components for Harness 1.0 architecture fall into the following areas: outer iteration loop context management and context compression, skills and tools management, sub-agent management, built-in prepackaged skills, session persistence and recovery, system prompt assembly, project context injection, Lifecycle hooks, permission and safety layer. And the outer iteration loop. The core architectural foundation of a modern Harness is the while loop. She's calling back to that. The way it works is the model uses the system prompt and decides based upon the data what tools to call. It iterates on tools until it is finished. Finished meaning there was some goal outcome stated by the human, connecting back to her previous text. The while loop is the core foundation of the Harness 1.0 architecture. So there's that iteration loop. User types message. So yeah, I guess this is like user does things, but this could just be the coding agent use case. We'll see in a sec. So the inner loop is user types message. There's some goal there. It's not in this diagram, but step 1, call the LLM with the assembled context. And then it's like, should I call a tool? No, text only, break, display. But if I should call a tool to meet the goal of the user, The human? Yes. Execute a bunch of tools. Might be reading file. Yeah. OK. So this is very coding agent-based. Reading a file, editing a file, bash scripts, grep, subagents, push results, call LLM again, see if you've met the goal is, I think, the implicit understanding here. The LLM based on the system prompt is pushed to find tools to use to finish its job. It will compose those tools together, tool after tool, execution after execution until its job is done. The main core architectural component of the harness, a loop over tools that attempts to accomplish any task, is not the core idea behind LangGraph. It is a human-configured state graph. Okay, that's interesting. How do you decide what to pull into context? That is the number one question. How do you decide what to pull into context? How do you get the right context at the right time, especially if your application surface area is quite large across many teams, like human teams, human plus agent teams now. How do you decide what to simplify in your context or compress, and how you decide how to represent large data in the simplified fashion are all about context management. Here's a great graph, uh, image on this. So session trajectory, where we see the session going, compacting, selecting, triggering certain tokens, summarization, and then the context window. Cool. And she speaks about other challenges here. Other challenges revolve around how to pass data to skill or tool calls, what data those skill or tool calls have access to, and how data is returned and using context from the skill and tool calls. Skills and tool management is a set of structures that allow teams to build skills, manage what skills are available, add new skills, and execute skills. Every Harness ships with a registry of built-in tools. I think this is an important distinction because otherwise then you, then you're not, it's not working out of the box as she said, right? Read a file, edit a file, run a shell command, that kind of thing. These skills or tools are primitives. The harness needs to know what tools exist, what permissions each tool requires, and how to dispatch a tool call from the model to the right execution path. When the model says I want to run grep, the harness looks up that tool spec, checks permissions, executes it, and feeds the result back into context. The skills are a layer on top of that tool, those tools. The Harness discovers these skill files from well-known directories, and the model can invoke them by name. This is where organizational knowledge gets encoded. Tools are universal. Skills are specific to your team and workflow. Okay, I'll pause there. That was a lot to absorb. Um, any, any thoughts on, on here? It's obvious that this is like very coding agent specific with her examples. There's a question which is, can we extend this example to other cases? Uh, yeah, what do you, what do you think?

Yeah, I think she is, uh, she is generalizing it for, for generalized agents at this point. And I think, um, the— yeah, I mean, the language seems to be pretty convergent with, uh, OpenAI and Cursor that we just talked about. Um, yeah, I'm actually asking ChatGPT right now to compare the article versus Cursor and OpenAI's, definition. And oh sweet, it says like, can you share with me?

It's really thread. I'll share my screen and just show that comparison. I think that'd be cool.

Yeah, let me get the link to you.

Today most harnesses run subagents as threads with isolated sessions. Tomorrow we expect subagents to run in fully isolated sandboxes or even on separate machines. That is very convergent with, um, how OpenAI and Cursor are thinking about that. Now let me pull up Jonathan's ChatGPT thread to sort of compare the differences. Okay, so going back to what we talked about with Cursor and OpenAI, Cursor is packaging its coding agent product harness as a TypeScript SDK. OpenAI is packaging a more general agent harness plus sandbox runtime primitives.

If you want to see through the lens of this current article, it's the second question in the thread.

The Arise article is basically a theory of what a harness is. Cursor and OpenAI are shipping implementations of that theory but at different layers. Cursor is closest match to the article's definition. It's a vertical harness and already wired coding agent runtime. Yeah, Legitter comes out of the box. There's a Skill Toolchain Registry. You can get it into your production in a day kind of thing for a pretty particular use case. That's what I'm understanding from this. Any other thoughts from this synthesis, Jonathan?

It seems like her definition is pretty well aligned with how Cursor and OpenAI are thinking about it, uh, so far, right?

And it also makes sense from a macro perspective of OpenAI is trying to compete in a more general horizontal case and Cursor is competing in a more narrow vertical case.

Yes. Um, says OpenAI agent SDK is a broader platform level harness architecture.

It can become a full harness when assembled into a specific agent product from its primitives. There's a question there, which is at one point, if you take the time slider to infinity, Cursor is going for speed. Then for a very vertical case. Does an OpenAI coding agent win in the long term for a particular development team's coding use cases in their domain, assembling their own primitives?

An OpenAI coding agent like Codex?

Yeah, well, I guess I'm saying here OpenAI Agents SDK is a general-purpose harness foundation with primitives. So my take high level, is if a team wanted to be very particular around how their AI-native development workflows are, they're injecting their own context around their domain. For example, one case that I'm dealing with right now is I have a team that is interested in how do we manage thousands of PRs across hundreds of developers and make sure that it's all following the same front-end architecture if they're checking in front-end code. That speaks to me around how do we inject the right context for their particular taste and architectural decisions. I would have to dig into the details of would Cursor work for them basically is what I'm asking myself. Or if you were going to give a recommendation, would it be like, here's this OpenAI agent SDK, instead. Or perhaps it's just a different thing, which is Cursor is like, hey, really no switching costs. You don't got to build primitives. It just comes out of the box. Here's the fucking harness. And then OpenAI is like, you know, here's primitives. You can do it all yourself. And then maybe harnesses emerge where those could be shared across. I don't know. This is speculation.

One way to stress test that, I was asking ChatGPT if, um, OpenAI used the agent SDK to build Codex, and it was like, probably not, right?

Well, there we go. There we go. That's funny. I also wonder what kind of harness they built around that for those types of intellectual property, uh, chats, you know?

Yeah, probably Codex is its own harness, right?

Yeah, yeah, that makes sense. That's like IP. Um, so okay, Aparna's article is stricter than OpenAI's position. She argues that LangChain, LangGraph style systems are frameworks, not harnesses, because they ask a human to wire together abstractions, state graphs, tools, memory, and routing. A harness, in her definition, already works. Okay, so that, that to her makes Cursor the harness, like an actual harness that works out of the box. OpenAI has—

That's an important distinction. I didn't understand that before today. I think that's helpful.

That is super helpful. Yeah. So how I'm understanding this, Jonathan, and let me know if this makes sense to you. I'm making sense of it. This is us making sense of shit together and with other AI builders too, putting this out there. In her view of the world, the harness is already working out of the box. You don't got to do anything. It will solve problems by definition. It comes with its own skill registry, toolchain calls, et cetera. And it just works. OpenAI is going for the play of we allow anybody to build harnesses from the ground up. Here are a bunch of primitives. Essentially just a very different play. Oh, I love this. Cool. There's a synthesis on top of her writing.

The checklist. Harness or not harness. The harness, not harness checklist.

Yeah, so checklist for judging whether something is really a harness. Does it ship with an agent loop already wired? Does it manage context under pressure? Does it expose tools and skills to the model, not just to the developer? Does it have permissioning and lifecycle hooks? Does it support persistence, recovery, and long-running work? Can it spawn or coordinate subagents? Does the human provide a goal while the harness manages the execution path? By that checklist, OpenCursor SDK is a strong concrete example of harness. OpenAI Agents SDK is a broader platform-level harness architecture. Oh, and then it talks about us. For epistemic me and Clarity, this is what we're building. The interesting question is not which SDK is better. I was thinking that. It is what is the domain-specific harness for modeling a person, which is what we do. We deal with quantifying subjectivity at the individual user level to better inject context at point of inference to personalize the result. Interesting. Talks about our primitives. Our equivalent primitives to cursors, primitives around repo, file, git, test, PRs will be beliefs, observation, context, evidence, memories, dialectic sessions, sessions, longitudinal traces, and evals. That's pretty cool. Like, yeah, that's great. That makes a lot more sense. Love the distinction.

I love the memory features on these things. Getting pretty good.

Yeah, that's pretty sick.

And actually, this recommendation is exactly how we're implementing in our organization. Like, we're kind of saying, how do we evolve our building agents, which are, you know, the context is built out of PRs and Git repos and, you know, this kind of thing. Whereas we have, uh, like user agents and organizational agents which have contexts that are relevant for those things, just like it listed out, like, you know, how you would want the different data that you'd want in those context windows. Um, so yeah, like the— our, our Harness engineering project has a list of about 20 agents. Some of them are Builder agents because that's what we spend our time on, but a large portion of them are like things that meet our workflows. And we're trying to figure out the best practices, how to build the harness for those workflows.

Yeah. And I think a lot of AI builders are trying to figure out harnesses based on how my social media is popping off with questions around harness engineering. So hopefully for the AI builders listening to this, I think aligning on what does a term or concept mean, that, that is one of the most important things in any product and engineering team. Is what does this thing mean to us? Uh, so now hopefully our dissection of this has given you some sense-making around the terms. Uh, harness in this lens is it works out of the box, uh, and you could build your own harness up to the point where it works out of the box, right? Let's move into this actually and skip the headless agents until the next discussion. I think the headless agent conversation will evolve a bit more into next week's pod. Let's talk about how to build a company from— with AI from the ground up So this is really interesting. YC just came out with this 7 days ago. And actually, yeah, could I just— I'll go and just summarize this real quick. It should just inject this. Here we go. One of the things that came from this video, we're not going to watch it on the pod together. Me and Jonathan have already watched it and I'm just on my screen showing key takeaways for this is if you're building a company from the ground up, think about AI as your operating system. And if agents are your new teammates, we certainly have a— I have a growth agent that helps me with content and like our top of funnel and stuff like that. You have to think about your company becoming fully queryable. So all actions, meetings, code, customer feedback, tickets, etc., are captured as data so AI, your agent teammates, can learn and optimize decisions. Just like humans. Ideally, I always think about Conway's Law. Actually, I have a good image to sort of show here. But this is the evolution of just information routing and why we have had these hierarchies is just to route information to teams. Started with the military, with the Roman Army. Jack Dorsey had a great article on that. We can link that in the show notes. And then there's the idea of Conway's Law, which is your information flow, how your organization is designed, will show up in the design of your system. And that's something I've always, in my 10+ years of being in the software tech game, have seen is how well the organization is designed to maximize information flow. Then dictates whether your product looks fragmented or not. On the left is fragmented, it's in people's heads, humans have to route information. On the right is like, hey, we now have the substrate. Could everybody contribute their decisions and artifacts into one place and then agents and humans could make decisions off of it? Jonathan, what are your thoughts on building an AI-native company from from scratch? Because you've been a 12-time entrepreneur. And I'm sure you've had reflections on like, well, shit, like, what if those other 12 times, like, what if it was like this? And then I'm sure, you know, we're thinking about this now for our own company, right? And we have some implementations of this with, you know, OpenClaw and stuff trying to keep us aligned. Some of your thoughts about agent, AI-native companies?

Yeah, I thought the YC partner Diana did a great job with this. I mean, because it was a really short video too, and I think she got a lot, a lot of the best practices you see seen in the YC community infrastructure. And this idea of the closed-loop agents, and, you know, like that, to me, that meets my mental model of what builds a good company. You want to, you want a company that can, like, be learning and sort of like building process that's repeatable and accomplishes the business's goals, you know, and I think now it's just like, okay, how are we building business processes with Close with Agents that is a symbol that we're learning the processes that accomplish the business's goals. So I thought that it was really well framed and where she talks about, you know, the practice of creating, you know, collecting upstream data and making it a queryable artifacts. I think that is a probably best practice she's seen from her portfolio companies at YC that we should all listen to. And what is it? What exactly does it mean to make it queryable, right? Like, I mean, because we have MCP servers, like that's one form of queryable information. I saw her taking this kind of like to a level where like you don't just want like raw data artifacts in your context window. You actually want to structure the data in a way that they can be queried for the way that the agent needs to use it. And that might mean, you know, taking on something like how Andrej Karpathy's, you know, like wiki system of the PKM, like markdown file wiki system that he was building as opposed to like a RAG system. You might think about like how, okay, these are the MCP servers we need. Then what are like the structured markdown files that like make abstractions out of those that create queryable data that we can actually use in the context windows efficiently? For agents. They got me thinking in that direction. I thought it was powerful that way. And then, and it really just gets you thinking about like, what, how, what agents can I bring to a closed loop? Because I can't. Some of them need a human in the loop, and that should be also part of the design of a modern system. But then, like, you know, how do I sort of tune, fine-tune my agents so that they can be effectively used as closed loop? And I think that's where we get to the conversation on the VALs. And, you know, how we're using harnesses with traceability, we're debugging them, and we're, you know, creating an evaluation system that can say this agent is ready for a closed-loop operation. So yeah, I thought it was really nice framing the video as a whole.

Yeah, definitely. I liked your distinction there of Ultimately, the panacea is closed-loop everything, right? But you got to have the right signal and you got to have the right evals. And then there's a prioritization sort of roadmap of where is technology at with these tools of what can be closed-loop and what makes sense for your business at a certain point in time. Because even with agents and unlimited firepower, we're still founders at the end of the day driving. So we got to decide where do we put our effort, right? Like, uh, one of the examples, real world, I'll give is I built a closed-loop system that I'm still trying to evolve actually, where, uh, we have automated CRO on our website where we're trying to optimize copy. So that, that's like an easy thing. It's like you can imagine you hire a team of marketers for a few hundred thousand dollars to build a loop around let me look at the conversion, the top funnel of the website, let me then A/B test all the copy and how we sequence the pages to eke out gains in the conversion funnel. So then there's a question of like, okay, like that, that's pretty simple closed-loop system because we have the data available to service to an agent. And we have the tools like PostHog, MCP, etc., to expose that data to the agent and then run A/B tests on its own. But there are certain other parts where it's like, could you close loop finding PMF? I don't think so yet. If we figure that out, that's like money printer. Just connecting it to some concrete examples in my head. What do you think of this? The new company structure she mentioned. There's going to be ICs who are builder operators, DRIs, directly responsible individuals who own outcomes. And then AI native founders leads by using AI deeply, not just delegating it.

I was going to say, yeah, that does mimic what Jack Dorsey was saying and what he's implemented at Block with like the different roles and how people are aggregating around them. You know, she doesn't go so far as to say this is how you replace hierarchy, but, you know, like it's a very similar kind of like structure in the organization.

She does mention, and Jack does too, which is middle management, which was the information routing layer, rife with human egos and political land grabs, by the way. Agents don't quite have that. Until proven otherwise. We'll see. She's saying we should remove that so there is no human middleware, just direct first-party data, ideally queryable to all individuals at the company to better make better decisions to move forward the company goals.

So if you want to be a human in the loop, then you're just generating queryable data for the agents to act on.

In other words, yeah, we're all just generating queryable data for our agent companions. I go to a prospecting I learn stuff, I codify that, and honestly, I codify that in the Clarity API with our digital twins, and now it's queryable. And then Jonathan could take that and query that against a pull request to ensure that we're meeting a particular stakeholder's goals, right? So that, I literally think that's such a high leverage part of my job is just processing meeting transcripts into structured data that anybody in our company and organization could use. That's such an important role now. And if you think about it, it's like before, what did we have? We had like, I like this model, which was a millennia ago, fast forward now, then telephones came to life, radio stations came to life. You could understand we're at war now in an instant, comparatively. And now we can get a tweet where boom, we're at war, right? You know, the Iran crisis is happening, like, all right, now everybody knows about it. That's kind of at the macro scale how I think about information routing. In the more micro of a company, an organization, like a team, it is signal of what signal from market where we can then understand how do we capitalize on that demand, uh, from market and inculcate product decisions to capitalize best. Uh, and for our company where we're at is, you know, acting as for deployed engineers getting more enterprise contracts, landing with companies to help them fix and improve their AI offerings, implementing world-class eval methodology for them. We've had some success. And then earning the right to solve more problems. And in those, me and you are not in the same meetings all the time. And even with just us two, it is hard to stay aligned. And so part of the job description is upload these meeting transcripts, make sure the signal is captured in a queryable format. So we could both use it and compound it, right? I, I think, um, that is going to be our advantage, uh, against a lot of bigger companies that we got to beat out.

When you describe that, age of agents is bringing us, uh, when you describe that, uh, one thing I think of is that the age of agents is bringing us towards like these world models that we have to make sense of. And so, you know, every— all those, all those communication channels you're talking about like, it's just, uh, world models that— whether it's the customer world model, the organizational world model, subsets within those, um, you know, that's where all the data is effectively coming down to, is like, what, what's going on? Um, and that— I could see that being like, once we have agents in place that are creating these round-trip information loops, um, we start to need to get more coherent on world models.

Yeah, kind of extending the Harness conversation more, I'm seeing Harness is really How can we build a closed loop system? And if I extend the Harness concept to business, not just the technical infrastructure to make an agent good, how do you know your agent's good? It's making money. It's making your company money at the end of the day. A good leading indicator is the quality bar is good, meets the regression test scenarios, meets your evals that you've well-defined to objectively and measurably make it better over time for your domain-specific workflows. Now, one could imagine, like I've been talking about this concept of like a harness, what around not just the agent and the technical outcomes and the user experience outcomes, but like the business outcomes, like is it hitting the bottom line more? So what Jonathan just spoke of, we speak about this internally a lot, the whole world model concept. How do we model the world from different perspective taking, right? The company's world model, our perspective, And then the customer model, their own individual subjective experience perspective. And how do we build a learning engine around that as a company to better go to market and win? That's how I think about it. Anyway, just wanted to flash a visual that I made around that. And I'm happy to add this newsletter to our pod too. Okay, we've been going for a while. We could go fucking forever because this is like 4 pieces of AI news that we've reacted to. There's like, you know, a billion others, but we're just trying to find the highest signal for AI builders just like us, uh, trying to make sense of the AI landscape, uh, and then turn that into actionable insight for you to better run your companies, uh, and, you know, your practices in AIing better or building better AI. So I think with that, let's end there. Jonathan, um, wanted to say thanks a lot for just being a dope co-founder and helping to make sense of the world together. And hopefully this helps out other AI builders out there. Let us know if you got questions or comments or anything like that around anything we talked about— Harness engineering, best practices, evals, how to objectively and measurably improve your AI products. And then AI-native companies, that's an interesting topic. You can find us on socials. We have our company page, et cetera, et cetera. Follow us on the pod, subscribe, helps out a lot. And we'll try to find you more clarity and signal from the front lines of AI.

Take care.

Until next time. Bye-bye.