- Why should a Next.js developer care about Eve?
- What's the fastest way to start (and why templates beat a blank folder)?
- Why deploy to Vercel on day one?
- What does great agent observability actually look like?
- How do debugging and evals stop being painful?
- What's my advice if this is your first agent?
I walked through Eve live at Agent Conf 2026. This is the discovery version — hot takes, almost no code. The talk has the demos.
Why should a Next.js developer care about Eve?
Hot take: everyone is building agents. Traditional infra was not built for them.
Vercel is pushing self-driving infrastructure: infra that understands the app and operates itself. Vercel did exactly the same move for agents. Sites and apps got a platform that matches how you build. Agents need that too: durable runs, channels, sandboxes, and something you can actually inspect after deploy.
If you know Next.js, you already know Eve's mental model. Next.js made websites feel like a folder with conventions. Eve is that same idea for durable agents: one directory, a few optional building blocks, grow only when you need to.
At Agent Conf I asked who had used Next.js. Full room. Who had used Eve? Almost nobody. So this post is for that room, and for you if you've shipped app/ routes and you're about to ship your first agent.
Eve is open source. Docs and templates live at eve.dev. You can also copy prompts for example agents straight from the site (more on that below).
What's the fastest way to start (and why templates beat a blank folder)?
You can start empty:
npx eve@latest init my-agent
That works. An instructions.md persona is enough to have a real agent. Skills, tools, channels, schedules: all optional. Add them later.
Hot take: for your first agent, don't start empty. Start from a template on eve.dev/templates.
That's what I do. For the last 2 decades I've coded from templates, not from zero. Eve templates are cool because you can inspect them by walking the optional configs and Markdown files: instructions.md, skills, tools, channels, the lot. On top of that you can clone the template code as usual, or just copy the prompt simply and go.
A few worth opening:
- Chat: persisted Next.js chat (memory, auth, the web UI you'd expect)
- Slack: webhook + Vercel Connect, ready to deploy
- Software factory (Foreman): GitHub + Linear, then classifier / analyst / implementer / reviewer, then a draft PR
- GitHub maintainer (Kody): digests, mentions, Linear handoffs
- Incident response, marketing team, social, Sanity, Mux…: real use cases, not hello-world
Copy a template that matches the job. Then delete half of it. That's still faster than inventing folder structure while you're also learning what an "agent run" even is.
Skills fit the same philosophy: Markdown playbooks the agent loads when relevant. You don't stuff a novel into every prompt. You drop focused guidance and let Eve pull it in when the task needs it. Browse and share skills on skills.sh. Init gets you moving. Skills make the agent sharp. Templates are how I'd start.
Why deploy to Vercel on day one?
Hot take: if you only chat with your agent in a local TUI for two weeks, you're delaying the part that teaches you the most.
Deploy early. Eve on Vercel is not "also host it somewhere." It's where the agent becomes inspectable.
Agents think between turns. They wait. They call tools. They park for human approval. On Fluid Compute you don't pay for idle think-time the way classic always-on servers punish you. But the bigger win for a first agent is simpler:
Ship it, then watch it.
One CLI deploy and you're in production with channels, runs, and an overview you can actually read. In the talk I showed a Telegram YouTube-summarizer agent: one message in, tools firing, Notion write at the end, and the whole path visible after deploy. That's the loop you want on day one, not day thirty.
If you're already on Vercel for Next.js, this should feel boring in the best way: same platform, now agents next to sites and apps.
What does great agent observability actually look like?
When the agent is deployed, you get a proper Agent overview and Agent runs experience, not a wall of console.log and hope.
A single run with the waterfall: which tool fired, token use, timing, what succeeded. In the talk I opened a run and could see the YouTube tool call, the Notion tool call, cost, cache tokens: the whole story of one user message.
Observability is how you go from "it kinda worked" to "I know why tool two failed and I can fix it before I add Slack."
How do debugging and evals stop being painful?
Two use cases that show why this workflow matters:
1) Debugging real runs
Because runs are first-class, debugging feels closer to reading a Next.js deployment than chasing logs across machines. You replay what the model did. You see the tool boundary. You spot when the agent got creative in the wrong direction. That feedback loop is the DX: the same obsession Vercel has always had for websites, now aimed at nondeterministic systems.
2) Creating evals from reality
Agents are nondeterministic on purpose. Workflows are steps. Agents need room to think, and that means you need evals or you're flying blind.
Hot take: the best evals come from real conversations you've already had, not from made-up golden answers.
Eve makes evals a folder you grow into: score real sessions, catch regressions as the agent evolves. In the talk I called out the 2026 version of DX: agentic experience. You can literally prompt toward evals from prior runs and observability. Self-improving loops stop being a conference slide and become something you can try after your first deploy.
So the argument is practical:
- Deploy early, then runs exist
- Runs exist, then you can debug
- You can debug, then you can write evals that match production behavior
- Evals exist, then you can change the agent without fear
That's the path.
What's my advice if this is your first agent?
Follow this and I promise the experience is good:
- Trust the Next.js intuition. Eve is a folder with conventions, same family of DX.
-
Start from a template on eve.dev/templates, not from a blank
init, unless you enjoy reinventing wiring. Inspect the optional configs and Markdown, or copy the prompt and go. -
Deploy to Vercel early, before you over-polish
instructions.md. - Live in Agent overview + Agent runs. Make observability your IDE for agents.
- Add skills when the agent needs expertise (see skills.sh); add tools when it needs deterministic verbs; add channels when you want it where you already work (Slack, web, Telegram…).
- Write evals from real runs once you've got a few messy, honest conversations.
-
Only then wrap it into your Next.js app with
withEve/useEveAgentif the product needs same-origin chat. Native Next.js integration is there, but discovery starts with a working agent you can see, not with config gymnastics.
Godspeed
PS. Follow me on Twitter or LinkedIn and subscribe to my AI YouTube channel
https://twitter.com/dom_sipowicz
https://www.linkedin.com/in/dominiksipowicz/
https://www.youtube.com/@DominikSipowicz
Top comments (0)