EPISODE 1967

[INTRODUCTION]

[0:00:00] ANNOUNCER: Most AI agent setups today are built around a single session, where one user interacts with one agent at a time. However, that model breaks down when an agent has to serve a business, where thousands of requests can arrive at once and each session needs to be isolated, durable, and recoverable. Getting agents to run reliably at that scale has meant a lot of hand-rolled infrastructure beneath the agent itself. EVE is an open-source, cloud-native agent framework from Vercel that removes much of the agent's scaling burden. In the EVE framework, an agent is defined declaratively through configuration files, and these files compile into infrastructure as code, so the platform provisions only what the agent actually uses.

Andrew Barba is a member of Technical Staff at Vercel, and Shar Dara is the Product Lead for EVE at Vercel. In this episode, they join Kevin Ball to discuss what it means for an agent framework to be cloud-native, why they chose to express agents in plain English, and their view that company building is becoming agent building.

Kevin Ball, or KBall, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript Meet-Up, and organizes the AI in Action discussion group through latent space. Check out the show notes to follow KBall on Twitter or LinkedIn, or visit his website, kball.llc.

[INTERVIEW]

[0:01:42] KB: Andrew, Shar, welcome to the show.

[0:01:45] AB: Thanks for having us. Happy to be here.

[0:01:47] SD: Yeah. Thanks for having us.

[0:01:49] KB: I'm excited to get to know you guys and to learn a little bit more about EVE and this new agentic framework. But let's start with you. We'll go to Andrew first. Can you tell us a little bit more about your background and how you ended up working on this project?

[0:02:01] AB: Yeah. I've been at Vercel for some three and a half years now. I was actually a Vercel customer, maybe one of Vercel's very first enterprise customers back in 2020, so it had been an unconventional path to Vercel. Yeah, I spent my first year and a half or so doing all CDN works, a lot of deep systems, distributed systems, edge networks, firewalls, security stuff, things like that. Then, basically went over to the other end of the business and worked on billing for a good year, which is where I met Shar, so Shar and I were leading - we're leading the billing team at Vercel for most of 2025. Then, yeah, February came around this year and we had a really interesting opportunity to look at what does it take to deploy agents to Vercel, and we came up with EVE.

[0:02:48] KB: Awesome. And Shar, how about you, your background and how you ended up here?

[0:02:51] SD: Yeah. I've been in Vercel for a year and a half. I was in the billing space for a decade before, so that's where I joined Vercel and the billing team, where I worked with Andrew. Earlier this year, Andrew's like, "You want to join build EVE?" Of course, I loved working with him, so great opportunity.

[0:03:11] KB: Awesome. Well, let's start then with a little bit about EVE. It's brand new. A lot of folks probably haven't heard of it. What's the high level of what this thing is, and then we can dive into the details in a little bit?

[0:03:22] AB: Yeah. I mean, so EVE, it is a cloud native agent framework. The reason I say cloud native is, I think most people when they're using agents, they're probably running a process on their computer, and so they're familiar with working with these things locally. Very familiar. So, your Codexes, Claude codes, open codes, things like that. These are obviously very, very powerful, harnesses that people are interacting with in the machines, but we really want to look at how do you use something like this in a multiplayer cloud environment and what is putting these things in the cloud actually nearly to do. It turns out, there's a lot of different products that go into making that happen, and so EVE is a framework that basically stitches together with very good defaults, all of those types of products to give you a very robust out-of-the-box harness that lives in the cloud.

[0:04:11] KB: That makes sense. One thing that immediately strikes me, to follow up on there, is like, okay, what makes for it to be different if it's cloud native, right? I'm thinking about all these folks who got excited about OpenClaw, and they got their own Mac mini, and they're running it, and it's not exactly cloud since it's running on their desk somewhere, but it is isolated off in this place, but what does it mean to be cloud native in this context?

[0:04:34] AB: Yeah. Yeah. Great question. The example I love to give is let's take an OpenClaw and let's take an EVE agent, and let's let a thousand people send a prompt at the exact same time, and what's going to happen. The difference between the two is EVE on Vercel, or another platform that you host on will scale out horizontally to meet that demand. We can spin up these harnesses very, very quickly. In parallel, we can isolate these sessions. They're durable. A whole bunch of mechanics behind it for recovery and retries and error handling and things like that. It's a very different use case than just you communicating back and forth as one person with one agent, right? This is really meant to drive businesses, whether that's internal agents for a 10,000-person enterprise, or if you are some B2C company and an agent is your primary product, evil support, that type of multiplayer type of model, and it could do this very, very scalably.

[0:05:31] KB: Nice. Okay. Let's maybe then go one level of detail further. Let's start with, as you mentioned, there's a lot of folks doing agent frameworks out there. Many of them focused at running on a laptop, or a single machine, or things like that, but what kind of prior art were you able to bring into this, and what were the things you said, "Hey, this is actually something brand new. We got to solve this"?

[0:05:52] AB: It started from our own data agent that we built inside Vercel. This is called D0. This was really the first agent inside of Vercel that the entire company was interacting with. It was a lot of work, a lot of hand-rolled systems to go put D0 onto Vercel. We had to wrap a lot of our products, like our service functions and sandboxes and our workflows and various other Vercel products. It was a ton of work by that team, basically just getting it to run correctly before even thinking about what D0 does. In fact, there's this very large layer sitting below D0 that basically, every single agent we would then deploy to Vercel was going to need. That was the first piece.

Then when we actually looked at D0 and what it was, so much of D0's functionality actually came from Markdown files, EAML files, other types of spec files, because D0 being a data agent, it's basically trying to provide the semantic layer. When you say, how many monthly active users are there, maybe that's too obvious, but this semantic layer is telling the agent what these types of words mean. And so, when certain people ask questions, they're using different acronyms and things like that. There's this entire layer that's basically educating the agent. That idea is really where we started. We took two approaches here. We said, well, it has to become way easier to deploy an agent to Vercel in the same durable fashion that D0 was doing. We thought that a declarative file system was really, really interesting. We think a lot of other agents can almost be entirely expressed in English. And so, we took this very dramatic stance in the beginning, where we basically said there was no code. EVE was going to be purely English Markdown text files. Yeah, with those two extremes, that was the very, very early idea behind what EVE is now today.

[0:07:44] KB: Yeah, that's super interesting. Well, and I go back to, I remember a conversation I had, I think, with Tom Occhino at some point about Vercel's vision of automatically provisioning infrastructure and being able to infer that from the application. That requires having applications with certain sets of constraints and structure and all of those different pieces. What does this end up looking like for someone who wants to develop an agent? What is the EVE? Is it an SDK? Is it something where it's like plugging these Markdown files in this place? what does this actually look like?

[0:08:17] AB: Yeah, it is literally a directory. The most simple EVE agent could actually just be an instructions.md file and that's it. Yeah, it's, of course, a framework, because the grammar behind EVE and our slots, those are all compiled down into this manifest and that manifest is basically the infrastructure as code that you just referenced, where we're provisioning things based on what you have. If you add skills, for example, then you get a sandbox. If you define schedules, you get our event infrastructure for schedules, right? But at its core, it is effectively, we call it ChatGPT in a box. If you drop in an instructions.md, you are getting a frontier model as trained and you're getting a cloud hosted version of it.

[0:09:02] KB: Interesting. This reminds me back of the original page router days of NextJS, or something like that. What are the conventions? You said an instructions.md. You've got a directory, you put things. You referenced here, schedules or skills. What are the different primitives you have to play with here?

[0:09:19] AB: Yeah, great question. Yeah, instructions is the identity, of course. I think most people are familiar with this. Skills is the things that you want to progressively disclose. I think skills have been around for maybe a year, a year and a half now. I think people are generally pro adding skills, but I don't think necessarily they understand how it works behind the scenes. The key thing to understand with EVE or any of these harnesses is that is your progressive learning mechanism. Skills are basically giving a hint as to when they should be used, and the models are really good understanding when they need to learn more about something, and so they can take that hint and then basically pull in additional context. D0 is 90% skills.

Then tools, of course. You most likely want to run deterministic code, pull in a deterministic set of data from some outside source, maybe a PostgreSQL database, or some sort of open API connection. Tools facilitate that. Then we have a specialized version of tools called connections. Connections are for things like MCP. EVE has a first-class way to just drop in an MCP URL and we automatically expose those tools for you, so you don't have to think about it. Those are the core primitives. I think that's the brain and the operations of EVE.

Then the next layer that is fairly critical is how do you invoke it? You need to start the agent somehow and this is what we call channels. Channels are basically all your entry points into your harness. We have a default channel, which is just some HTTP route. This is what our TUI uses. If you were to hook it up to a NextJS app, you're basically using that default leave channel. The more interesting ones are things like Slack and Teams and GitHub. We basically support all the first-party events that you would expect from those platforms. We come up with some opinionated defaults for how we think you probably want to use your agent inside of those platforms, then we, of course, customize it beyond that. That's really the core primitive.

Then it expands quite a bit out from here in much more advanced use cases. We have this concept of sub-agents, which in its most simplest form is effectively context management. You're taking some larger set of tasks that you don't want to blow in your parent agent, and so the sub-agent can go take that and work with it on its own and then report back. Sub-agents also enable completely different ways of building teams around agents. Internally in Vercel, we use sub-agents where literally, entire teams own a sub-agent. Then we have another agent that interacts with those. D0, for example, is actually a sub-agent of another one, and so the data team owns that. We have a help EVE agent, for example, that knows all about how to build EVE, and so the rest of the company can invoke that. That's effectively a sub-agent of our larger agent as well.

Yeah, sub-agents enable really a different way of organizing who owns what. Those are pretty interesting. Then something else that I'm very excited about that is first-class in EVE is Evals. We think it's very, very important when you build a non-deterministic system, like an agent that you can actually test it and monitor it over time and see how it's performing. That could be based on changes that you're making. It could be testing a new model, or different levels of reasoning and things like that. Evals is a very first-class primitive inside of EVE.

[0:12:40] KB: I want to double click on that, because Evals is something, I think, everyone is talking about and trying to do. At least in most of the folks I've talked to and certainly what I've seen just diving in with people in places, it still feels a lot harder than it needs to be. How do you set up an Eval in EVE? Is it a static test case? Are you doing Evals on live queries? What does that whole lifecycle look like?

[0:13:05] AB: Yeah. We have two different types of Evals. The first type is more deterministic. It's probably more of what you're familiar with, where you're looking for conditions to be met and these are fairly deterministic things. EVE'S example of that is you might want to send a query and then make sure that a tool was called. Not perfectly deterministic, because the models might not call it. But in general you can say, "Okay, I have this tool defined," and let's say, you're building a weather agent. When you ask what is the weather, you would like to make sure that the get weather tool is called. Those are a little bit more deterministic, very straightforward to write.

Then we take this one step further, where we let you do, I believe the term is LLM as judge. You can actually reason about responses and grade and score these types of responses. For D0, this is where things can get really interesting and much more complex, where we can actually grade the SQL query that might be generated and make sure that it's looking for the right tables and things like that. An Eval in EVE is literally a - it is a defined eval function. You basically get this test function that you can write what you want. It's effectively a full interface to your agent. You can start turns via prompts. You can trigger things, like human in the loop. Basically, all the functionality in EVE you can programmatically write and set up an eval. You can do as much or little with it as you want.

I think is particularly interesting about the way we have the EVE repo set up is our test suite is in fact a full set of Evals. We actually use our Eval framework to test EVE. That is basically what gives us the confidence to ship new versions many times a day.

[0:14:44] KB: Yeah. No, that's super cool. Okay, I'm going to push on this. You may not have anything. I haven't seen anybody really do this yet, but it's a thing I'm minorly obsessed with. What we just described is essentially, Evals as guardrails, right?

[0:14:56] AB: Yup.

[0:14:57] KB: We have something we believe to be true. We're using Evals to make sure it remains true. It's a AI, or non-deterministic variation on unit and functional tests. A direction that I'm interested in is this concept of essentially, turning prompting into an optimization function, right? Your Evals layout what should be true as an outcome, and then you use maybe an LLM, or something else in the loop to actually iteratively evolve your agent to get it to behave the way you expect. Is that something that you've played with at all in EVE? Totally fine if not. I don't know anyone has. But when we started talking about this, I was like, "Oh, does this make it easier to create that optimization loop?"

[0:15:37] AB: Well, yeah. This is really interesting. I have never thought about it in this way. But if you use a coding agent to build your EVE agent, I think you'll find that it will actually write and run Evals while it's iterating. Part of this is because of the way we expose our docs inside of the package. We hint that you test EVE with evals, and so the coding agents actually understand this. When we work locally on EVE, we have a bunch of fixture style apps. The coding agents are running those Evals.

I think it wouldn't be asking too much to actually prompt your coding agent to get what you want out of here. I think it would do a pretty reasonable job at using those evals to iterate. I've never quite seen it write an eval first and then go build the implementation. But I think you could probably get something pretty close to that.

[0:16:27] KB: Nice. That's cool. I really like that idea of thinking, I think more and more frameworks are starting to do this, where they think of our documentation needs to be designed not just for humans, but for coding agents.

[0:16:39] AB: A 100%.

[0:16:39] KB: It's the right things, put the right guardrails in place.

[0:16:43] AB: Yeah, we had a lot of learnings from Next.JS in that regard where the models are trained on much older versions of Next. It's like, how do you get it to learn the latest thing? Obviously, EVE doesn't exist as far as these models are concerned. Yeah, so we spent a lot of time making sure that the package had to come with LLM-friendly docs. I think we've seen really, really good payoff there.

[0:17:04] KB: Curious, actually, any lessons learned there? One of the things I'm thinking about here is similar to skills. I feel like, you probably want some sort of progressive disclosure, or something like that, because otherwise, the model may get overwhelmed. You don't want to stuff the model with all the context about your whole framework all the time. How did you design those to make that work well?

[0:17:24] AB: Yeah, two things. Our scaffold includes an agents.md file, which of course points at the docs. We also include our change log in the package. This is really, really useful, because the agent basically knows that it only has to look at certain things, like when you start upgrading the EVE versions and things like that. It doesn't have to start from a clean slate. It's really good at knowing a common version 0.2. I see the change log is on 0.5. Let me just look at the diff between that. Then in terms of the docs themselves, the coding agent, like Codex and Claude, whatever, they're so good at knowing that there's tons of files in a directory and not to scan them all. We didn't really do much to optimize there, other than just picking a folder structure for the docs that we think would make sense.

The change log is really interesting. Especially for a framework that's pre-1.0, it's critical, because we're breaking stuff every week. That's the main way that we can make sure people are upgrading without throwing a fit.

[0:18:23] KB: Yeah. No, that's super useful. Actually, that's a technique that I think I've found for a lot of code bases. When you have multiple people in a code base at all, having that change log really helps the agents keep up with what's going on.

[0:18:34] AB: Yeah. Yeah, exactly.

[0:18:37] KB: Different direction here. Still in this mental model of, okay, we're moving from my pet agent living on a box somewhere to these cloud-based agents. One of the big challenges I feel like a lot of us are grappling with is how do you manage things like permissions, authorization? What is this agent allowed to see depending on who's interacting with it and that types of things? Is that something that EVE has primitives for? How do I think about data access control and stuff like that in the EVE framework?

[0:19:08] AB: The funny thing is when we started EVE, we were pretty set on enterprise right off the bat. EVE was, we knew it was going to be code first. We knew that, or thinking about use cases like D0, we expected companies to go build their own EVE agents to run their businesses. Now we're actually starting to double back on more of the personal use cases. The reason I said is like, a lot of the permissioning and whatnot, like that, that was baked very early on. Yeah, there's quite a bit built in in terms of where we look at permissioning, because there's quite a few layers, right? At the channel layer, we basically are saying, who are you? You define what that is.

For Slack, for example, the who are you is going to be your workspace ID, plus your Slack user ID, right? EVE was designed to be multiplayer from the beginning. Basically, everywhere you write code in EVE, you have a context object, and that context object is going to give you things like, who was the current user in this turn? Who was the user that started this turn? They could be different people. Different people can follow up at different times. That gives you the ability to do basic type of authentication, or permissioning where - what I would say is the more traditional permissioning, where if you're writing any typical backend REST API, you're looking at some off header coming in, you're authenticating it, and then you're saying, okay, you can do XYZ. EVE facilitates that, basically by resolving that identity of the channel layer.

Where it gets more interesting is, can the agent perform some action? We have this concept of tool approvals, which basically surface as these human in the loop style messages, and it's completely dependent on the channel that invoked it. All you have to say is always require approval and some tool. If the invocation comes in from Slack, we can render that channel and those had a render human in the loop. If it comes in over SMS, it could take on a completely different form. Those approvals give you a lot of control. You can look at, again, who asks the question and who is asking for approval? Who is then giving the approval? Maybe it's not the same person, right? You may decide that that's okay. You may decide it's not.

This is where EVE really shines as a code first framework. All these cases, we can't necessarily predict how people want to run these types of things. We basically just say, "Hey, go write the code to make the experience that you want." Yeah, so approvals are baked in. Then the last piece, which I think is maybe most interesting, it's something that we haven't even necessarily solved ourselves yet at Vercel, but you hinted at it is how can you see what you're supposed to see? This creates a whole bunch of really interesting problems.

For example, let's take D0. D0 effectively has access to all of Vercel's data lake, right? If Guillermo is asking a question, he may have access to things that when I ask a question that I shouldn't, right? How do you resolve my credentials versus his? We basically have a pretty advanced API, which we called defined dynamic. This lets you resolve different sets of tools, different sets of connections based on the current caller. You could do things like, literally not expose a tool when I'm the one invoking a term versus, say, Guillermo. That's, again, a very advanced use case. It is extremely well documented. The agents do a really good job figuring this out. When you start prompting for this type of behavior, it will learn that this is basically the way to do it inside of EVE.

[0:22:35] KB: That's super interesting. Before we go deeper on the tech side, something you mentioned, so you talked about going enterprise and then maybe dialing back to personal use and things like that. I'm going to direct question over to Shar. Who are you seeing as the key user audiences for this? What is the rollout and usage look like?

[0:22:54] SD: Yeah. As Barba said, we did initially target enterprise, given that that was where most of the requests came from. We have the infrastructure, so it was a no brainer. Also, we were scratching our own itch to an extent. We actually use EVE internally for all of our internal agents. Now we have hundreds of them running on EVE. That was the initial target audience. But very soon after we launched, we saw thousands of our users actually adopting it. Those are not necessarily just within the enterprise segment. You can see them around our hobby users, or pro users building. The range of use cases we've seen go all the way from business agents, what we call what enterprise is launching, where you automate a business function, down to a hobbyist building a iMessage multiplayer agent on a weekend. We want to enable, basically, all of those use cases and let you extend the framework to your needs.

[0:23:56] KB: I love that you started scratching your own itch, right? I think, especially one of the advantages working in a developer tooling company is you can really do a lot of that. I'm curious, if you were to look at the distribution of internal agents that you're building, how much of those are engineering related, versus other functions within the business?

[0:24:14] SD: It definitely started within engineering. Engineering is the function that actually spun up a lot of these agents initially. As we saw the adoption over time, it became go to market, move everything they had on EVE. Then marketing is working on automating content creation, socials and so on on EVE, and so on the rest of the team. You see billing that help EVE was an example. You see examples of product teams that give the product documentation to the agents to answer questions, both on the docs and internally, and sometimes share those with customers directly on Slack. The distribution is still heavy on the engineering side, where those are the main users and builders of the agents. I think you're seeing that distribution get more neutralized as it gets easier to spun up agents and build them as we get to self-evolution, and so on.

[0:25:11] KB: Yeah. No, that makes sense. The advantage of the approach you guys are talking about in terms of like, hey, we make this really easy for coding agents to work with is increasingly coding agents are available to everyone, right? It's not engineering specific. Interesting. I guess, a question. Are there any patterns that have been emerging in terms of how folks end up adopting this? Particularly, once again, thinking outside of the engineering context, I immediately, I'm like, oh, yeah, I'm used to working with agents. I'm doing things and all of that. As you start to see go-to market adoption, as you start to see marketing adoption, are they approaching this differently? Or do their agents look very similar to the engineering developed agents?

[0:25:55] SD: Yeah. There are three types I've seen, I would say. The most common one is the conversational agents, where the agent is channeled through Slack. Mostly we are a Slack company, so most of the communication happens in Slack. That was the initial use cases. D0, for example, which was the initial use case did primarily work on Slack. The second one was background agents. These are mostly the agents job is to run some server report and also send it to Slack, or send it through email to internal folks. The last one, which GTM, for example, is a big user of this, is actually applications. Actually, build an agent, but your front facing is a web app that you're working with. That web app is actually powered by an agent and you also have a chat interface with the agent on the web app. There's the three different types we've seen come out of it.

[0:26:52] KB: That makes me want to - I'm going to send this back maybe to Andrew then. In the case where I'm building a web app of some sort, but it's got an agent-powered backend, how does that interact with EVE? Because you mentioned, this is directory structure-focused. Do I embed these directory structures inside my web app directory structure? Or are these independent repos running in different ways? How does this integrate with the rest of the development lifecycle?

[0:27:17] AB: Yeah, so we wanted a pretty opinionated story with Next.JS. Next has the pages directory and then more recently the app directory. We knew the agent directory had to just work. There's first-party support for that type of setup, where the agent literally lives next to your Next.JS app. But it does not have to be that way. I think in many cases, there's still lots of teams that are deploying a separate front end from a separate back end and EVE can work absolutely just like that, where you deploy your EVE agent as its own project and then you just connect to it over HTTP. That's what that default - we give you the EVE channel, which is basically our HTTP protocol, or stream protocol. It has things like, sending messages and canceling and things like that. Then ultimately, we give you back this durable stream which you can basically use to power any UI that you can think of.

Yeah, it really is just an API. The way we think about it internally is EVE is a back-end framework. It is not a front-end framework. So, yeah, it works with your front ends the way any of your other back ends, you know what.

[0:28:22] KB: Okay.

[0:28:23] SD: On the applications, we actually seen some really cool examples of our users shipping web apps with EVE. Two of the examples we saw was one of them was an open-source CRM. What happened was the user goes in, adds a lead, adds the name and the email. The background agent goes in and researches the lead and completes the whole thing behind the scene. The second one was, I believe, an AI music maker where you go in and add the tempo, but then the agent collaborates with you on the site and completes the music. You are seeing these agentic native applications that are being built. The EVE agent really is the back-end brain behind the scene.

[0:29:05] KB: Yeah. No, I think it's really interesting. This is one of the spaces I feel like is under explored yet. Like a lot of generative UI interfaces are like, let's throw a chat button this thing, or let's asynchronously generate a report. But I think there's a tremendous untapped opportunity for almost collaborative interfaces. What does collaborative document editing look like when you have an agent involved? Right now, you can do that with Claude and their artifacts. You could try to do it in Google Docs with Gemini, but I wouldn't recommend it. I think there's a really rich space here for easy to interact with, agentic pieces.

I'm curious. Andrew, you said, basically, you're exposing this durable stream and now you can do whatever with it. Is there any primitive that is missing there? I feel like, that's pretty low level, I guess, in terms of directing, which is fine for first generation, but I wonder if there are also opportunities there in terms of what are the abstractions that make sense in interacting with an agent inside an app context?

[0:30:12] AB: Yeah, it's interesting. The Vercel lab team is doing really interesting stuff here, I think with tools like JSON render and taking these lower level protocols and producing UIs out of them. EVE, the stream protocol that we have is very low level. You are literally getting delta chunks of reasoning and things like that. It is a lot to work with. The TypeScript client makes this stuff much easier. We have really nice APIs for iterating over the stream and strongly type phases and events and things like that, so you can definitely work a little bit higher up. But you're right, not much. It's still a fairly low-level API.

Yeah. I mean, I'd love to see a lot more done here. I do think EVE is a lot more than just interacting with a chatbot, like you said. We have cool features where when you send messages, you can actually specify an output schema, for example. This is really interesting, because now if you know your UI takes some shape of data, you can agentically generate that thing. This lets you do really completely different experiences and just asking a question and getting some English response back.

[0:31:16] KB: Oh, interesting. Question on that immediately. Do you include built in validation of that schema and serialization of it? Or is this just -

[0:31:24] AB: Yes.

[0:31:25] KB: Okay. What does that look like? Tell me more.

[0:31:28] AB: Yeah. We take the output schema, we basically plumb that all the way through down to the - EVA was built on a tool of agent from AI SDK. Basically, what we end up doing is we actually, we produce a tool called submit result and that validates your schema. It's retrieval, of course. It's a lot of times as agents will call a tool like that and they produce the wrong thing. Then we can hint back to the agent basically saying, "Oh, you missed this required property," and it'll do it again. It's not guaranteed to get your schema, but especially with these frontier models and the way they are today, it's quite good.

[0:32:03] KB: Yeah. They're good at that. Now, the challenge with tool causes that you lose your streaming once you go to tool calls, right? Now you've suddenly got to wait for that whole block to do it.

[0:32:12] AB: No, not exactly. The stream will produce all the reasoning in between, right? Because it's just the final step, instead of getting a message, some English message out, you're just getting that final tool call, but you get everything in between. If you're using some high-reasoning effort, and if you want to, you can inspect all of that, even though you're waiting for some output, you could still see everything in between.

[0:32:36] KB: Totally. No, no, no. I guess, what I was saying is yeah, you're streaming up until that tool call, but the tool call introduces a synchronous block, essentially. You're not getting pieces of the tool, like you're not getting partial schema results along the way -

[0:32:48] AB: Exactly. Yup, yup, yup.

[0:32:48] KB: - which influences the UI you want to build, right? Now you have to have a waiter, or something like that, rather than streaming out the pieces of it as you go. But super interesting. Let's talk a little bit more infrastructure getting back to this, like cloud scale thing. You mentioned a little bit of like, "Hey, if I got a thousand requests, suddenly I can just spin up a thousand different processes to answer this." Very interesting. That now introduces questions around durability, resumability, all those different pieces. How does EVE handle that?

[0:33:20] AB: Yeah. I mean, it really started where we knew we wanted to build EVE on top of workflow, which is basically our version of temporal, I think a lot of people are familiar with. The way we modeled this very early on was a single workflow is a single EVE session. Today, it's actually two workflows, but you can think of it as one. The partitioning is basically, every session is completely separate from every other. There's ways to share data between them, or I should say, we provide guides on how you might want to share data between them if you bring your own storage, but that is the partitioning.

A thousand sessions versus a single session, you shouldn't have to think about that. The cloud should do that work for you. Yes, as soon as that turn starts, you are initiating a workflow. Then we do some clever things. We run on serverless functions, which historically have 15-minute timeouts. These agents obviously can run for a lot longer than 15 minutes. And so, we can do some really clever things here, where every time we invoke a tool, we can move over to another function, and it just continues the workflow.

[0:34:26] KB: Because it's another synchronous break. Yeah. No, this makes sense. Yeah, yeah, yeah.

[0:34:32] AB: Exactly. In the future, we might decide to, if we have a lot of time, a lot left, then we run multiple tool calls on the same function. Today, we actually, we moved to a new function for every single step. As long as workflow gets faster and continues to be performant, you don't notice this, and the agents can effectively run indefinitely.

[0:34:52] KB: That's cool. What about things like durable memory and stuff like that? One of the things that's interesting working with something like an OpenClaw, or a Hermes, or one of these things is that they have as a part of their built-in loops some amount of, "Oh, I'm going to remember this. I will write my own file that I can reference, or I will iterate on this skill that you may be, gave me a first version of, but I can actually modify my own prompts and sources based on your feedback." Are there mechanisms for that type of learning agent within EVE?

[0:35:25] AB: Yeah. This is probably the biggest thing I'm working on right now. All of memory is open NPRs, which you can go inspect if you want to right now. Yeah. I'd say, all of this is - and this actually goes back to what I was saying before, where we started enterprise and funny enough, these types of things aren't necessarily your enterprise use case, but they are very personal agent use case. Now, we're starting to double back and build up these features for the personal case and self-evolution is a really, really important part of that for all the reasons that you just said, right? The idea is you just deploy the out-of-the-box agent and it just starts getting better as it works with you.

There's different forms of self-evolution and I think it's also different. EVE is going to do it a little bit differently than maybe something like Hermes, which can literally just update its code in place and then restart itself effectively. On EVE, we're thinking about self-evolution in a few different ways. Memory is obviously one of them. We are doing a first-class folder called memory, and you will be able to define different memory slots. You would be able to have, let's say, you wanted workspace memory for your Slack channel. This is literally global memory that's shared across all your users, but then you could define an additional slot that is just memory for yourself. Now, the agent actually has multiple memory banks that it can pull and save to depending on what scope you define it.

It's a mix of, we'll give you a really easy personal memory provider, but we think it has the primitives for much more advanced enterprise memory use cases. Hopefully, threads the needle on both sides there. Yeah, so memory is one form, and then the other one is obviously, modifying yourself. Can you add a new connection to some MCP server, or write new tools, produce new skills, things like that. Skills maybe is a special case, or it might actually be close to memory. But for other things, you literally have to write code, right? You could make it happen in EVE. For now, we're going to lean pretty heavily into git. Our customers are using git. What we want to do here is open PRs.

We will do a coding sub-agent that you can define, and that is basically your self-evolution. We'll do all the hard work of when you deploy this thing, it'll have a sandbox for you with your code base. We'll have the right prompts, so it knows when it has to invoke the coding agent to change something. The goal is to effectively just open PRs against itself. That's our model of the VPS world where they just get to change their files.

[0:37:54] KB: Yeah. No, that's honestly a really nice clean model, because it allows you to define whatever level of oversight you want on those.

[0:38:02] AB: Exactly. Exactly.

[0:38:04] KB: If you want to let it self-merge, all right, you can build those automations. You want it to have heavy human review on everything, you can configure that the same way you would anything else. Yeah, that's really nice.

[0:38:14] AB: Yeah.

[0:38:15] KB: You used a term, slots, and this is, I think, the second or third time you used in this conversation. May not be familiar to everyone. Can we define what you mean when you say like, "Oh, we're going to define a few slots for this"?

[0:38:26] AB: Oh, yeah. I use it specifically in memory. Yeah, when I generally say slots, I'm talking about basically, our top-level directories, right? Scales, tools, sandbox channels. Memory is going to be, if I was talking to my coding agent, it would call it an authored slot, is how it would refer to it. It will be a top-level directory. Then inside of memory, we're basically giving you, it's effectively calling, like memory drawers almost, or shelves that have different drawers inside of them. One drawer might be global, one drawer might be user based, one drawer might be channel plus user, maybe you want memory just in specific Slack channels. It'll give you the control over how you want to scope those memories.

This lets EVE do interesting things, where we can control - The classic example is you almost never want a tool call that takes in a user ID, for example, right? You don't want the agent to guess, or think it knows the user ID. What these memory slots do is they're lowering tools that are bound to those things, so it cannot guess the wrong slot.

[0:39:27] KB: Yeah. Yeah. You want all of those permission and other related things to be deterministic under the layer of what the agent does. It just asked for a thing and you say, "Oh, that is scoped to this user. We're going to include that in the actual functional call."

[0:39:40] AB: Exactly. Yeah. We went back and forth on whether we wanted memory to be first class or not. The more you look at cases like that and you realize that you can start grabbing memories from the wrong people and this and that, when we see problems like that, it hints to us that, yes, this does belong as a first-class thing, because we can provide the right guard rails and the nice APIs around them and things like that.

[0:40:02] KB: Quick detail question on memory. How do you expose that to the agent? Is it through a tool call? Is it embedded in the context all the time? What does that look like?

[0:40:12] AB: Yeah. We took a stance here, where we have this concept called provider and the provider can give whatever tools it wants. EVE actually makes, we have no opinion on the tools that should exist when it comes to memory. The model is actually, we deterministically invoke three functions, recall, save and this tools function. The provider, it's entirely up to it on what it wants to do there. The provider that will ship in the framework is a file provider. This one is very, very simple. Recall, it returns the file in full as context. Save, it completely ignores. There's no implementation of save. The tools it provides is basically add memory and forget memory. The agent can add a single memory, in which case, we will re-save the file to blob storage and then forget memory, same thing. We remove the memory and re-save it. That's the file memory implementation.

[0:41:11] KB: Just to make sure I understand then, this is a deterministic thing, it's going to be called, and the result would be whatever gets returned by recall is embedded in the context of the agent from the start and it has access to these tools. In this version, the contents of the file are going to be in every agentic prompt and it has access to save, or forget particular memories within it.

[0:41:34] AB: Exactly. That's the most basic version. This is very similar, I think to Hermes has a user.md file, I believe. This is our version of that. But the APIs we're providing let you go way beyond this. We really wanted to support something like super memory, where all of the recall and saving is done on their service, right? EVE has no opinions on those things. The super memory provider actually looks quite different, where they might provide no tools. They don't want the model calling save memory, or forget memory, whatever. They don't want to do that. Because what they want to do is we'll call save at deterministic times, they actually take that message history and they will go run some agentic process and figure out what to save. It doesn't want to expose tools, because they're doing that in their own service.

Then their recall can do something much more interesting than the file case. They can actually look at the inbound message and say, "Let me recall agentically based on this inbound message." It's a completely different recall.

[0:42:32] KB: Interesting. Recall is called in every turn of the loop, so you could actually change what your embedded prompt looks like based on - Nice. Okay.

[0:42:40] AB: Exactly.

[0:42:41] KB: That's cool.

[0:42:42] AB: Yeah. We call recall. There's a few phases that we call it in. Obviously, turn start is the main one, but we also call it after compaction, for example, because we can't guarantee that compaction keeps your memories around. We'll call recall again after compaction, and someone like super memory, they might actually look at the compacted prompt and say, "Oh, no. We're good. It has what we need. Or no, we have to re-inject." They can do really sophisticated things, and EVE doesn't care.

[0:43:10] KB: In that world, sorry, I'm going way down in the guts here, but are these each turn recall, is that being injected as a new message at the end of the stream? Are you actually editing the system prompt?

[0:43:20] AB: We give you the choice. The default is depend. Yeah, we don't want to bust the prompt cache if we don't have to. We use the role user for memories, but you can override this and you could do a role system. For the file memory provider, maybe role system actually does make sense. But the downside of that is every add or forget does bust the system prompt.

[0:43:42] KB: Yeah, that makes sense. Awesome. That's super fun. Thank you for geeking out with me on that.

[0:43:47] AB: Yeah. It's all open in PR. Hopefully, it launches soon. We'll see.

[0:43:52] KB: Yeah. No, I actually, I was going and looking. You got a lot of PRs open. Actually, that's an interesting question. This is a Vercel project. You all are open sourcing it, it looks like. What's the contribution model? What's the ongoing management ownership model look like?

[0:44:09] AB: Yeah. We have a bit of a funny problem right now, where we want to accept outside contributions, but one of the problems we actually have is because our test suite is hitting models and is actually deploying projects to Vercel, and so it's using a bunch of secrets, basically. We actually have this problem where we can't easily test outside contribution PRs. We actually have to carefully pull them into a sandbox, make sure that they're not doing anything malicious, and then we have to basically recommit them under our accounts with a co-author, and then we can actually run the suite. Yeah, this is definitely a bummer and we're trying to figure out a better process here. It hasn't been the easiest thing. But yes, we want the outside contributions and we've been trying to take in as many as we can.

We obviously have EVE agents internally that are actually analyzing these PRs daily to look for the ones that we should be pulling in. But yeah, the more contributions, the better. The EVE team was really - it was really two people full-time from March until about maybe mid-July, I want to say, and we just brought on four more people that have been doing a great job. Yeah, it's about six people full-time on it now engineering-wise.

[0:45:21] KB: Well, we're getting closer to the end of our time. I have one more question I'm going to put to each of you, and then also, anything that we haven't talked about that you think would be important, we can bring that up. The question for each of you in turn, and maybe we can start with you, Andrew, and then Shar, you can close us out is like, what's the vision for where this is going? What do you see coming down the road, the next three, six? I don't know if we can project out nine months since today's AI age, but what's coming down? What are you excited about?

[0:45:49] AB: Yeah. For me, I mean, one of the very early principles behind Eve was we're going to bet on the models getting smarter. The way we designed the framework was really meant to take advantage of this. I think a lot of other agent frameworks that we had seen, they scaled vertically, where they just appeared to get more and more code. Eventually, it doesn't look like an agent anymore. You have a lot of determinism. It's almost like, these workflow style APIs. What we really wanted with Eve is to go horizontal and basically just say, we are going to bet on the models making the right decisions. This is also generally where the folder structure and things like that came from, where we just want to provide more things for the model and let it make the right decision. EVE is going to stick to that principle. Yeah. I mean, it's clear that the model intelligence is not slowing down anytime soon. We think EVE is going to take advantage of that in a great way.

[0:46:44] KB: Awesome. What about you, Shar?

[0:46:46] SD: Yeah. For me, I think, the way we were thinking about it as a company building is agent building. The idea is that EVE is more fundamental than your certificate of incorporation. Your agent predates your websites, your domain name, and even incorporating the company. You start with the agent and the agent incrementally builds the software factory for you, including your complete software development lifecycle. Your job is then to actually fine tune that factory. We believe that EVE is positioned to basically become that brain of your company moving forward. That's where we're headed.

[0:47:25] KB: Well, that makes me think immediately. What's the hosting story outside of Vercel? I mean, obviously, it's great that you guys can manage all of this and all this sort of thing. But if I'm building my company on top of this, I want to know that I can move it where I need to move it whenever that might happen. How does one host an EVE-based agent framework, or a set of agents?

[0:47:44] AB: Yeah. This is actually very important to us. We do have customers internally that are running EVE on Kubernetes on their own hardware, even. Part of this is taking advantage of what is called a world inside of workflow. This is part of our N10 test suite, where we test different worlds, like a PostgreSQL world, the local world and things like that. As long as you can define a world for your infrastructure and many of them exist, like there's worlds for tons of other providers out there, that is really all you need to host EVE yourself. Yeah, there's a lot more work that we're going to be doing here to make that experience much better.

The key with things like memory and self-evolution and these other types of things is there has to be adapter contracts, right? We can only do so much in the framework without bringing in external things. Dynamic scheduling, for example. That will be first-class on Vercel, but you will need to bring in something. The key is just making sure that those APIs and those adapters are thought of early on in the process and not some afterthought after it already works on Vercel.

[0:48:49] KB: I love it. That's a pretty good cut, unless you guys have something else you want to talk about.

[0:48:53] AB: No, nothing for me. That was great.

[0:48:55] SD: Yeah, that was fun.

[END]
SED 1967		Transcript

	(c) 2026 Software Engineering Daily	1