# evex — full content > evex is the community registry for eve agents, reusable agents built on eve, Vercel's agent framework. Browse configurations, preview every file before install, and add agents with one shadcn command. This document contains every agent in the registry and every learning guide. The short index lives at https://www.evex.sh/llms.txt. # Agents ## RFP Response Drafter RFP response drafter via Google Drive Connect and sandbox files that cites every claim, Slack-routes SME gaps, and write-backs approved Drive or mailbox drafts without portal submit. RFP Response Drafter is an eve agent that lists configured Google Drive RFP and knowledge folders, exports Docs and PDFs into the workspace, and registers sandbox packs. It drafts sectioned answers, requires a pack path or Drive file citation on every claim, posts leftover questions to Slack for an SME, and writes only an approved Drive Doc or mailbox Draft. A human reviews that draft. The agent never submits a vendor portal. You interact with it through Eve chat and environment variables. Set a Google Connect UID plus RFP and knowledge folder ids, sandbox roots for local packs, Slack Connect for SME questions, and optionally a mailbox Connect UID for Drafts. The rfp-deadline-digest schedule is optional Slack or email. write_approved_draft pauses until confirmWrite is true after SME approval. It is useful when a proposal team wants cited answers without auto-submitting a portal. Drive or disk files become the only allowed sources. The model reads them with built-in file tools. Uncited claims fail closed. Slack holds the SME pause. The approved write-back is a Drive Doc or a mailbox Draft the team sends themselves. - Install: `npx shadcn@latest add @evex/rfp-response-drafter` - Category: productivity - Author: TommyBez - Updated: 2026-09-11 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/rfp-response-drafter - Full source (markdown): https://www.evex.sh/agents/rfp-response-drafter.md ## Inbound Lead Qualifier Inbound lead qualifier via signed intake or Connect CRM/Typeform that scores ICP fit, drafts approved CRM notes, and Slack-notifies hot leads only. Inbound Lead Qualifier is an eve agent that accepts a signed HTTP form post, a Typeform Connect poll, or a HubSpot, Salesforce, or Pipedrive scan. On each run it sanitizes untrusted fields, fail-closes enrichment when the email is missing, and waits for you to approve draft_crm_note before any CRM write. You interact with it through environment variables and Slack. Set an HMAC secret for POST /leads/push, a Typeform Connect UID, or a CRM Connect UID, then trigger inbound-lead-scan. Slack is optional and hot-only. The agent never emails the inbound person. It is useful when demo forms dump every request into a queue. Work-email founders on an ICP domain become a hot Slack ping. Free-mail or instruction-shaped fields stay fail-closed. The cursor file records last-seen ids so cron does not replay a lead. - Install: `npx shadcn@latest add @evex/inbound-lead-qualifier` - Category: productivity - Author: TommyBez - Updated: 2026-09-09 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/inbound-lead-qualifier - Full source (markdown): https://www.evex.sh/agents/inbound-lead-qualifier.md ## Invoice Chase Drafter Weekday AR chase via Connect that drafts mailbox reminders from QuickBooks or Xero and posts an idempotent Slack digest after a paid re-check. Invoice Chase Drafter is an eve agent that reads unpaid invoices from the QuickBooks or Xero company you already connected. On each weekday cron tick it ages those rows into buckets, writes reminder emails into the mailbox Drafts folder, and posts a finance digest to Slack. You review and send the drafts yourself. The agent never calls a send API. You interact with it through environment variables and the chase-open-invoices schedule. Set a Custom OAuth Connect UID for QuickBooks or Xero, a Google or Microsoft Connect UID for Drafts, and Slack Connect for the digest. The agent re-checks each invoice before deliver_ar_digest and only posts when confirmSend is true with a date-derived idempotency key. It is useful when finance wants weekday chasing without auto-send. Current invoices stay in the digest as current. Overdue rows get a Drafts reminder when a customer email is present. A paid re-check drops invoices that cleared after the first read so Slack does not list them, and the same date key keeps a retried cron from posting twice. - Install: `npx shadcn@latest add @evex/invoice-chase-drafter` - Category: productivity - Author: TommyBez - Updated: 2026-09-09 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/invoice-chase-drafter - Full source (markdown): https://www.evex.sh/agents/invoice-chase-drafter.md ## CRM Hygiene Agent Scheduled CRM hygiene via Connect that proposes dedupe, normalize, and enrich batches for human approval before any write. CRM Hygiene Agent is an eve agent that connects to one HubSpot, Salesforce, or Pipedrive account you already own. On each cron tick it reads contacts through Vercel Connect, drafts a dedupe, normalize, and enrich batch, and waits for you to approve before any CRM write. You interact with it through environment variables and Slack or email. Set a Connect UID for the CRM you use, pick Slack Connect, Resend, or both, and trigger crm-hygiene-scan. The agent previews every digest and only delivers when confirmSend is true. CRM writes stay behind apply_hygiene_writes. It is useful when you want scheduled cleanup without silent merges. Duplicate emails become a reviewable dedupe row. Name and phone formatting become normalize rows. Empty company or phone fields become enrich rows that copy from a sibling on the same domain. The append-only audit log records proposed, delivered, approved, written, and refused. - Install: `npx shadcn@latest add @evex/crm-hygiene-agent` - Category: productivity - Author: TommyBez - Updated: 2026-09-09 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, resend@^6.14.0, zod@4.3.6 - Web page: https://www.evex.sh/agents/crm-hygiene-agent - Full source (markdown): https://www.evex.sh/agents/crm-hygiene-agent.md ## Email Triage Assistant Inbox triage that classifies threads and writes draft replies without sending. Email Triage Assistant is an eve agent that connects to one mailbox you already own. On each cron tick or signed inbox push it lists threads, reads the ones that need a human, and writes replies into the provider Drafts folder. You review those drafts in Gmail, Outlook, or IMAP and hit send yourself. You interact with it through the inbox-triage schedule, the /inbox/push channel, or an on-demand Eve chat that still reads the mailbox. Set EMAIL_TRIAGE_GOOGLE_CONNECT_UID, EMAIL_TRIAGE_MICROSOFT_CONNECT_UID, or IMAP, plus optional Slack Connect. The agent applies TRIAGE_BUCKETS labels and matches Sent-folder tone before it calls create_draft_reply. It is useful when you want autonomous sorting without an auto-send. Code refuses SMTP ports and send URLs. create_draft_reply always returns sent false. Newsletter and FYI threads get a bucket and no draft unless a real question is waiting in the thread. - Install: `npx shadcn@latest add @evex/email-triage-assistant` - Category: support - Author: TommyBez - Updated: 2026-09-08 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/email-triage-assistant - Full source (markdown): https://www.evex.sh/agents/email-triage-assistant.md ## Competitor Intel Monitor Scheduled competitor URL monitor that diffs pages and delivers scored Slack or email digests. Competitor Intel Monitor is a scheduled eve agent that re-reads a list of competitor pages you already chose. On each cron tick it checks robots.txt, pulls the HTML that is allowed, and compares normalized text to the last snapshot in a JSON file or Upstash Redis. You configure the list and thresholds once, then leave it running. You interact with it through environment variables and your inbox or Slack. Set COMPETITOR_INTEL_URLS or a JSON or text file, pick Slack, Resend, or both, and trigger watch-competitor-pages. The agent previews every digest and only sends when confirmSend is true and a date-derived idempotency key is present. It is useful when you want a quiet baseline plus alerts that ignore tiny edits. First-seen URLs are stored without a ping. Later diffs report a score from changed character weight, and only rows that clear both gates go out. Robots disallows and missing config stop that path instead of inventing a page. - Install: `npx shadcn@latest add @evex/competitor-intel-monitor` - Category: research - Author: TommyBez - Updated: 2026-09-08 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, resend@^6.14.0, zod@4.3.6 - Web page: https://www.evex.sh/agents/competitor-intel-monitor - Full source (markdown): https://www.evex.sh/agents/competitor-intel-monitor.md ## Meeting Action Extractor Extracts owners and deadlines from a meeting transcript and drafts Linear follow-ups for approval. Ask for follow-ups from a standup or planning notes already checked out. Meeting Action Extractor searches the local transcript tree, reads the matching files, and returns Linear issue drafts with owners and dates. Nothing is filed in Linear. You review the drafts, then create the issues yourself. You interact with it through Eve chat sessions. Linear is a read-only lookup for team and people names while it drafts. Paste a request that names a transcript or a meeting date, get structured drafts, then approve them. The agent never creates the issues. The extract_meeting_actions and draft_linear_issues tools record owners, deadlines, and issue payloads and always report created false so the agent cannot claim work was filed. create_linear_issues always pauses for a person. Even after you approve, that tool still does not create issues in Linear. - Install: `npx shadcn@latest add @evex/meeting-action-extractor` - Category: productivity - Author: TommyBez - Updated: 2026-09-07 - Dependencies: @vercel/connect@^0.2.6, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/meeting-action-extractor - Full source (markdown): https://www.evex.sh/agents/meeting-action-extractor.md ## Knowledge Base Gardener Finds stale product docs and drafts updates with file cites. Paste the stale page or changelog you want reconciled. Knowledge Base Gardener searches the local product-docs tree, reads the matching files, and writes a draft with file-path citations. Nothing is committed or overwritten. Copy the draft from the session, then you review and apply it. You interact with it through Eve chat sessions only. There is no GitHub channel and no publish connection. Paste a gardening request or a suspected stale page, get a draft, then copy the update into your docs yourself. The agent never applies the edit. The draft_doc_update tool records the proposed text and citations and always reports published false so the agent never claims the docs were shipped. When a cited page looks current, it says so instead of inventing churn from training data. - Install: `npx shadcn@latest add @evex/knowledge-base-gardener` - Category: support - Author: TommyBez - Updated: 2026-09-07 - Dependencies: eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/knowledge-base-gardener - Full source (markdown): https://www.evex.sh/agents/knowledge-base-gardener.md ## Support Reply Draft Drafts a customer reply from product docs and cites the file. Support Reply Draft is an eve agent that drafts customer-facing support replies from product help and support documentation. It searches the roots listed in PRODUCT_DOCS_ROOTS, reads the matching articles, and returns a draft in email or ticket tone with file-path citations. You interact with it through Eve chat sessions only. There is no GitHub channel and no email-send connection. Paste a customer question, get a draft, then copy it into your own mail or ticket tool. When the product docs do not cover the question, it says so instead of inventing refunds, SLAs, or setup steps. The draft_support_reply tool records the reply text and citations and always reports sent false so the agent never claims delivery. - Install: `npx shadcn@latest add @evex/support-reply-draft` - Category: support - Author: TommyBez - Updated: 2026-09-01 - Dependencies: eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/support-reply-draft - Full source (markdown): https://www.evex.sh/agents/support-reply-draft.md ## GitHub CI Explainer Explains failed GitHub Actions checks from the log. GitHub CI Explainer is an eve agent that watches failed GitHub Actions checks through a native GitHub App channel. When a check_run completes with conclusion failure, GitHub delivers the webhook to your deployed eve app at /eve/v1/github, and the agent comments what failed plus the first useful file and line from annotations or the job log. It sits next to GitHub Issue Maintainer and Code Reviewer in the same GitHub App world, but its job stops at explaining the failed check. It posts a regular pull request timeline comment when a PR is associated, or a commit comment when there is no PR, and it never changes the branch. Built-in Upstash-backed rate limiting and per-check idempotency keep public deployments from comment storms when GitHub retries webhooks or several jobs fail in one suite. - Install: `npx shadcn@latest add @evex/github-ci-explainer` - Category: coding - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @upstash/ratelimit@^2.0.8, @upstash/redis@^1.38.0, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/github-ci-explainer - Full source (markdown): https://www.evex.sh/agents/github-ci-explainer.md ## Docs Knowledge Assistant Answers from your repo docs and cites the file. Docs Knowledge Assistant is an eve agent that answers questions from the installing repository's documentation files. It searches README, docs/, CONTRIBUTING*, and AGENTS.md, then replies with file-path citations so readers can verify the source. You interact with it through Eve chat sessions or by mentioning it on a GitHub issue comment. It ignores pull request conversations, never publishes GitHub PR reviews, and never applies taxonomy labels or triage other issues. When the documentation clearly lacks an answer, it says so. On GitHub issue-comment turns it can optionally open a documentation-gap issue with open_docs_issue so maintainers can track missing docs without turning the agent into a second issue bot. - Install: `npx shadcn@latest add @evex/docs-knowledge-assistant` - Category: support - Author: TommyBez - Updated: 2026-09-01 - Dependencies: eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/docs-knowledge-assistant - Full source (markdown): https://www.evex.sh/agents/docs-knowledge-assistant.md ## GitHub Issue Maintainer Labels GitHub issues, asks for missing repro, and emails a weekly digest. GitHub Issue Maintainer is an eve agent that triages newly opened GitHub issues through a native GitHub App channel. When an issue opens, GitHub delivers the webhook to your deployed eve app at /eve/v1/github, and the agent applies a small label taxonomy, then asks for missing reproduction details when the report is thin. It is adjacent to Code Reviewer in the same GitHub App and issue-comment world, but it never reviews pull requests and never publishes GitHub PR reviews. Its job stops at issue hygiene: labeling, clarifying incomplete reports, and a weekly open-issue digest email through Resend. Built-in Upstash-backed rate limiting keeps public deployments safe, with stricter defaults for public repositories than private ones. The weekly digest is a schedule, not a review workflow: it lists open issues and emails maintainers a concise HTML summary. - Install: `npx shadcn@latest add @evex/github-issue-maintainer` - Category: coding - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @upstash/ratelimit@^2.0.8, @upstash/redis@^1.38.0, ai@^7.0.38, eve@^0.47.5, resend@^6.14.0, zod@4.3.6 - Web page: https://www.evex.sh/agents/github-issue-maintainer - Full source (markdown): https://www.evex.sh/agents/github-issue-maintainer.md ## Programmatic SEO Agent Weekly scheduled agent that grows a product's organic traffic with programmatic SEO: it checks the product's GitHub repository out into its sandbox, discovers and validates keyword opportunities with DataForSEO, researches each target with the Parallel web search API, generates batches of SEO-optimized pages matching the repo's content conventions, and pushes them as a pull request for human review. Programmatic SEO Agent is a scheduled eve agent that grows organic traffic by shipping weekly batches of SEO-optimized pages to your product's GitHub repository. Each run clones the repo defined by PSEO_GITHUB_REPO into a Vercel sandbox, studies your product and existing content conventions, and writes new pages that match the format already in the repo, from frontmatter fields to internal-link style. You interact with it through a cron schedule (PSEO_WEEKLY_CRON, Mondays at 07:00 UTC by default) rather than a chat channel, and everything it produces arrives as a pull request on an idempotent pseo/-w branch. It never merges anything, never touches files outside the configured target directory, and re-running the same week updates the existing PR instead of opening a duplicate. What makes it useful is that every page is backed by data: keyword opportunities come from the DataForSEO Labs and Google Ads endpoints, factual claims are grounded in Parallel web search excerpts with provenance, and a bundled programmatic-seo skill enforces a quality bar that drops thin doorway pages. A week with no keywords above the volume threshold is deliberately skipped, not padded. - Install: `npx shadcn@latest add @evex/programmatic-seo-agent` - Category: marketing - Author: TommyBez - Updated: 2026-09-01 - Dependencies: ai@^7.0.38, eve@^0.47.5, parallel-web@^1.1.0, zod@4.3.6 - Web page: https://www.evex.sh/agents/programmatic-seo-agent - Full source (markdown): https://www.evex.sh/agents/programmatic-seo-agent.md ## Brand Visual Asset Generator Generate brand-aligned SVG asset packs for SaaS products using Context.dev brand extraction and a Quiver Arrow SVG tool. Brand Visual Asset Generator is an on-demand eve agent that turns a company domain, product description, or explicit brand profile into a coherent pack of editable SVG assets: icons, empty states, hero illustrations, badges, feature graphics, onboarding visuals, changelog art, and dashboard or modal graphics. You talk to it in your eve chat client, name the assets you want, and it returns real SVG markup ready to drop into a product or landing page. Under the hood it combines two services. A Context.dev MCP connection resolves the brand facts first: name, description, colors, logos, homepage copy, and styleguide cues for a domain. Then a generate_svg_with_arrow tool calls the quiverai/arrow-1.1 image model through Vercel AI Gateway once per asset brief, validates that the response is safe SVG with a viewBox, rescales it to the requested dimensions, and normalizes icons to currentColor strokes so they theme automatically. What makes it useful is pack coherence and honesty. A bundled brand-visual-assets skill enforces a six-step workflow with a scorecard: every asset must share palette, stroke language, and illustration metaphors, and anything scoring 8 or below gets regenerated with a tighter brief. If Context.dev or AI Gateway credentials fail, the agent stops and reports the error instead of fabricating brand facts or hand-writing replacement SVGs. - Install: `npx shadcn@latest add @evex/brand-visual-asset-generator` - Category: marketing - Author: TommyBez - Updated: 2026-09-01 - Dependencies: ai@^7.0.38, eve@^0.47.5, zod@4.4.3 - Web page: https://www.evex.sh/agents/brand-visual-asset-generator - Full source (markdown): https://www.evex.sh/agents/brand-visual-asset-generator.md ## OpenUI Assistant An Eve agent that streams OpenUI Lang generative UI using the official openuiChatLibrary, with demo weather, stock, and search tools from the openui-chat example. OpenUI Assistant is an eve agent that answers every chat turn with OpenUI Lang, a structured generative UI language, so your chat streams rendered cards, tables, and follow-up buttons instead of markdown prose. It builds its system prompt at build time by calling openuiChatLibrary.prompt(openuiChatPromptOptions) from @openuidev/react-ui, the same library and prompt options the official openui-chat example app uses, so its output stays compatible with the upstream renderer. You interact with it through a normal chat session: run eve dev for the terminal UI, or mount the bundled OpenUIEveChat reference component in a Next.js app that uses withEve(), where useEveAgent() streams the reply into the Renderer from @openuidev/react-lang. Every reply is a program whose first statement assigns root, built from chat primitives like Card, CardHeader, TextContent, Table, and FollowUpItem. Three deterministic demo tools ship with the agent: get_weather, get_stock_price, and search_web. They mirror the sample tools from the openui-chat example and return mock JSON, which makes the agent a self-contained sandbox for evaluating generative UI without wiring real data providers or API keys. - Install: `npx shadcn@latest add @evex/openui-assistant` - Category: general - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @openuidev/react-lang@^0.2.8, @openuidev/react-ui@^0.12.1, ai@^7.0.38, eve@^0.47.5, just-bash@^3.1.0, zod@^4.4.3 - Web page: https://www.evex.sh/agents/openui-assistant - Full source (markdown): https://www.evex.sh/agents/openui-assistant.md ## Eve Agent Builder An Eve coding agent that creates Eve agents, runs their checks, deploys them to Vercel, and verifies the live routes. Eve Agent Builder turns a plain request like 'create an agent that answers onboarding questions' into a tested, deployed Eve agent, so you review approvals and results instead of running the delivery checklist yourself. Install it into an existing Eve app and talk to it through whatever channel that app already exposes: web chat, the Eve session API, Slack, or GitHub. Every claim it makes is backed by a recorded result. The agent tests generated code in a real Vercel Sandbox with Node 24, and a hook captures the exit code of each eve info, build, and eval run. When it asks you to approve a deploy, the request quotes that recorded evidence, so you decide with facts rather than the model's recollection. Deployment stays under your control. The bash tool denies Vercel CLI commands outright and routes them through run_vercel_cli, which pauses for human approval on every Connect setup, project link, and deploy, and refuses to deploy a workspace that is not already linked to a Vercel project. After deploying, it verifies the live health, session, and stream routes. - Install: `npx shadcn@latest add @evex/eve-agent-builder` - Category: coding - Author: TommyBez - Updated: 2026-09-01 - Dependencies: ai@^7.0.38, eve@^0.47.5, zod@^4.4.3 - Web page: https://www.evex.sh/agents/eve-agent-builder - Full source (markdown): https://www.evex.sh/agents/eve-agent-builder.md ## Branded SEO Page Builder Generate an on-brand, SEO-optimized HTML page from a domain using Context.dev brand, content, and styleguide data. Branded SEO Page Builder is an eve agent that turns a bare domain into one complete, SEO-optimized HTML page. You interact with it in chat: ask for a page from a domain such as linear.app, or point it at a specific source URL and a target topic, and it returns a full static document with metadata, Open Graph and Twitter card tags, semantic sections, and JSON-LD structured data. What makes it useful is grounding. The agent connects to Context.dev's hosted MCP server at context-dev.stlmcp.com to resolve real brand data for the domain: company name, description, colors, logos, industry labels, homepage content as markdown, and optional styleguide signals like typography and spacing. Every user-facing claim in the generated page comes from that data or your explicit request, never invented statistics, testimonials, or pricing. Two vendored skills shape the output. The seo-audit skill enforces on-page fundamentals such as one h1, canonical tags, descriptive alt text, and intent-matched schema types, while the ai-seo skill structures copy into extractable answer blocks and FAQ sections so answer engines like ChatGPT, Perplexity, and Google AI Overviews can cite the page, not only rank it. - Install: `npx shadcn@latest add @evex/branded-seo-page-builder` - Category: marketing - Author: TommyBez - Updated: 2026-09-01 - Dependencies: ai@^7.0.38, eve@^0.47.5 - Web page: https://www.evex.sh/agents/branded-seo-page-builder - Full source (markdown): https://www.evex.sh/agents/branded-seo-page-builder.md ## X Draft Assistant A scheduled Eve agent that scans a configured set of X (Twitter) profiles every day, surfaces hot topics from their recent posts, researches each topic with the Parallel web search API, and creates three draft candidates for X in Typefully so a human can review and publish them. X Draft Assistant is a scheduled eve agent that turns what a watched set of X (Twitter) accounts posted in the last 24 hours into three ready-to-review draft posts in Typefully. Every day it scans the handles listed in X_HOT_TOPIC_HANDLES via the X API v2, clusters their recent posts into hot topics, researches each topic with the Parallel web search API, and writes three distinct draft candidates with cited sources. You interact with it through a cron schedule rather than chat: the daily-x-drafts schedule fires at 08:00 UTC by default (configurable with X_HOT_TOPIC_DAILY_CRON), and the output lands as unscheduled drafts in your Typefully social set. The agent never publishes, schedules, replies, or likes anything, so a human always makes the final call on what goes live. The safety model around draft creation is what makes this workable for teams that review before publishing. The agent previews every candidate in dry-run mode first, only creates drafts after an explicit confirmCreate flag, and attaches a per-run idempotency key to each draft so a retried step never produces a duplicate in Typefully. It labels posts with the X made-with-AI disclosure by default. - Install: `npx shadcn@latest add @evex/x-draft-assistant` - Category: general - Author: TommyBez - Updated: 2026-09-01 - Dependencies: ai@^7.0.38, eve@^0.47.5, parallel-web@^1.1.0, zod@4.3.6 - Web page: https://www.evex.sh/agents/x-draft-assistant - Full source (markdown): https://www.evex.sh/agents/x-draft-assistant.md ## X Hot Topic Digest A scheduled Eve agent that scans a configured set of X (Twitter) profiles every day, surfaces hot topics from their recent posts, researches each topic with the Parallel web search API, and delivers an HTML digest by email through Resend. X Hot Topic Digest is a scheduled eve agent that watches a list of X (Twitter) profiles you configure and turns their recent posts into a researched daily briefing. It runs unattended on a cron schedule (X_HOT_TOPIC_DAILY_CRON, default 0 8 * * * UTC), reads only public posts through the X API v2 with an app-only bearer token, and never posts anything back to X. Each run scans up to 20 recent posts per handle inside a configurable lookback window (default 24 hours), clusters them into at most 5 hot topics by recurrence and engagement, and researches every topic with the Parallel web search API to attach ranked sources with titles, URLs, and excerpts. The result is a single accessible HTML email delivered through Resend to your configured recipients. You interact with it through configuration and your inbox: set the handles, schedule, and recipients in environment variables, and the digest arrives by email. The agent gates every send: it previews the email first and only sends with an explicit confirmation flag plus an idempotency key, so a replayed run never delivers the same digest twice. - Install: `npx shadcn@latest add @evex/x-hot-topic-digest` - Category: research - Author: TommyBez - Updated: 2026-09-01 - Dependencies: ai@^7.0.38, eve@^0.47.5, parallel-web@^1.1.0, resend@^6.14.0, zod@4.3.6 - Web page: https://www.evex.sh/agents/x-hot-topic-digest - Full source (markdown): https://www.evex.sh/agents/x-hot-topic-digest.md ## Supabase Data Analyst A Slack-native Eve analyst for a single Supabase project that only runs read-only SQL queries. It exposes just supabase__list_tables and supabase__execute_sql through an MCP client connection to the hosted Supabase MCP server; no write, migration, Edge Function, branch, storage, logs, advisors, account, or docs tools are available. Supabase Data Analyst is an eve agent that lives in Slack and answers questions about a single Supabase project with read-only SQL. Mention it in a channel or send it a DM, and it inspects your schema, writes one focused query, runs it through the hosted Supabase MCP server, and replies with an aggregate answer in plain language instead of raw row dumps. The agent is deliberately narrow: it exposes exactly two tools, supabase__list_tables for schema inspection and supabase__execute_sql for read-only SELECT queries. The MCP connection is pinned to read_only=true and features=database, a client-side allow list hides every other database tool, and the config loader rejects any attempt to set SUPABASE_DATA_ANALYST_READ_ONLY to false or request other feature groups at startup. It is also scoped to one project by design. SUPABASE_DATA_ANALYST_PROJECT_REF is required whenever the MCP URL points at the hosted endpoint, so your account-level Supabase personal access token can never reach other projects in the account. That makes it a safe way to give a team self-serve analytics over a development or preview database. - Install: `npx shadcn@latest add @evex/supabase-data-analyst` - Category: data - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @vercel/connect@^0.2.6, ai@^7.0.38, eve@^0.47.5 - Web page: https://www.evex.sh/agents/supabase-data-analyst - Full source (markdown): https://www.evex.sh/agents/supabase-data-analyst.md ## Postgres Data Analyst An Eve-native Slack analyst for a single Postgres database. It answers Slack mentions and DMs, inspects schema metadata, and runs bounded read-only SQL through authored tools. Postgres Data Analyst is an eve agent that lives in your Slack workspace and answers questions about a single Postgres database. Mention it in a channel or send it a DM, ask something like show total signups by month for the last 6 months, and it inspects the schema, writes one read-only SQL query, runs it, and replies with an interpreted answer rather than a raw row dump. Safety is layered rather than assumed. Every query is parsed into an AST with pgsql-ast-parser and rejected unless it is a single SELECT or WITH statement over allowed schemas; INSERT, UPDATE, DELETE, DDL, SET, and transaction control are all blocked before anything reaches the database. Execution then happens inside a READ ONLY transaction with a statement timeout and a hard row cap, and the docs walk you through creating a dedicated read-only Postgres role as the real enforcement boundary. It works with any Postgres you can reach with a connection string, including Neon branches and Supabase, and connects to Slack through Vercel Connect so you never handle bot tokens or signing secrets yourself. Schema allowlists and a blocked-tables list let you keep sensitive tables out of both query results and schema listings. - Install: `npx shadcn@latest add @evex/postgres-data-analyst` - Category: data - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @vercel/connect@^0.2.6, ai@^7.0.38, eve@^0.47.5, pg@^8.21.0, pgsql-ast-parser@^12.0.1, zod@4.3.6 - Web page: https://www.evex.sh/agents/postgres-data-analyst - Full source (markdown): https://www.evex.sh/agents/postgres-data-analyst.md ## Code Reviewer Eve agent for GitHub PR review. Mention it on a PR for inline comments on bugs, not style. Code Reviewer is an eve agent that reviews GitHub pull requests when someone mentions @code-reviewer in a PR comment or a review thread. It runs behind a native GitHub App channel: GitHub delivers the comment webhook to your deployed eve app at /eve/v1/github, and the agent replies by publishing a real GitHub review with inline comments anchored to the diff. The agent reviews changed behavior, not style. Its instructions direct it at concrete bugs, regressions, security risks, rollout risk, and materially missing tests, and explicitly forbid naming nits and speculative rewrites. It labels each finding blocking, warning, or nit, caps each review at 10 inline comments, and attaches GitHub suggestion blocks for small local fixes the author applies manually. It is read-only toward your repository: the channel checks the code out into the eve sandbox for inspection, but the agent never pushes commits, opens branches, or edits the pull request. Built-in Upstash-backed rate limiting keeps public deployments safe, with stricter defaults for public repositories than private ones. - Install: `npx shadcn@latest add @evex/code-reviewer` - Category: coding - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @upstash/ratelimit@^2.0.8, @upstash/redis@^1.38.0, ai@^7.0.38, eve@^0.47.5, zod@4.3.6 - Web page: https://www.evex.sh/agents/code-reviewer - Full source (markdown): https://www.evex.sh/agents/code-reviewer.md ## Linear Operations Agent An Eve agent for Linear operations across Linear, Slack, and scheduled runs. Linear Operations Agent is an eve agent that keeps Linear as the operational source of truth while meeting your team where work actually starts. You mention or delegate to it inside Linear Agent Sessions, mention or DM it in Slack threads, or let six built-in schedules run digests for triage, cycle health, backlog hygiene, project summaries, P0/P1 monitoring, and weekly initiative updates. All Linear reads and writes go through a single Linear MCP connection to https://mcp.linear.app/mcp with an explicit tool allow-list: eleven read tools such as list_issues, get_issue, and list_cycles, and six write tools such as save_issue, save_comment, and save_status_update. A dynamic approval policy gates every sensitive write, so issue creation, priority changes, reassignments, and bulk actions always require human sign-off first. It ships ten skills covering triage, duplicate detection, clarification, decomposition, incident support, Slack intake, and project, initiative, cycle, and backlog reporting. Two included evals verify the safety contract: triage produces evidence-backed proposals without calling save_issue, and initiatives outside LINEAR_OPS_COVERED_INITIATIVES never receive automated status updates. - Install: `npx shadcn@latest add @evex/linear-operations-agent` - Category: productivity - Author: TommyBez - Updated: 2026-09-01 - Dependencies: @vercel/connect@^0.2.6, ai@^7.0.38, eve@^0.47.5 - Web page: https://www.evex.sh/agents/linear-operations-agent - Full source (markdown): https://www.evex.sh/agents/linear-operations-agent.md --- # Guides # MCP server for AI agents: what it gives you and what it does not A practical guide to MCP servers for agent builders: tools, resources, prompts, permissions, and where MCP stops. An [MCP server](https://modelcontextprotocol.io/introduction) gives agents a standard way to discover and call external capabilities. It does not decide policy for you. The server exposes tools and context; the agent still needs clear instructions, permissions, logging, and workflow boundaries. Treat MCP as the integration layer, not the whole agent architecture. ## MCP solves integration sprawl Without MCP, every agent client needs custom glue for every system it touches. One client calls GitHub, another queries a database, and another searches docs. The result is repeated integration work and inconsistent permissions. An MCP server gives those capabilities a standard shape. The host or client discovers [tools, resources, and prompts](https://modelcontextprotocol.io/docs/concepts/architecture) through MCP, then presents the usable actions or context to the model in the format that runtime expects. That matters once more than one agent needs the same system. A database analyst, a support triage agent, and a product ops agent may all need read-only access to a data warehouse. If each agent builds its own database wrapper, the team now has three permission models and three places for query safety bugs. A shared MCP server gives the team one place to define permissions, logging, and query safety. ## What an MCP server actually exposes The useful split matches the protocol primitives. Tools perform actions, such as listing issues or running a read-only query. Resources provide context, such as files, schemas, or documentation. Prompts provide reusable interaction templates. That does not make every MCP server safe. A broad tool with vague arguments is still broad. A server that exposes write actions still needs consent, authorization, and observability. The best MCP servers are boring in the right way. They expose small capabilities with clear names, typed inputs, and predictable outputs. The model should know what a tool does before it calls it, and a human reviewer should understand the blast radius without reading a page of hidden implementation. - Tools: executable operations the model can request. - Resources: contextual data the client can attach or retrieve. - Prompts: reusable interaction patterns exposed by the server. ## Keep access separate from agent behavior In an Eve project, MCP access usually belongs near [connections](https://eve.dev/docs/connections) or narrow tools, while agent behavior stays in instructions, skills, and application code. That keeps external capability separate from the policy that decides when to use it. This matters for installable agents. A registry item should make it obvious which external systems the agent can reach and which files implement that access. For example, an Eve agent can connect to a hosted MCP server for Supabase or Linear, but still keep its local judgment in files users can inspect: instructions for when to ask for clarification, skills for safe analysis, and tools that wrap only the actions the workflow needs. The external capability is shared. The agent behavior remains owned by the project. ## The risk is assuming protocol equals policy MCP standardizes how capabilities are exposed. The protocol does not dictate how applications use LLMs or manage context. It does not decide whether the agent should call a tool, whether a user is authorized, whether a result can be trusted, or whether a write needs approval. Use MCP for access. Put rules in tools, permissions, approval gates, and runtime checks. A useful rule: if a bad tool call would surprise a user, the protection should not live only in the prompt. Use scopes, read-only credentials, allowlists, approval gates, rate limits, and logs. The model can choose from available capabilities, but the system should decide what capabilities are available. ## How to evaluate an MCP server before using it Start with the tool list. Look for tool names that describe one action, not an entire product surface. Then check inputs. A tool with one unstructured string may be convenient, but it gives the model too much room to improvise. Finally, inspect failure behavior. The server should return clear errors that the agent can use to recover. For production agents, also ask who owns the server. A public MCP server may be useful for quick exploration, while a company-owned server may be required for audited data access. The more sensitive the system, the more the MCP server should look like infrastructure, not a demo. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | MCP server | Many agents or clients need the same external capabilities through a shared protocol. | The capability is private to one agent and simpler as a local tool. | | Native tool | The action is specific to one workflow and needs local policy close to the agent. | Multiple clients need the same integration and discovery behavior. | | Skill | The agent needs a procedure for using a capability well. | The agent needs live access to an external system. | ## Examples ### Eve example An Eve data analyst can use a database MCP server for schema and query tools, plus a local skill that defines metric rules and safe query behavior. ### Outside Eve A desktop assistant can connect to the same MCP server, but it still needs client-side permission prompts and a clear display of what the tool will do. ## FAQ ### Is MCP only for tools? MCP can expose tools, resources, and prompts. Tools are the most visible part because they let agents act. ### Does MCP make tool use safe? MCP gives tools a standard interface. Safety still depends on scopes, validation, approvals, and logging. ### When should I build an MCP server? Build one when the same integration should be reused across agents, clients, or teams. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/mcp-server-for-ai-agents - This document: https://www.evex.sh/learn/mcp-server-for-ai-agents.md - All guides: https://www.evex.sh/learn --- # Agentic workflows: when software should decide the next step How to decide when a workflow should be agentic, deterministic, or a hybrid of both. An agentic workflow is useful when the next step depends on judgment. If the path is fixed, ordinary workflow code is clearer. The best production systems usually mix both: deterministic rails around model decisions, with tools and approvals controlling the moments where the agent can affect the outside world. ## Do not make everything agentic A workflow becomes agentic when the model observes state, chooses an action, sees the result, and decides what to do next. That flexibility helps triage, research, code review, support, and messy operational work. It is wasteful when the process is already known. If step two always follows step one, a model does not need to decide it. Deterministic software will be cheaper, faster, and easier to test. The easiest mistake is asking the model to enforce rules the application already knows. It should not decide whether an invoice over a fixed threshold needs approval if that threshold is a policy. It should not decide whether a user has access if the application already has permissions. Let the agent handle interpretation and prioritization. Let code handle invariants. ## Use agents for ambiguity Good agentic work has ambiguity at the center. Which issue matters? Which query answers the question? Which source is credible? Which tool should run next? These are judgment calls where a model can add value. Bad agentic work asks the model to enforce fixed policy. Business rules, permissions, idempotency, and irreversible writes should live in code. This split is not just about reliability. It also makes the user experience better. A user should feel that the agent is making thoughtful choices where humans normally spend time, not that it is randomly deciding things software should know already. ## Hybrid workflows are the default The practical pattern is a hybrid: a deterministic trigger starts the run, the model makes a bounded decision, tools execute narrow actions, and the workflow records state. Human approval appears only where risk justifies it. Eve fits this pattern because [channels, schedules, tools, skills, and durable sessions](https://eve.dev/docs/getting-started) can sit around model judgment instead of replacing application structure. A scheduled digest is a good example. A cron-like schedule can start the run. The model can decide which changes matter. A Slack tool can post the final summary. Durable state can prevent duplicate delivery. Each layer does one job, and the agent is used where judgment actually matters. ## Design for the second run The first run is usually easy. The second run reveals whether the workflow is real. What if the same event arrives twice? What if the user rejects the draft? What if the tool succeeds but the response stream fails? What if the model has no useful action to take? A strong agentic workflow has answers to those questions. It can no-op, ask for clarification, retry safely, or stop with a useful explanation. If every failure path becomes "ask the model again", the workflow is not designed yet. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Deterministic workflow | The steps and branches are known before the run starts. | The workflow depends on interpreting messy context or choosing among uncertain actions. | | Agentic workflow | The model must choose the next action based on observations. | The model is being asked to enforce rules that code can enforce exactly. | | Hybrid workflow | You need model judgment inside clear runtime boundaries. | The boundaries are so vague that no one can explain who controls the next step. | ## Examples ### Good fit A Linear triage agent reads new issues, decides which ones need clarification, and drafts updates while code enforces allowed project fields. ### Poor fit A billing workflow asks a model whether a fixed refund threshold applies. That should be a rule, not a judgment call. ## FAQ ### Are agentic workflows the same as automations? Automations follow predefined steps. Agentic workflows let the model choose some steps based on context. ### Where do tools fit? Tools are the bounded actions an agentic workflow can request. They should stay narrow and observable. ### What is the first thing to test? Test the failure path: bad input, missing context, duplicate trigger, and rejected approval. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/agentic-workflows - This document: https://www.evex.sh/learn/agentic-workflows.md - All guides: https://www.evex.sh/learn --- # AI agent frameworks: the practical checklist before you choose A practical checklist for comparing LangGraph, CrewAI, AutoGen-style systems, Eve, and other agent frameworks. Choose an AI agent framework by the work it must survive: tool calls, retries, approvals, state, deployment, observability, and team ownership. A demo tells you whether the framework can run. A failure-path test tells you whether your team can operate it. ## Start with the job the agent must survive Most agent frameworks can run a tool call in a tutorial. That is not enough. The real question is what happens when the run is messy: a webhook arrives twice, a tool partially succeeds, a human rejects an output, or a deployment happens while the agent is waiting. Before you compare frameworks, write down the agent’s operational requirements. Does it need durable state? Does it write to external systems? Does a human approve anything? Does it run on a schedule? Does it need to be installed as source in customer projects? Those answers matter more than a generic “best framework” ranking. This makes the comparison less abstract. LangGraph, CrewAI, AutoGen-style systems, Eve, Mastra, and vendor SDKs are not interchangeable wrappers around the same thing. They make different tradeoffs around control flow, collaboration, deployment, and ownership. ## The seven checks that actually matter A serious evaluation should cover seven areas. First, state: can the framework resume a run without repeating completed side effects? Second, tools: can you define narrow actions with typed inputs and clear errors? Third, approvals: can a human approve the exact artifact that will be executed? Fourth, deployment: does the framework fit your runtime, queue, serverless, or long-running worker model? Fifth, observability: can you inspect prompts, tool calls, retries, approvals, token spend, and final delivery? Sixth, evals: can you run behavior checks in CI? Seventh, ownership: can your team inspect and change the agent’s instructions and tools without fighting the framework? If a framework is weak in one of these areas, that does not automatically disqualify it. It tells you where you will need extra infrastructure or stricter conventions. - State and recovery - Tool boundaries and permissions - Human approval and artifact review - Deployment and runtime fit - Observability and cost tracking - Behavior evals in CI - Source ownership and local customization ## Where the popular options tend to fit [LangGraph](https://docs.langchain.com/oss/python/langgraph/) is strongest when explicit workflow state is the center of the problem. If you need branches, loops, retries, and human interruptions that are easy to reason about, graph structure helps. The tradeoff is that simple workflows can feel heavy when forced into graph terms. [CrewAI](https://docs.crewai.com/en/introduction) is strongest when the work naturally maps to roles: researcher, analyst, writer, reviewer. It can be fast for prototypes and internal workflows where role collaboration is the clearest way to describe the task. CrewAI also has flow-style orchestration, but if exact state recovery and side-effect boundaries are the main concern, compare those flow primitives directly against graph-first options. [AutoGen](https://microsoft.github.io/autogen/stable//index.html)-style systems are strongest when the work is conversational collaboration between agents, especially code or research loops where one agent proposes and another critiques. The risk is that long conversations can hide control flow unless you add strong stop conditions and tracing. [Eve](https://eve.dev/docs/getting-started) is strongest when the agent should be a TypeScript backend project with inspectable files: instructions, tools, skills, channels, schedules, and env requirements. That makes it a better fit for source-owned agents distributed through a registry than for every possible orchestration problem. ## Use the failure-path prototype Do not choose from a hello-world example. Build the smallest version of the real workflow that includes one trigger, one model decision, one tool call, one rejected or failed path, and one log you would show a teammate. For a code review agent, that might mean opening a pull request, detecting one real issue, rejecting a noisy finding, and posting a review only after validation. For a data agent, it might mean reading schema, refusing a write query, running a safe read query, and explaining the SQL. For an operations agent, it might mean receiving a Slack message, creating a draft Linear update, and asking for approval before posting. Then compare the result. Which framework made the code easier to read? Which made the run easier to inspect? Which made the unsafe action harder to perform by accident? ## When distribution is part of the decision If you are building reusable Eve agents, the framework choice also becomes a distribution question. Can another developer inspect the files before they install them? Can they see which tools write to external systems? Can they change the instructions and keep the result in their own repository? That is where evex is relevant. It does not make Eve the best framework for every workflow. It makes Eve’s source-owned file model easier to discover, preview, and install when that model is the right fit. Browse [/agents](/agents). ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Graph-first framework | The workflow needs explicit branching, loops, checkpointed state, and recoverable interruptions. | The agent is mostly a small source-owned workflow where graph structure adds noise. | | Role-first framework | The task maps cleanly to specialist roles and quick multi-agent collaboration. | The process needs strict state recovery, narrow side effects, and auditability. | | Filesystem-first framework | The team needs installable source files, inspectable tools, and project-level ownership. | The execution graph is the main artifact the team must control. | ## Examples ### Framework evaluation slice Build a PR-review agent that reads a diff, rejects one false positive, posts one validated comment, and records the run. The best framework is the one that makes that failure path easiest to understand. ### Eve-shaped workflow An installable Slack data analyst benefits from visible files: channel, tools, instructions, env example, and query policy. That source-owned shape matters as much as orchestration. ## FAQ ### What is the best AI agent framework? Start with state, tools, approvals, deployment, observability, evals, and source ownership. There is no universal best. ### Should I choose based on programming language? Language matters because your team has to maintain the agent, but it should not override runtime fit, recovery, and tool safety. ### How do I compare frameworks quickly? Build one failure-path prototype in each candidate framework. Include a tool error, a duplicate event, and one user-visible output. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/ai-agent-frameworks - This document: https://www.evex.sh/learn/ai-agent-frameworks.md - All guides: https://www.evex.sh/learn --- # AI agent tools: the safe way to give models actions How to design agent tools with narrow authority, typed inputs, clear descriptions, and observable results. A tool lets the model affect a real system, so every tool needs a narrow job, typed inputs, logs, and clearly declared side effects. Bad tools turn the agent into an unreviewable API gateway where the model has too many ways to surprise you. ## A tool is not just a helper function In agent systems, tools are where model output becomes system behavior. A model can ask to call a tool, pass arguments, read the result, and decide what to do next. That makes tool design a security and product decision. The tool name, description, schema, permissions, and output shape all influence how the agent behaves. A human user may never see the tool definition, but they feel its quality. A good tool lets the agent answer confidently and recover from errors. A bad tool creates vague failures: the model sends malformed input, receives a confusing error, and guesses its way forward. ## Narrow tools beat clever tools A broad tool feels flexible, but it moves complexity into the model prompt. A narrow tool gives the model fewer ways to be wrong. Compare `update_ticket_status` with a typed status enum to `run_linear_operation` with a free-form operation string. The narrow version is easier to test, easier to log, and easier to explain to users. Narrow does not mean tiny. A tool can perform several deterministic steps if those steps always belong together. The key question is whether the model should make a decision between steps. If not, hide the sequence behind a tool. If yes, expose smaller steps and let the agent inspect the result. ## Give every tool a reviewable file Eve tools live in `agent/tools/` ([Tools](https://eve.dev/docs/tools)), so every callable action has a file. That layout makes review concrete: what can the model ask the system to do, and where is that behavior implemented? For registry-installed agents, this is especially useful. Users can inspect tool files before giving the agent credentials or connecting a channel. That does not remove the need for careful schemas. A file path tells you where authority lives. The tool implementation still has to validate inputs, handle errors, redact sensitive output, and make side effects explicit. ## What to include in a tool contract A tool contract should answer five questions: what action does it perform, what input does it accept, what output does it return, what can go wrong, and what side effects can happen. If any of those are unclear, the model and the reviewer are both guessing. Descriptions should be written for the model, but they should also be readable by humans. Avoid vague verbs like "handle" or "process". Name the action: list, describe, create, update, send, preview, approve. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Read tool | The model needs data from a system, such as schema, issue state, or file content. | The data can be attached as static context or a resource without model-controlled execution. | | Write tool | The agent needs to create, update, send, or trigger something outside itself. | The action is risky and lacks approval, idempotency, or audit logs. | | Composite tool | A sequence is deterministic and should not be controlled step-by-step by the model. | The sequence contains judgment points the model should inspect between steps. | ## Examples ### Good tool `submit_pr_review` accepts a review body and inline comments, then posts one GitHub review with clear rate limits and logging. ### Risky tool `github_action` accepts any operation and arbitrary JSON. It may demo quickly, but it is difficult to permission or test. ## FAQ ### Should tools be tiny? They should be narrow, not necessarily tiny. A tool can do several deterministic steps if the model should not decide between them. ### Where should validation happen? Validate at the tool boundary with schemas and runtime checks. Do not rely on prompt instructions alone. ### Should a tool return prose or data? Return structured data when the agent will reason over it. Use prose only when the output is meant for a human. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/ai-agent-tools - This document: https://www.evex.sh/learn/ai-agent-tools.md - All guides: https://www.evex.sh/learn --- # MCP vs skills: do you need a connection or a playbook? A grounded distinction between MCP servers, tools, resources, prompts, and skills for teams extending AI agents. [MCP](https://modelcontextprotocol.io/introduction) gives an AI application a standard way to reach external systems. Skills, in Eve and Agent Skills–style runtimes, give an agent a reusable playbook for a task. They often work together, but they are not substitutes. The clean design is usually MCP for access, skills for judgment. ## The common confusion Both MCP and skills show up when people ask how to give an agent more context. That phrase hides two different needs. Sometimes the agent needs access to a system: list tables, read a file, search docs, create an issue. Sometimes the agent needs a method: review a migration, write in a brand voice, or triage an incident. MCP is strongest for the first need. Skills are strongest for the second. The confusion is understandable because both change what the model can do. But they change different things. MCP changes what systems the agent can reach. Skills change how the agent uses that access. Mixing them up leads to strange designs, like hiding API credentials inside a markdown playbook or turning a review rubric into a fake tool. ## MCP is an interface to capabilities An MCP server exposes tools, resources, and prompts through a standard protocol ([architecture](https://modelcontextprotocol.io/docs/concepts/architecture)). The client can discover what is available and call into those capabilities without each agent inventing a custom integration. This is useful when the capability should be shared across many clients or agents. A Postgres MCP server, a Linear MCP server, or a docs search MCP server can serve multiple workflows. MCP is especially useful when the external system is not owned by the agent author. A team can maintain one approved server for a database, CRM, or ticketing system, then let multiple agents use the same capability under the same access rules. ## Skills are playbooks A skill is a playbook ([Eve skills](https://eve.dev/docs/skills)): a model-loadable procedure that improves how the agent works. It tells the agent what to check, what to avoid, what output shape to use, what examples matter. Loading a skill adds instructions; it does not grant a new execution surface. Skills should not hide credentials or grant authority. They can tell the model to use a read-only SQL tool carefully, but the read-only boundary must still live in the tool, database role, MCP server, or runtime policy. A good skill makes the agent more consistent without giving it new powers. It might teach severity levels for code review, rules for customer-facing email, or the right way to answer analytics questions. The skill improves judgment; it does not replace permissions. ## Use both when capability needs a method Many useful workflows need both layers. A data analyst needs database access and metric definitions. A support agent needs ticket access and escalation policy. A code reviewer needs GitHub access and review calibration. In those cases, the design question becomes: what does the agent need to reach, and what does it need to know? MCP answers the first question. Skills answer the second. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | MCP | The agent needs live access to external tools, resources, or server-provided prompts. | The agent only needs local procedure or writing rules. | | Skill | The agent needs repeatable judgment, checklists, examples, or output standards. | The agent needs credentials or live system access. | | Both | A workflow needs external capability plus domain-specific procedure. | The combination adds indirection without improving reuse or safety. | ## Examples ### Eve example A database analyst can use MCP for database access and a skill for metric definitions, SQL safety rules, and answer format. ### Outside Eve A coding assistant can connect to an MCP server while loading project-specific skills from the repository. ## FAQ ### Can a skill call an MCP tool? A skill can tell the agent when and how to use the tool. The runtime still performs the actual tool call. ### Can MCP replace skills? MCP can expose prompts, but skills remain useful for local, portable procedure and examples. ### Which is safer? Safety comes from scopes, validation, approvals, and logs - not from choosing MCP or skills alone. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/mcp-vs-skills - This document: https://www.evex.sh/learn/mcp-vs-skills.md - All guides: https://www.evex.sh/learn --- # Agent registry: discovery without trust is just a list What an AI agent registry must expose before developers can reuse agents safely. An agent registry should help a developer answer whether an agent is safe, maintained, installable, and worth adapting. Discovery is only the first step. Trust comes from seeing what will be installed, who owns it, and what authority it needs. ## The registry problem is trust Agents carry instructions, tools, external access, schedules, and sometimes public-facing channels. A card with a name and a nice description is not enough to install anything safely. A useful registry shows files, tools, schedules, credentials, write access, dependencies, author, update date, and install command. This is different from a normal plugin directory. Agents can reason, call tools, and act across systems. A registry listing has to show those capabilities before installation, or it is just asking developers to trust a black box. ## Registry, catalog, marketplace A catalog helps people browse inventory. A marketplace helps people choose between vendors. A registry should provide structured metadata and installation paths. For developer agents, the registry model is often the right starting point because the user needs to inspect and own the artifact. This distinction matters for product expectations. A marketplace implies reviews, pricing, support, and vendor comparison. A registry implies installable artifacts, metadata, and repeatable delivery. Agent infrastructure usually needs the second before it can credibly become the first. ## What a registry item needs A real registry item has a clear job, source files, target paths, dependencies, setup instructions, author identity, and update metadata. Install counts are useful, but they are secondary to inspectability. The best registry items also explain the first-run path. What credentials does the agent need? Which files should the user review first? Which tools can write to external systems? What should a safe dry run look like? - Files and target paths - Dependencies and environment variables - Author and source review path - Install command and previewable output ## Why source ownership matters Agent behavior often needs local policy. A company may want a stricter review rubric, a different Slack channel, a narrower SQL policy, or a custom approval step. Source-owned installation makes those changes normal instead of forcing a fork of an opaque tool. Installable source files let teams review the agent, change the policy, and commit the result before they run it. Reusable agents should not trap teams inside someone else’s hidden prompt or tool wrapper. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Public registry | Reusable artifacts should be discoverable and installable across projects. | The agents depend on private infrastructure or internal policy. | | Internal registry | A company needs approved agents, private tools, and governance. | The goal is open contribution and public discovery. | | Marketplace | Commerce, licensing, reviews, and support are part of the product. | The core value is source-owned installation. | ## Examples ### evex-style registry An agent page on [/agents](/agents) shows files, dependencies, author, and install command. Agents enter through a reviewed pull request ([Publishing](/docs/publishing)). ### Enterprise registry A company registry may track approved MCP servers, internal agents, policy status, owners, and deployment state. ## FAQ ### What makes an agent registry trustworthy? Transparent files, clear ownership, dependency disclosure, review history, and install previews. ### Should a registry store runtime state? It can store metrics and favorites, but canonical source metadata should stay close to the files being installed. ### Is evex an agent marketplace? evex is a community registry for reusable Eve agent configurations. Commerce, paid tiers, and vendor storefronts are a different product shape. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/agent-registry - This document: https://www.evex.sh/learn/agent-registry.md - All guides: https://www.evex.sh/learn --- # Shadcn registry for agents: installing workflows as source files How the shadcn registry model applies to AI agent workflows, where users need source files rather than opaque packages. The [shadcn registry](https://ui.shadcn.com/docs/registry) model fits agents because many agent workflows are source bundles: instructions, tools, skills, env examples, evals, and integration files that users need to inspect and adapt. For agents, owning the installed files is often the point. ## A reusable agent is not just a dependency Traditional packages work well when the user wants stable behavior behind an import. Agent workflows often need the opposite. The user wants to see the prompt, adjust the tool, change the channel, remove an integration, or add a stricter approval step. A registry item can install editable files directly into the project with the shadcn CLI. The user owns the result and can change it before running the agent. This is the same reason shadcn became popular for UI: teams wanted useful starting points without surrendering ownership. Agent workflows have an even stronger version of that need because prompts and tools encode policy, tone, and authority. ## What the registry must show before install Before install, the registry should show files, target paths, dependencies, author, category, update date, and install command. Otherwise the user cannot answer the basic question: what will this add to my project? This is especially important for agents because installed files can contain authority: tools that write to APIs, channels that receive webhooks, schedules that run unattended, and skills that shape judgment. A previewable registry item reduces anxiety. The user can see whether the agent adds a Slack channel, a GitHub tool, a schedule, an MCP connection, or only local instructions. That makes the install feel like code review, not blind trust. ## Why it pairs well with Eve Eve already organizes agents as files under `agent/` ([Getting started](https://eve.dev/docs/getting-started)). A shadcn registry item can place those files into the expected locations, while the user keeps ownership of the result ([Installation](/docs/installation)). The registry installs the agent files users need to review: instructions, tools, skills, channels, env examples, and evals. For example, an Eve registry item can install `agent/instructions.md`, `agent/tools/`, `agent/skills/`, `agent/channels/`, `.env.example`, and evals together. Each file lands where an Eve developer expects it. ## When not to use a registry item Do not use a registry item for every reusable thing. Stable library code still belongs in a package. Small snippets may belong in docs. A registry item is strongest when several files work together and the user benefits from owning them. The test is simple: if the user will need to inspect and adapt the files, a registry item is a good fit. If the user only needs to call a stable API, a package is probably cleaner. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Shadcn registry item | Users should own, inspect, and modify the installed agent files. | The artifact is a stable library better consumed as a normal package. | | npm package | The behavior is reusable code with a stable API and little need for local editing. | Prompts, tools, env files, and workflow policy need project ownership. | | Docs snippet | The setup is tiny and educational. | The workflow has enough files that copy-paste becomes unreliable. | ## Examples ### Eve example An evex item can install `agent/agent.ts`, `agent/instructions.md`, `agent/tools/run_sql.ts`, a skill folder, README, and `.env.example` into the expected Eve layout. ### Outside Eve The same registry mechanism can distribute project rules, MCP setup, CI workflows, and framework templates. ## FAQ ### Why not publish every agent as an npm package? Users often need to inspect and change prompts, tools, schedules, and channel behavior. A registry item installs those files as source. ### What makes a registry item good? A clear job, explicit target paths, dependency declarations, setup docs, and files that belong together. ### Is customization expected? Yes. The registry gives users a reviewed starting point they can adapt, not a permanent black box. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/shadcn-registry-for-agents - This document: https://www.evex.sh/learn/shadcn-registry-for-agents.md - All guides: https://www.evex.sh/learn --- # LangGraph vs CrewAI: graph control or role-based crews? A builder-focused comparison of LangGraph and CrewAI, with Eve as a file-based reference point. LangGraph and CrewAI start from different mental models. LangGraph makes workflow state and transitions explicit. CrewAI makes role-based collaboration quick to model. The right choice depends on which complexity your team needs to see first, not which framework has the longer feature list. ## The real comparison is not popularity Both frameworks can build useful agents. The difference is how they ask you to think. [LangGraph](https://docs.langchain.com/oss/python/langgraph/) asks you to model a stateful graph. [CrewAI](https://docs.crewai.com/en/introduction) often starts with agents, roles, and tasks, while its Flows cover more structured orchestration. Those mental models lead to different debugging experiences. A graph helps when the failure is in routing. A crew helps when the work naturally decomposes into roles. When the workflow goes wrong, the useful question is which model helps your team find the problem faster: explicit state transitions, or role-shaped collaboration. ## Where LangGraph is stronger LangGraph fits when the workflow needs explicit branching, loops, [checkpointed state](https://docs.langchain.com/oss/python/langgraph/checkpointers), and [human-in-the-loop](https://docs.langchain.com/oss/python/langgraph/interrupts) transitions. It also fits when you want to reason about the path a run took. The tradeoff is overhead. Simple workflows can feel verbose when forced into graph terms. A graph also creates useful pressure: drawing the states makes the workflow inspectable. That helps for regulated, high-stakes, or long-running processes where implicit model behavior is hard to audit. ## Where CrewAI is stronger CrewAI fits fast prototypes and workflows that map to human-like roles: researcher, analyst, writer, reviewer. CrewAI also has Flow-style orchestration, but the common crew abstraction is easiest to explain when the work naturally decomposes into roles. The tradeoff appears when control flow gets complex. Role metaphors can hide state transitions that should be explicit. CrewAI can be the right choice when the team needs to test a multi-agent collaboration pattern quickly. The role-based crew abstraction becomes weaker when the workflow needs durable recovery, careful retries, or exact visibility into how state changes over time; those cases often need flow or graph structure. ## Where Eve differs Eve is [filesystem-first](https://eve.dev/docs/getting-started). That makes it relevant when the agent is a backend project whose tools, skills, channels, schedules, and env requirements should be visible as files. This gives teams a third option in the comparison. If the main problem is control flow, reach for graph thinking. If the main problem is role collaboration, crew thinking may fit. If the main problem is inspectable, source-owned agent capability, Eve’s file model becomes more interesting. ## How Eve agents get into a project Eve agents are files in an Eve app, not a hosted runtime. evex is the open registry for those agents. Open the [/agents](/agents) catalog, inspect the files, then install with `npx shadcn@latest add @evex/` ([Installation](/docs/installation)). If you want a first install to compare against a graph or a crew, start with the PR review agent: `npx shadcn@latest add @evex/code-reviewer`. ## How to decide without guessing Build the same uncomfortable slice in both frameworks. Include one external tool, one bad input, one human decision, and one recovery path. Then read the implementation with a teammate who did not write it. If they can explain what happens next, what can fail, and where to make a change, the framework is serving the team. If they need a tour of hidden conventions, the framework may be working against the workflow. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | LangGraph | State transitions, retries, and explicit routing are the main complexity. | The workflow is simple enough that graph structure adds more weight than clarity. | | CrewAI | The task maps naturally to roles and fast multi-agent collaboration. | The workflow needs precise state control and durable side-effect boundaries. | ## Examples ### LangGraph-shaped workflow A claims workflow with branching escalation paths, retries, and approval states benefits from explicit graph control. ### CrewAI-shaped workflow A research pipeline with researcher, analyst, and writer roles can be faster to express as a crew. ## FAQ ### Is LangGraph more production-ready than CrewAI? It is often stronger for explicit state and control flow. CrewAI can still be useful when the role model fits the work. ### Where does Eve fit in this comparison? Eve is a different axis: file-owned backend agents rather than graph-first or role-first orchestration. ### How should teams choose? Build the hardest failure path in each candidate framework and compare which one is easier to debug. ### How do I try an Eve agent after this comparison? Install from evex with `npx shadcn@latest add @evex/` after you inspect the files on the agent page. The catalog is at /agents. --- - Published: 2026-07-01 - Updated: 2026-09-05 - Web page: https://www.evex.sh/learn/langgraph-vs-crewai - This document: https://www.evex.sh/learn/langgraph-vs-crewai.md - All guides: https://www.evex.sh/learn --- # Eve agent registries: evex vs agentcn Fair, dated comparison of evex and agentcn as Eve agent registries. Both use the shadcn CLI. evex adds inspect-before-install and publish via pull request. Eve agent registries let Eve developers install reusable agents as source files instead of copying folders. evex and agentcn both use the shadcn CLI. evex is the browse, inspect, install, and publish loop: file preview on every agent page, GitHub-verified authors, and publish via pull request. Choose on inspectability and the publish path, not popularity. ## Comparison | Criterion | evex | agentcn | | --- | --- | --- | | Install | `npx shadcn@latest add @evex/` ([Installation](/docs/installation)) | Same shadcn CLI. Live Eve example: `npx shadcn@latest add @agentcn/eve/deep-search` ([Deep Search](https://www.agentcn.run/docs/agents/eve/deep-search)). | | Inspect files before install | Yes. Files, dependencies, author, and command on every agent page. | Recipe docs: Composition file tree, Manual source, optional live preview that needs an API key. Not an inspect-files UI on the catalog listing. | | Author identity | GitHub-verified author profiles | Not surfaced as GitHub-verified author profiles on recipe pages. | | Publish path | Reviewed pull request ([Publishing](/docs/publishing)). | Fork and open a PR ([Contributing](https://github.com/shadcn-labs/agentcn/blob/main/CONTRIBUTING.md)). No first-party publishing docs on agentcn.run (checked 4 Sep 2026). | | Catalog extras | Browse, search, leaderboard, favorites, publishing docs | [Agents](https://www.agentcn.run/docs/agents) list and [Changelog](https://www.agentcn.run/docs/changelog). No leaderboard, favorites, or author pages in the public docs index. | | After install | You own the files ([Installation](/docs/installation)). No runtime dependency on evex. | You own the copied files ([Installation](https://www.agentcn.run/docs/installation)). Same class of write-to-disk outcome. | | Hosted agent runtime | No | No | | Price | Free, MIT | Free. GitHub lists [MIT](https://github.com/shadcn-labs/agentcn). No paid tier on agentcn.run. | If you want inspect-before-install and a PR-owned catalog, use evex. If you already live in agentcn, the install mechanic is the same class of tool. Star count is not a quality signal. ## What an Eve agent registry is An Eve agent registry is a catalog of reusable agents Eve developers can inspect and install as source files. Instead of copying folders from GitHub by hand, you run a shadcn CLI command that writes the agent files into your project. evex is that kind of registry for Eve. Browse the catalog on [/agents](/agents), open an agent page, preview the files, then install with `npx shadcn@latest add @evex/` ([Installation](/docs/installation)). After install you own the files. There is no hosted agent runtime. See [/docs](/docs) for the product overview. ## Same install mechanic, different product evex and agentcn both install through the shadcn CLI. On evex the command is always `npx shadcn@latest add @evex/`. On agentcn, a live Eve example is `npx shadcn@latest add @agentcn/eve/deep-search`. The shared mechanic does not make the products identical. evex is built around browse, inspect, install, and publish for Eve agents. agentcn ships recipes across frameworks and leans on recipe docs plus optional live preview. Choose on inspectability and the publish path, not on which CLI wrapper looks familiar. ## Inspect before you install On every evex agent page you can preview files, dependencies, author identity, and the install command before you run anything ([/agents](/agents)). That inspect-before-install loop is the trust surface: you review what will land under `agent/` first. agentcn recipe docs expose a Composition file tree, Manual source, and an optional live preview that needs an API key. That is useful documentation, but it is not the same as an inspect-files UI on the catalog listing. If file preview on the listing page is the decision gate, evex matches that job more directly. ## How agents get into the catalog evex agents enter the catalog through a reviewed pull request. First-party publishing docs live at [/docs/publishing](/docs/publishing). Canonical agent metadata and files stay in the repository; the database stores runtime state only. agentcn publishing, per its CONTRIBUTING.md, is also fork-and-open-a-PR. There are no first-party publishing docs on agentcn.run. Both paths can accept community work. evex makes the PR-owned path a first-class product surface with docs, author profiles, and CODEOWNERS. ## When to pick which Pick evex when you want inspect-before-install, GitHub-verified author profiles, leaderboard and favorites, and a documented PR publish path for Eve agents. Stay with agentcn when you already live in that catalog or need its mixed-framework recipe set. The install mechanic is the same class of tool. Star count, install totals, and community-size bragging are not quality signals. Copy-paste from GitHub remains fine for a one-off experiment. It falls short when you want a repeatable command, dependency prompts, and a page others can reinstall from. Use [/docs/installation](/docs/installation) when you are ready for the registry path. ## How to install from evex 1. Start from an Eve project root (create one with `npx eve@latest init` if needed). Eve requires Node.js 24 or newer ([Eve getting started](https://eve.dev/docs/getting-started)). 2. Pick an agent on [/agents](/agents) and preview its files, dependencies, and author on the agent page. 3. Run `npx shadcn@latest add @evex/` from the project root ([Installation](/docs/installation)). Example: `npx shadcn@latest add @evex/code-reviewer`. 4. Own the written files: fill `.env.example` when present, read the installed README, and run evals under `evals/` before you trust the agent in production. Use the shadcn `add` command above, not an `eve` CLI `add` subcommand, and not a URL install as the command you publish or paste into docs. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | evex | You want inspect-before-install, GitHub-verified authors, and a PR-owned Eve catalog with first-party publishing docs. | You need a multi-framework recipe catalog outside Eve and already standardize on agentcn. | | agentcn | You already live in agentcn or need its mixed-framework recipes with the same class of shadcn install. | Your decision gate is file preview on every catalog page plus a documented PR publish path for Eve-only agents. | | Copy-paste from GitHub | You are doing a one-off experiment and do not need a repeatable install command. | You want dependency prompts, a stable slug, and a page teammates can reinstall from. | ## Examples ### evex inspect-then-install Open an agent page on [/agents](/agents), preview every file and dependency, confirm the GitHub-verified author, then run `npx shadcn@latest add @evex/` and own the files in your Eve project. ### agentcn mixed-framework Use agentcn when the recipe you need is already there across Eve or other frameworks it documents, accepting recipe-doc composition trees and optional live preview instead of an inspect-files catalog UI. ## FAQ ### What is the difference between evex and agentcn? Both are Eve-capable agent registries that install with the shadcn CLI. evex adds inspect-before-install on every agent page, GitHub-verified author profiles, and first-party publish-via-PR docs. agentcn emphasizes recipe docs, changelog, and mixed-framework recipes. ### How do I install an agent from evex? From your Eve project root, run `npx shadcn@latest add @evex/`. Preview files on the agent page first. Prerequisites and post-install steps are in Installation. ### Is evex an agent marketplace? evex is a community registry for reusable Eve agent source files. There is no commerce layer, paid tier, or hosted runtime. ### How do I publish an agent to evex? Open a reviewed pull request with the agent package. First-party steps are in Publishing. Canonical files stay in the repository. ### Does evex run the agent after install? Install writes source into your project. You own the files and run them in your Eve app. There is no runtime dependency on evex. --- - Published: 2026-08-13 - Updated: 2026-09-04 - Web page: https://www.evex.sh/learn/evex-vs-agentcn - This document: https://www.evex.sh/learn/evex-vs-agentcn.md - All guides: https://www.evex.sh/learn --- # Eve vs Flue: Vercel-first vs deploy-anywhere Compare Eve and Flue on deployment gravity: Vercel-first vs deploy-anywhere. Then see where Evex fits as the registry for reusable Eve agents. Pick Eve when your default path is Vercel. Pick Flue when you need to write once and deploy across Node, Cloudflare, or CI. After you choose Eve (or already have an Eve app), Evex is how you install reusable agents with `npx shadcn@latest add @evex/`. ## The decision is deployment gravity Eve and Flue are both TypeScript agent frameworks. The useful cut is where you expect the agent to run day to day. Eve's first-class deploy path is Vercel: `eve deploy`, with Vercel running the web service, workflows, sandboxes, and schedules. On Vercel, the default sandbox backend is Vercel Sandbox ([Deploy to Vercel](https://eve.dev/docs/guides/deployment/vercel)). Flue markets write-once, deploy-anywhere. Its getting started path covers Node.js, Cloudflare, and GitHub Actions or other CI, with `flue run` for local and CI runs and a Vite plus Hono path when you host the agent ([Flue getting started](https://flueframework.com/docs/guide/getting-started/)). Choose on that gravity first. Feature lists matter less than whether your team's host is already decided. ## Eve in one paragraph Eve builds an agent by walking the filesystem under `agent/`. Start with Node.js 24 or newer and `npx eve@latest init`. The default scaffold routes models through the Vercel AI Gateway. From there the natural production path is the Vercel deploy flow above ([Eve getting started](https://eve.dev/docs/getting-started)). ## Flue in one paragraph Flue is an open agent framework from the creators of Astro, powered by Pi. You write agents with a React-like hooks API, run them with `flue run`, and target Node or Cloudflare in config. The site and docs frame it as a programmable harness you can run locally or deploy across those hosts ([Flue](https://flueframework.com/), [Flue getting started](https://flueframework.com/docs/guide/getting-started/), [withastro/flue](https://github.com/withastro/flue)). ## Where Evex fits Eve is the TypeScript agent framework you author under `agent/`. Evex is the catalog where you browse reusable Eve agents and install them as source into that project. Browse the catalog on [/agents](/agents). From the Eve app root, install with: `npx shadcn@latest add @evex/` The CLI writes under `agent/` (and related files). You own those files. There is no hosted Evex runtime ([Installation](/docs/installation)). For editor-driven browse and install, configure the shadcn MCP server and resolve `@evex/` from chat ([MCP](/docs/mcp)). Product docs live at [/docs](/docs). For scaffold vs catalog vs standalone install paths, see [/learn/install-eve-agent](/learn/install-eve-agent). If you chose Flue for deploy-anywhere, that choice stands. `@evex` installs still require an Eve project: Installation documents agents installing into an eve app, not into a Flue app. Use Eve when you want the Evex catalog path. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Eve | Your default host is Vercel, and you want filesystem agents under `agent/` with `eve init` / `eve deploy`. | You need Node, Cloudflare, or CI as equal first-class targets without a Vercel-first gravity. | | Flue | You want an open harness/framework you can run locally and deploy across Node, Cloudflare, or CI. | Your team is already committed to Eve on Vercel and wants registry installs from Evex. | | Evex install | You already have (or will create) an Eve app and want reusable agent source via `npx shadcn@latest add @evex/`. | You only have a Flue project and expected `@evex` to install there. Evex installs into an eve project. | ## Examples ### Eve on Vercel, then Evex Your default host is Vercel, so you scaffold with `npx eve@latest init`, deploy with the Eve Vercel flow, then install a catalog agent from [/agents](/agents) with `npx shadcn@latest add @evex/`. ### Flue for deploy-anywhere You need Node, Cloudflare, or CI as equal targets, so you pick Flue and follow [Flue getting started](https://flueframework.com/docs/guide/getting-started/). You do not use `@evex/` unless you also keep an Eve app for registry installs. ## FAQ ### What is the difference between Eve and Evex? Eve is the TypeScript agent framework (filesystem under `agent/`, Vercel-first deploy). Evex is the catalog of reusable Eve agents you inspect and install as source with `npx shadcn@latest add @evex/`. ### Can I install Evex agents into a Flue project? No. Evex Installation says agents install into an eve project and write the `agent/` layout Eve loads. If you want `@evex/`, create or open an Eve app first. Flue remains the right framework when deploy-anywhere is the priority. ### When should I pick Flue? Pick Flue when write-once and deploy across Node, Cloudflare, or CI matters more than a Vercel-first path, and you want the hooks-style Flue agent model. ### When should I pick Eve? Pick Eve when Vercel is your default production host and you want filesystem-authored agents with the Eve init and deploy flow. After the Eve app exists, use Evex to install catalog agents. --- - Published: 2026-09-06 - Updated: 2026-09-06 - Web page: https://www.evex.sh/learn/eve-vs-flue - This document: https://www.evex.sh/learn/eve-vs-flue.md - All guides: https://www.evex.sh/learn --- # Install an Eve agent Pick the right install for where the Eve agent came from: scaffold a new app, copy a catalog agent into an existing app, or create a standalone directory. Installing an Eve agent depends on where the agent came from and where the files should land. `eve init` scaffolds a new Eve app when you do not have one yet. Catalog installs from evex or agentcn copy into an existing Eve app. bergside/awesome-eve-agents creates a standalone agent directory. ## First, where did the agent come from? Start from the source, then pick the install that matches that destination. `@evex` and `@agentcn` are shadcn registry namespaces for agents added to an existing Eve app ([evex installation](/docs/installation), [agentcn installation](https://www.agentcn.run/docs/installation)). The bergside catalog uses its own CLI to create a new directory ([awesome-eve-agents](https://github.com/bergside/awesome-eve-agents)). Those commands are not interchangeable with each other, with a hand-written `agent/` tree, or with `eve init`, because each path writes to a different place. ## Into an existing Eve app Run an evex install from the root of the Eve app: `npx shadcn@latest add @evex/` The shadcn CLI copies the agent source under `agent/` and prompts for the npm dependencies the agent declares ([Installation](/docs/installation)). Agent files for that path are listed on [/agents](/agents). agentcn uses the same shadcn mechanic and publishes recipes for Eve, Flue, Mastra, and LangGraph (Dawn) ([agentcn installation](https://www.agentcn.run/docs/installation)). Its own Eve example, [Deep Search](https://www.agentcn.run/docs/agents/eve/deep-search), is: `npx shadcn@latest add @agentcn/eve/deep-search` Both commands run from the project root and write into an app you already have. Each namespace resolves entries from its own registry, and `@evex` resolves through the shadcn community registry with no configuration on your side. For how the two registries differ, see our [evex and agentcn comparison](/learn/evex-vs-agentcn). ## As a standalone agent directory bergside/awesome-eve-agents uses a separate installer ([README](https://github.com/bergside/awesome-eve-agents)). Its catalog is at [eveagents.dev](https://www.eveagents.dev). `npx @bergside/eveagents install ` The installer creates a new directory containing the complete agent. That destination is why it does not write into an existing Eve app. Enter that directory and start Eve: `cd ` `npx eve@latest` The project lists 21 agents under the MIT license ([README](https://github.com/bergside/awesome-eve-agents)). ## If you have no Eve app yet Eve requires Node.js 24 or newer ([Eve getting started](https://eve.dev/docs/getting-started)). When you still need an Eve app, the official scaffold creates one: `npx eve@latest init my-agent` Use this when you have no Eve app yet. After the app exists, catalog agents still install with the `@evex` or `@agentcn` commands above, not with another `eve init`. ## Decision table | Choice | Use when | Avoid when | | --- | --- | --- | | Scaffold a new Eve app | You do not have an Eve app yet. | You already have an Eve app, or you are installing a catalog agent into an existing app. | | Write the agent yourself | You are authoring your own agent files under agent/. | You want a ready-made agent from a catalog. | | Install from evex or agentcn | You want registry source copied into an Eve app you already have. | You want a standalone agent directory, or you still need to scaffold the app. | | Install from bergside/awesome-eve-agents | You want the agent as its own standalone directory. | You want the agent copied into an Eve app you already have. | ## Examples ### An evex agent in an existing Eve app You already have an Eve app and chose an agent on [/agents](/agents). From the app root, run `npx shadcn@latest add @evex/`. The agent source is copied under `agent/` in that app. ### A bergside agent as a standalone directory You chose an agent from [eveagents.dev](https://www.eveagents.dev) and want its own directory. Run `npx @bergside/eveagents install `, move into the new directory with `cd `, then start Eve with `npx eve@latest`. ## FAQ ### Is eve init the only way to install an Eve agent? No. `eve init` scaffolds a new Eve app when you do not have one. Catalog installs from evex or agentcn copy into an existing app. bergside creates a standalone agent directory. Match the command to the source and where the files should land. ### Why aren't the install commands interchangeable? The `@evex` and `@agentcn` commands copy registry entries into an existing app. The bergside CLI creates a standalone directory. `eve init` creates an Eve app. Scaffold, catalog-into-app, and standalone are different jobs. ### What lands where? evex writes the selected agent under `agent/`. agentcn writes its recipe into the existing app. bergside creates a new directory with the whole agent. `eve init` creates the app itself. ### Where is the source listed? evex publishes agent files on [/agents](/agents). agentcn documents each recipe in its own docs, for example [Deep Search](https://www.agentcn.run/docs/agents/eve/deep-search); our [comparison](/learn/evex-vs-agentcn) covers how the two registries differ. bergside lists its agents at [eveagents.dev](https://www.eveagents.dev). --- - Published: 2026-09-02 - Updated: 2026-09-06 - Web page: https://www.evex.sh/learn/install-eve-agent - This document: https://www.evex.sh/learn/install-eve-agent.md - All guides: https://www.evex.sh/learn