B4.run Agent Framework

What does this agent do, and when should you use it?

B4.run is a TypeScript framework built around LangGraph.js, adding file-system routes, generated types, local development and testing conventions, and persistence primitives for agents and workflows. Developers define an `agent`, `workflow`, `graph`, or `chain` in a route's `src/app/**/index.ts`, with shared tools, route-local tools, and runtime policies available. Tests can replay fixture responses offline; state defaults to SQLite-backed storage, whose persistence across restarts depends on retaining the app root and SQLite files. The default build emits a runnable Node server, a Dockerfile, and LangSmith graph artifacts. It requires Node.js and LangGraph.js; B4.run does not host the app, provision infrastructure, or manage secrets.

Create a TypeScript project with npm create b4-app@latest, then export agent() or another supported entry from a route's index.ts; B4.run discovers the route and generates route, parameter, state, and tool declarations. Put shared tools in src/tools/ or alongside a route, then restrict them with tools.deny or require human approval with tools.approve. Permissions can gate shell commands and file paths outside the workspace, and the optional sandbox isolates workspace tools. Develop with b4 dev and run offline tests with committed fixtures; builds can emit a Node server, Dockerfile, and LangSmith graph artifacts. You must validate the runtime, storage, authentication, and provider boundary for your chosen deployment target.

1. A TypeScript team adopting an existing LangGraph.js graph can expose it incrementally as a raw graph route and validate checkpointer behavior per target.
2. A team that needs repeatable local agent tests can replay fixture responses and fail on unmatched interactions instead of silently calling a provider.
3. Developers building agents with restricted tool access can deny tools, require human approval, and gate operations outside the workspace.
4. An app that needs state to survive development server restarts can use the default SQLite-backed storage, provided the app root and SQLite files persist.
5. A TypeScript project preparing a Node deployment can use the default build's server and Dockerfile outputs, then validate its own deployment environment.

How do you install or deploy this agent?

Requires Node.js 24 or later and npm 11. Scaffold and install the starter:

npm create b4-app@latest my-agent
cd my-agent
npm install
npm test

The starter test runs offline with fixtures and needs no API key or model calls. To run the README's live OpenAI navlog example, set OPENAI_API_KEY in server/.env.

How do you use this agent?

Define an agent in a route file, for example:

import { agent } from "@b4run/sdk"

export default agent({
  model: "gpt-5-mini",
  recursionLimit: 100,
  description: "A VFR flight planner for a Cessna 172N…",
  tools: { deny: ["runBash"], approve: [{ tool: "fileFlightPlan", allowAlways: false }] },
  systemPrompt: "You are a VFR flight-planning assistant for a Cessna 172N…",
})

Run the basic starter with npm run dev; set OPENAI_API_KEY for its live model path. The navlog template uses a two-package workspace, with separate commands for the server and Workbench:

npm run dev:server
npm run dev:web

The navlog server listens on port 3002 and the Workbench on port 3010. Its production build and start commands are:

npm run build
npm start

Model credentials depend on the provider; the README also says a local Ollama route needs no provider key.

What are this agent's strengths and limitations?

How does this agent compare with similar options?

Key facts side by side with the most closely related agents.

How does FollowAgents rate this agent?

FAQ