Add Eve (durable AI agents) to the stack — an agent tier for next-forge

[broomva]

Is your feature request related to a problem? Please describe.

next-forge covers the model-call tier through packages/ai (AI SDK), but has no story for the agent tier — durable, tool-using backend agents. Eve (Vercel's open-source agent framework) defines exactly that shape, and a next-forge monorepo is where it shines: agent tools can reuse the same workspace packages, Prisma schema, and validated env keys the apps already use.

Today, users wiring Eve into a next-forge project hit several undocumented seams. I built and verified the integration end-to-end on a fresh next-forge@6.0.2 scaffold (pnpm) with eve@0.20.0, and found:

1. eve init . mutates the workspace root — rewrites root engines.node (>=18 → 24.x, Eve's hard minimum) and appends a dependency-hygiene block to pnpm-workspace.yaml. Surprising if undocumented.
2. server-only guards block agent runtimes — @repo/database's root entry (and other packages') carries import "server-only", which only the Next.js runtime satisfies. Eve agents run on Nitro, so direct imports crash at boot. Workaround: import @repo/database/generated/client + @repo/database/keys directly.
3. Tools must bundle to a single module — dynamic import() inside a tool fails Eve's build.

With those documented, the integration works cleanly: durable sessions with tool calls against @repo/database, graceful degradation when DATABASE_URL is absent (matching next-forge's optional-integration philosophy), eve build, typecheck, and eve eval --strict all green.

Describe the solution you'd like

An addon guide — docs/content/docs/addons/eve.mdx — following the existing addon shape (c15t, Trunk): scaffold apps/agent as a workspace app, a tool that reuses @repo/database, evals, client wiring via eve/react, and deployment as a separate Vercel project. I have this written and dogfooded, and will attach a PR.

Beyond the guide, three deeper (discussion-only, not in the PR) opportunities:

1. First-class apps/agent in the template, gracefully degrading like every other integration (no AI_GATEWAY_API_KEY → agent disabled).
2. Runtime-neutral entrypoints on @repo/* packages — e.g. a conditional export or a /server subpath without the server-only guard, so non-Next server runtimes (agents, workers) can consume them.
3. Node 24 baseline — Eve's floor is Node ≥24; the template currently declares >=18.

Describe alternatives you've considered

• packages/agents as a thin wrapper (like @repo/ai): doesn't fit — Eve agents are deployable apps with their own build/deploy lifecycle, not shared libraries.
• Documenting inside the AI package docs: buries a capability that has its own app-shaped lifecycle.
• Waiting for Eve GA: the guide pins versions and flags beta status instead; the seams above are worth documenting now.

[broomva]

@haydenbleasel — following up on this proposal: I've implemented the first staged ask (a first-class apps/agent) as a code PR (#757), with the companion docs page in #756.

Both are dogfooded on a stock scaffold under bun — eve build, a provider-free eve eval, ultracite check, and a live /eve/v1/session smoke all pass — and kept intentionally optional and minimal-diff so they don't touch the other apps (the agent degrades to a deterministic offline fixture when no AI Gateway key is set, so bun run dev/build stay green with zero keys).

Two design points I'd value your read on before taking it further:

• Ask 2 (runtime-neutral @repo/database entrypoint): I kept the generated-client import workaround to keep the diff small, but I'm happy to add a guard-free /server subpath if you'd prefer the cohesive fix.
• Node 24: scoped engines >=24 to the agent package only (root stays >=18); easy to bump the root instead if you'd rather standardize.

No rush — just flagging there's working, reviewable code whenever you have a chance, and glad to adjust to whatever fits next-forge's direction.