Vercel "Eve" Framework — Deep Dive (Pros & Cons)

What it is

Eve is the fleet's macrobiotic/voice counsellor, built on the eve framework (v0.38.3) — a TypeScript agent framework in the Vercel ecosystem. Stack: @vercel/connect (edge/serverless runtime), ai SDK v7 (Vercel AI SDK), @ai-sdk/openai (provider), zod, Node 24 / TS 7.

Deployment reality: despite the "Vercel" label, Eve runs self-hosted as eve.service (eve start, port 8093) on the SolOS box — not on Vercel cloud. "Vercel framework" = Vercel's stack, not Vercel's hosting.

Architecture (verified live)

• agent/agent.ts — main loop (multiple .bak* = heavy manual iteration).
• agent/instructions.md — persona/instructions.
• agent/channels/{telegram,eve}.ts — input channels.
• agent/tools/{search-books,send-a2a-message}.ts — tool integrations.
• agent/connections/solos-registry.ts — registry link.
• agent/schedules/daily-principle.ts — scheduled task.
• knowledge/*.txt — symlinks to the shared Obsidian vault (macrobiotics books) — no duplication, vault is source of truth.
• A2A: a separate Python adapter (eve-a2a-bridge.service → :9902) bridges Eve's HTTP API (:8093) into the A2A mesh. Eve is not a native A2A peer.

Pros

1. Mature LLM plumbing — Vercel AI SDK gives first-class streaming, tool-calling, structured output (zod). Less hand-rolled than the Python lanes.
2. Clean declarative layout — instructions / tools / channels / schedules / connections each in one file.
3. Native multi-channel + scheduling — Telegram + webchat channels, built-in schedules/.
4. Vault-integrated knowledge — symlinks, not copies → single source of truth.
5. A2A + registry reachable — send-a2a-message tool + solos-registry connection.
6. Portable — eve build + @vercel/connect could lift to Vercel edge later.

Cons

1. Two runtimes, two lifecycles — TS/Node (eve start) vs the fleet's Python (run_.py). Two toolchains (npm vs solos-venv), two deploy patterns, two monitoring paths.
2. A2A is a bolt-on — needs a Python bridge hop (:8093 HTTP → bridge → A2A :9902). Extra latency + failure surface; not native A2A.
3. Memory-isolated from the fleet — Eve has no rows in solos.db memory plane (durable/longterm/episodic). Her "memory" is symlinked book text. She cannot share or benefit from the cross-agent memory bus — contradicts "SolOS = brain".
4. Not actually serverless — self-hosted systemd, so none of Vercel's scaling/edge/zero-ops benefits are realized. The label overstates reality.
5. Credential sprawl + exposure — API keys (OPENCODE_GO, OPENROUTER, TELEGRAM token) sit inline plaintext in the systemd unit file. Weaker hygiene than the fleet's central config.
6. Persona drift — instructions.md + multiple agent.ts.bak* = manual, ad-hoc iteration outside the central persona system.

Verdict

Eve is a well-structured TS agent but sits outside the SolOS brain (own runtime, own memory, bridged A2A). Fine for a single-purpose domain agent (macrobiotic voice); as a fleet-wide template it would fragment memory + ops. Recommendation: keep Eve's TS stack for her niche, but (a) route her memory through the shared plane, (b) move her secrets to the central config vault, (c) treat the Python A2A bridge as tech debt to replace with a native A2A shim.