Vercel says internal @v agent routes finance, docs, and engineering workflows

• @v now touches Vercel's day-to-day operations, with rauchg's post naming finance, comms, docs, marketing, engineering, business analytics, per-user memories, workflows, and schedules.
• Vercel collapsed agent sprawl into a router, since rauchg's router follow-up says teams had built dozens of internal agents before @v became the default entry point.
• The public artifact is Eve, because rauchg's post says @v is powered by and shaped the design of @evedev.
• Slack is the current primary surface, while rauchg's channel reply says the goal is multi-channel access with useEveAgent() for arbitrary web UIs.
• Control is the thesis: rauchg's post contrasts owning source, runtime, data, and token flow with using a third-party Slack agent, and cramforce's reply compressed that into ownership of production.

The small reveal is operational: rauchg's post says a skills.sh milestone reminder came from @v periodically checking and reminding him. The Eve project structure docs make the public framework concrete: agents are files under agent/, with instructions, tools, skills, channels, schedules, and subagents. The frontend guide explains the useEveAgent() aside in rauchg's channel reply: it opens durable browser sessions and streams agent events into UI state.

Vercel's internal claim is broad: every day-to-day job now involves @v, and the agent's token use and daily interactions are growing exponentially, according to rauchg's @v post. The remit he listed spans:

• finance
• comms
• docs
• marketing
• engineering
• business analytics
• per-user memories and workflows
• schedules and reminders

The routing model came from agent sprawl. In rauchg's follow-up, Vercel had dozens of team-built and individual-built agents, then consolidated the default interaction pattern around @v.

The shape is simple enough to steal as a mental model:

• central agent as the company front door
• subagents and skills behind it
• delegation to other agents over the network
• occasional purpose-built agents with their own direct front doors

Christmas came early for internal-agent nerds: the interesting part is the routing layer that keeps dozens of agents from becoming dozens of user experiences.

@v is internal, but rauchg's post says it is powered by Eve and also served as the basis for Eve's design. The Eve GitHub repo describes Eve as a filesystem-first framework for durable AI agents.

The project structure docs define the contract by path:

• agent/instructions.md: always-on system prompt
• agent/agent.ts: model and runtime configuration
• tools/: typed functions the model can call
• skills/: procedures loaded when useful
• channels/: HTTP or messaging entry points
• connections/: MCP and OpenAPI services
• sandbox/: controlled workspace files and commands
• subagents/: specialist agents
• schedules/: recurring tasks
• evals/: checks next to the agent directory

The Eve homepage reduces that further: an instructions.md file is enough to run an agent, and the other directories are optional building blocks as the agent grows.

The reminder example in rauchg's post uses two Eve-shaped primitives: skills and schedules. @v was seeded with skills, and it periodically checked for the skills.sh milestone on a per-user schedule.

The skills docs define a skill as a model-loadable procedure using the SKILL.md convention. Eve advertises each skill's description, then the model calls load_skill only when the turn needs the full body.

The schedules docs put recurring work under agent/schedules/, with a cron expression starting the root agent on its own clock. The docs list daily digests, data syncs, cleanup sweeps, and heartbeats as schedule-shaped work.

Vercel also has an official agent-skills repository, described there as packaged instructions and scripts for AI coding agents.

Eve's subagents docs give the router claim a concrete execution model. Delegation has two modes:

• Built-in agent tool: the root agent runs a fresh copy of itself, with fresh conversation history and state, while sharing the root's instructions, connections, auth, and sandbox.
• Declared subagents: specialists live under agent/subagents/<name>/, with their own prompt, role, and tool surface.

The built-in mode can run multiple delegated calls concurrently. Declared subagents narrow the tool surface when the work wants a specialist instead of another copy of the root.

Slack is the current interface for @v, and some subagents already have web interfaces, according to rauchg's reply. The same reply says the goal is multi-channel access.

The public Eve side is useEveAgent(). In the frontend overview, the hook:

• opens a durable session
• sends turns
• streams replies
• exposes raw events
• tracks session cursor state
• defaults to same-origin Eve HTTP routes

The Next.js frontend docs add the deployment shape: withEve() runs a frontend and Eve agent from one dev server and one Vercel deploy, with named agents mounted under /eve/agents/<name>/eve/v1/*.

The sharpest framing came from ownership. rauchg's original post contrasts @v with a generic BigAI Slack integration by naming the control plane Vercel cares about: source, runtime, data, and token flow.

The public Eve docs make one boundary explicit. The tools docs say tools run in the app runtime with full access to process.env, not in the sandbox, and sensitive tools can be gated on human approval.

That is the enterprise-agent bet in miniature. cramforce's reply called it owning the means of production, while gdb's reply called it Codex for helping operate a business.

The detailed case study has not landed in the evidence pool. In rauchg's reply, he said Vercel should write about it, and rauchg's credit reply credited @dmitrykurash.

That leaves the public record split between a production claim about @v and the separately documented Eve framework.

@v already keeps per-user memories and personalized workflows, according to rauchg's post. aibuilderclub_'s reply asked the governance question the thread did not answer: does per-user memory stay a factual log, or does it distill into company-wide skills that become policy?

Eve's multi-tenant memory pattern puts storage deliberately outside Eve. It composes memory from route auth, dynamic instructions, and ordinary tools, while leaving memory size, count, retention, export, and deletion to product policy.