Essay · 6 min read

Eve and B4.run: Choosing an agent framework

Eve and B4.run both organize agents as files. Here is what that structure gives us, and how to compare the client, runtime and deployment choices.

June 18, 2026

Brian Love

philosophyagents

On June 17, Vercel introduced eve, an open-source agent framework. Its use of files and directories caught my attention: an agent keeps its model declaration, instructions and tools in its folder.

I care about that idea in B4.run too. I want a developer to open an agent application and see where its behavior comes from.

Of course, a similar file structure doesn't make two frameworks interchangeable. Let's look at what the structure helps us understand, then at the runtime and integration choices behind it.

Updated September 2026: The comparison below uses the linked documentation and B4.run's current conventions. It isn't a complete feature comparison of the June releases.

Goals#Copy link to section: Goals

If you're evaluating an agent framework, I suggest starting with three questions:

1. Can my team understand and test the application code?
2. How will users interact with the agent?
3. Where will the application run, and which services will it need?

These questions are familiar from web development, and adding a model doesn't make them go away.

What does a file-based agent give us?#Copy link to section: What does a file-based agent give us?

An agent combines instructions with a model and tools. The model requests a tool call, and the runtime executes application code to perform the requested action.

Imagine a support assistant that looks up orders and checks refund policies. As a reviewer, I want to find:

• The instructions given to the assistant.
• The function that looks up an order.
• The policy used to approve a refund.
• The tests for successful and failed requests.

Files and folders give those pieces predictable locations, and we can review a change with the tools we already use for TypeScript projects.

Vercel's launch example uses agent.ts for the model, instructions.md for instructions, and folders for tools and subagents. The launch announcement shows that layout alongside its deployment workflow.

Here is the corresponding idea in B4.run:

src/app/support/
  index.ts
  state.ts
  tools/
    lookupOrder.ts
  skills/
    refund-policy/
      SKILL.md
  subagents/
    research/
      index.ts

Let's quickly review:

• First, index.ts defines the parent agent.
• Next, tools/ holds the route-specific functions it can call.
• Then, the skill holds instructions the agent loads when needed.
• Finally, the research child handles a bounded part of the work.

I like this because it gives us a starting point for answering "what can this agent do?" We still need to check shared tools, configuration and permissions, but we can begin with the route.

Compare the integration points#Copy link to section: Compare the integration points

Here are a few decisions you'll run into while building an application:

The eve details here come from its announcement and documentation. B4.run's Tools, AG-UI, and Deployment guides explain its corresponding APIs.

A table is only a starting point. Let's unpack each decision.

Tool types#Copy link to section: Tool types

In B4.run, a tool's TypeScript input type generates the schema shown to the model. For example:

export const description = "Format a greeting for a customer."
 
export default async ({ name }: { readonly name: string }) => {
  return `Hello, ${name}!`
}

The function accepts a name string. Type generation derives that required input from the signature, so we don't write a second schema for the same argument.

This helps when your team already leans on TypeScript while refactoring, because there's one less copy of the input to keep in sync. The tool still has to validate external data and check authorization at runtime.

Client integrations#Copy link to section: Client integrations

A channel is how a person or system interacts with an agent. A browser chat, a Slack conversation and a scheduled job can all be entry points into an application.

B4.run exposes thread-based HTTP APIs. A thread holds a conversation and its saved state. A client starts a run under that thread, receives the result or stream, and can continue the conversation later.

For browser clients, AG-UI describes events such as new text, a tool call, or an approval request. B4.run's adapter translates runtime activity into those events. The reference web client uses CopilotKit.

If you need another channel, plan for the application work around the HTTP call: authenticating the sender, mapping conversations to threads, handling retries and displaying approval requests. A framework's built-in integration can save time here if it fits those requirements.

Runtime and storage#Copy link to section: Runtime and storage

The runtime executes the agent and its tools. Storage retains the conversation and execution state across requests.

B4.run builds on LangGraph.js. Its runtime keeps checkpoints, threads and permission grants in SQLite or a configured Postgres backend. Long-term memory is a separate store, so choosing Postgres for conversation state leaves the agent's memory collection to its own configuration.

Vercel's eve documentation describes how its deployment uses Vercel Workflows, Sandbox, AI Gateway and related platform services. If you evaluate that path, include those services in your deployment and operations plan.

For either framework, I'd test the same small scenario: start a conversation, stop the application, then continue it. Next, test an approval that pauses a run and resumes after a user decision. Those exercises tell you more about the fit than a "durable execution" checkbox.

Tools that execute code#Copy link to section: Tools that execute code

If an agent can run shell commands, look at where those commands execute. An approval rule decides whether an operation may proceed. A sandbox decides the environment it runs in.

B4.run offers optional sandbox providers, including Docker and Kubernetes. Their network and filesystem behavior depends on the provider and its configuration. For example, Docker's deny-network mode removes network access, while its allow mode leaves egress open and does not enforce a denylist. The Sandbox guide documents those limits.

Evaluate the environment your application will actually use. A container, a hosted sandbox and an approved command on the application host behave differently, even when the agent sees a similarly named tool.

How I would evaluate the fit#Copy link to section: How I would evaluate the fit

I'd build one small application in each candidate framework and follow it through development, testing and deployment:

1. Add one tool that calls an existing service.
2. Write a repeatable test for a successful response and a service failure.
3. Connect the client or channel the team plans to use.
4. Add a human approval before an operation that needs review.
5. Deploy to the intended host and test continuation after a restart.

Then compare the application code and operational setup each version needs, along with what your team already knows about LangGraph, Vercel, TypeScript and the services involved. That gives you a decision based on a working example.

Conclusion#Copy link to section: Conclusion

I'm glad to see more agent frameworks give application code a predictable structure. It makes the instructions, tools and execution easier to find and discuss.

For B4.run, I value the combination of filesystem routes, TypeScript-derived tool inputs and the LangGraph.js ecosystem. Your choice also depends on the clients, services and deployment environment your team needs.

Start with the B4.run Getting Started guide and the eve documentation, then try the same small use case in both. A familiar file tree is a good start. Running your application through its whole workflow will tell you much more.