Eve made the agent boring. That was the point.

Last reviewed: June 2026. This post is based on the public Vercel Eve documentation, Vercel's launch post, the Eve GitHub repo, the current Eve package line, and a last-30-days scan of early community discussion across Reddit, X, TikTok, Instagram, and web coverage.

The migration

We did not need another agent demo

The Deepline GTM agent already worked.

It could call Deepline tools, enrich companies and contacts, list workflow presets, and route execution through our API. The model did not need to learn every GTM provider. Deepline already knew that.

The problem was shape, not capability.

Our previous implementation was a custom broker. That was useful for proving the idea, but every piece of production behavior had to be ours: session semantics, stream handling, auth, retries, model routing, deployment scripts, eval harnesses, and the mental model a new developer needed before they could safely change anything.

Eve forced the split we wanted:

• Eve owns the agent runtime shape.
• Deepline owns GTM execution.
• Skills describe GTM judgment.
• Tools perform actions.
• Evals catch drift before it ships.

What changed

What we gained

The agent became readable as files

Vercel describes Eve as a filesystem-first framework. An agent lives under an agent/ directory with files for agent.ts, instructions.md, tools/, skills/, channels/, schedules, subagents, and evals.

Before, you had to understand the broker before you understood the agent. After Eve, you can inspect the directory and answer the product questions quickly:

• What model does it use?
• What instructions does it follow?
• What tools can it call?
• What skills does it know?
• What channel exposes it?
• What tests prove the intended behavior?

For a GTM agent, that matters because the risk is rarely "can the model call an API?" The risk is "can someone audit why it called that API, with that payload, for that prospect?"

Deployment got closer to the platform

The Eve implementation runs like a Vercel agent, not like a normal app with an LLM loop bolted on.

The default path now covers:

• Vercel deployment.
• AI Gateway model routing.
• OIDC-shaped auth into Vercel infrastructure.
• A standard channel contract.
• Local and production smoke tests that exercise the same agent surface.

Deepline execution still sits behind Deepline APIs. Eve hosts the agent. Deepline runs the GTM work.

Skills finally had a real place

Our first Eve pass exposed Deepline as tools. That was necessary, but not enough.

Tools are verbs:

• deepline_chat
• deepline_execute_tool
• list_workflow_presets
• get_workflow_preset

Skills are operating policy:

• how to run a GTM research playbook
• when contact enrichment is allowed
• how to handle CRM writebacks
• how to choose a workflow preset
• what requires approval before activation

The model should not rediscover our GTM judgment on every run. It should load the relevant playbook, then call tools inside those constraints.

Evals became part of the adapter

The migration forced us to write evals around the claims we were making:

• Does the agent expose Deepline tools?
• Does it list workflow presets?
• Does it load the relevant skill before specialized GTM work?
• Does the smoke path complete against a live deployment?

I would not skip this. Agent demos decay when they are not pinned to behavior. Evals turn the migration into a contract: the agent still exposes Deepline tools, still loads the right skill, and still completes the smoke path.

Tradeoffs

What we gave up

With a custom broker, every behavior is yours. You can invent the stream format. You can decide exactly where session state lives. You can special-case auth. You can route every retry through your own logic. You can patch around edge cases because there is no framework boundary to respect.

That freedom is useful early. Later it becomes the tax.

Eve makes the default path stronger, but it also means you should work with the framework:

• Put agent identity in instructions.md.
• Put durable actions behind typed tools.
• Put reusable operating knowledge in skills.
• Put expected behavior in evals.
• Let the platform own more of the deployment shape.

The other tradeoff is timing. Eve is new. The public conversation is still mostly launch-week interpretation: "Next.js for agents," "agents as directories," and the predictable skepticism that every new agent framework gets. In a Reddit thread on production agents, the sharpest point was not framework choice. It was state persistence, auditability, cost tracking, data storage, and testing. Eve gives those concerns a place to live. It does not decide them for you.

The migration worked because we already knew the Deepline boundary. If you do not know your product boundary yet, Eve will not find it for you.

What we learned

The migration is a boundary exercise

The practical question was not "how do we move everything to Eve?"

The question was "what belongs in Eve, and what must stay in Deepline?"

Here is the split that worked.

The Eve code stays at the adapter layer. Deepline APIs remain the system of record for GTM execution.

Keep tools boring

The Deepline tools are intentionally thin. They validate inputs, call Deepline, and return structured results. The playbook logic lives in skills and instructions, not inside tool wrappers.

That keeps the adapter portable. If Eve changes, the Deepline API contract still holds.

Keep skills opinionated

The skills should not read like generic sales advice.

They should say things like:

• Run research before enrichment when the account context is thin.
• Never write to CRM without an explicit approval path.
• Prefer workflow presets when a user asks for a known GTM motion.
• Treat provider misses as expected, not exceptional.
• Summarize cost, confidence, and next action after every run.

That separates "an agent that can call tools" from "an agent that behaves like our product."

Keep deployment boring

The public chatter around Eve focuses on the file-based abstraction because it is easy to repeat. The operational benefit matters more: a standard deploy path, AI Gateway integration, a consistent agent contract, and a place to put evals.

That made it faster than DIY. The first prototype was not hard. The second, third, and fourth environment are where custom agent plumbing gets expensive.

Bottom line

Eve did not make the GTM agent smarter

Deepline still does the hard GTM work:

• enrich the account
• find the contact
• validate the email
• choose the workflow
• respect approval gates
• write back to the right system

Eve moved the agent runtime into a standard Vercel project structure.

Deepline still owns the GTM logic: tool execution, provider routing, approvals, and writebacks. The migration worked because those responsibilities stayed separate.