Workspace tabs
Agents
Design the AI agents the project ships, SDK by SDK.
The Agents tab designs the AI agents a project ships — their tools, prompts, and the SDK they run on. It sits between Backend and Security deliberately: an agent is server-side wiring that calls the API routes planned one tab to the left, and what it is allowed to do is the question the tab on its right answers.
Six builders, one rail
Each entry on the tab's rail is a full agent builder:
- MCP builder — a Model Context Protocol server: the tools, resources, and prompts an AI client can call on your project, over an HTTP or stdio transport. It leads the rail because it is the one that ships a server — the thing the agents below it can call.
- Deep agent — a LangChain
deepagentsagent: tools, subagents, skills, memory, and human-in-the-loop interrupts. - Claude agent — an agent on Anthropic's Claude Agent SDK, with its permission model and custom tools.
- Google ADK — an agent built with Google's Agent Development Kit in TypeScript.
- OpenAI agent — an agent on the OpenAI Agents SDK: handoffs, guardrails, and tools.
- Eve agent — a Vercel Eve agent definition.
If you are choosing between them, the step-by-step guide to building an AI agent covers what the pieces are; the tab is where the choice becomes part of the plan.
Added deliberately, never by default
Every builder starts as an "Add" invitation, and a project exports nothing until someone accepts it. The same builders exist as free standalone tools, where they open on a worked example that teaches the form — but a project must never ship an agent nobody defined, so here each one starts empty, named after your project, and Remove from project takes it back out. Definitions autosave with the rest of the workspace, sync live in a shared project, and are read-only for viewers.
What the Export tab does with them
Every defined agent appears in the Export tab's file tree as complete, runnable code — real implementations, not skeletons, so they never consume Generate initial code credits. The shape each takes answers one question: can the exported app host it, or does it run beside the app?
- An MCP server with an HTTP transport is hostable on the Web target, so it becomes a real
app/api/mcproute handler inside the exported app. A stdio transport — and every other target platform — gets a standalonemcp-server/package next to the app instead; a server configured for both transports gets both. - The Deep, Claude, ADK, and OpenAI agents are long-running processes an operator starts, so each exports as its own sibling package (
deep-agent/,claude-agent/,adk-agent/,openai-agent/) on every target. - The Eve agent exports as a definition directory that Eve's own tooling adopts — no generated manifest to fight
eve init— and on the Web target the exported app additionally mounts it viawithEve()in its Next.js config, so agent routes and session pages live inside the same deployment.
Agents planned here call the endpoints from Backend and operate under the roles reviewed in Security — which is the point of planning them beside the rest of the application instead of in a separate repository nobody cross-checks.