marketing-team-eve-template: five specialists and one file they all read

One lead, five specialists, and the lead never writes

The hierarchy is the design. A lead agent loads the brand context and your preferences, writes a brief for whichever specialist fits, and hands back what that specialist produced. It never writes a deliverable itself, which is an unusual thing for a lead to give up and it removes the most likely place for work to be quietly improvised. The five specialists each own one channel. The product marketer owns positioning, messaging, competitive alternatives and the shared brand document. The content marketer owns long-form: blog posts, landing pages, case studies, newsletters and docs. The social media coordinator owns short-form across X, LinkedIn, Threads, Bluesky and Mastodon plus the publishing queue. `seo` owns page and site audits, hierarchy, internal linking, schema markup and templated page sets. The email specialist owns reworking copy for the inbox and then building, targeting and sending. The sample exchange in the README shows the shape: a launch request produces three drafts sitting unscheduled in the publishing queue, waiting for a human to say when.

Every brief is self-contained, so no specialist remembers anything

This is the architectural decision that shapes everything else, and it runs against the usual agent design. Specialists start fresh on every task with no shared conversation history between them, so the lead's brief has to carry all of the context, and each specialist separately reads the brand document at the start of its own work. Delegation goes exactly one level deep: specialists do their own research and revise their own drafts against a written rubric rather than spawning further agents. The benefit is legibility. There is no emergent group state to reason about, every hand-off is inspectable, and adding a specialist cannot change how the existing ones behave. The cost is repetition, since context that a persistent conversation would have carried is rewritten into each brief, and a long project lives in the documents and the threads rather than in the agents' heads.

The brand context document is the only shared state, with one owner

Because specialists share no memory, the team needs one piece of durable shared state, and the documentation says plainly what it is: a short file describing what the product is, who it is for, and what the team claims about it. The product marketer maintains it. Every other specialist reads it at the start of a task. Because it is the only shared state, it is given a single owner rather than being edited by whoever happens to be working, which is the cheapest way to stop a positioning decision drifting between five agents. The same routing logic shows up in how newsletters are handled: they go through two specialists rather than one. The content marketer writes the prose, then the email specialist adapts it for the inbox and sends it through the email provider, so a newsletter still gets the content marketer's planning and editing passes rather than being written purely as an email.

Irreversible actions stop; drafting does not

The approval boundary is drawn by enumerating what the team cannot do alone, and the enumeration is specific. Sends and deletes in the email provider wait for you. Deletes and scheduled publishes in the social tool wait for you. Page moves in the wiki wait for you. Drafting is deliberately left friction-free, which is what keeps the loop fast, and the approve or deny control appears in the chat surface or the terminal before anything goes out. There is also a numeric limit behind it: the email specialist is given 47 of that provider's roughly 85 tools, so account administration is out of reach entirely rather than merely unapproved. One boundary sits outside the agents. Before a first campaign you have to verify a sending domain and create at least one segment yourself in the provider dashboard, because the agent can see your verified domains and segments and pick from them but cannot create a domain or verify DNS records.

Each specialist hands back something in the tool it owns

Deliverables land where the team already works rather than in a chat transcript. The content marketer returns a link to a wiki page. The social coordinator returns drafts sitting in the publishing queue. The email specialist returns a link to a campaign. The SEO specialist returns recommendations, with long audits written out as artifacts rather than pasted into a message. A fresh chat session in the chat client comes with four starter prompts pinned by the team, one per specialist: sharpen our positioning, write a blog post, draft social posts, and review a page's search performance. That is the intended entry point, and it is a deliberately small surface, four sentences that map one to one onto the four things this team is for.

One click wires five integrations and asks for one key

Deployment provisions the connectors rather than making you configure them, and the list is worth reading as a dependency statement. A Notion connector for long-form work and briefs, a Resend connector for email, a Slack connector for the chat surface, a blob store for shared state and files, and a prompt for the publishing API key. Underneath, the stack table is equally explicit: the eve framework as the agent runtime, TypeScript in strict mode with ES modules on Node 24, chat through Slack by way of a managed connector plus a local development TUI, Notion and the social tool and the email tool each reached over the Model Context Protocol, blob storage for shared files, a gateway for model access, and a sandbox for skill reference files and shell access. Linting and formatting go through a preset of an existing formatter, with `pnpm check` and `pnpm fix` mapped to check and auto-fix.

A template on version 0.0.0 with an import path to nowhere

The manifest describes something you clone rather than depend on. The version is 0.0.0, which is what a template looks like before anybody versions it, and there are no tagged releases in the repository. The import map is short, one entry resolving to the agent directory and a second resolving to an evals directory that is not present in the tree, so the evaluation surface the imports anticipates has either not been committed or lives elsewhere. The dependency block is inconsistent in a way that will matter if you pin: three packages use caret ranges while two are pinned to exact versions, and TypeScript in the development dependencies is pinned to an exact version too. The engines field asks for Node 24 and nothing else.

The local loop is three commands, taken as printed:

vercel link
vercel env pull
pnpm dev

Link a deployed project or a fresh one, pull its environment, then start the development TUI and run the model command once to attach a provider. The rest of the surface is a short command table: `pnpm validate` chains linting, type checking and framework discovery into one, `pnpm check` and `pnpm fix` run the linter in check and auto-fix mode, `pnpm typecheck` runs `tsc --noEmit`, `npx eve info` prints every discovered tool, skill, connection and subagent, and `eve deploy` ships to production.

Two files hold the detail the visible text points at but does not carry: `docs/ARCHITECTURE.md` for the full approval matrix and the credential model, and `docs/CUSTOMIZING.md` for the files the agent reloads as you edit them. The customizing section is where the visible copy stops mid-sentence, so what either of those two documents contains cannot be confirmed from here.

Editorial conclusion

marketing-team-eve-template fits a small team that publishes to Notion, Typefully and Resend and wants an approval step before anything leaves the building. It fits badly for anyone expecting agents that accumulate context across a long session, because specialists start fresh every time and everything has to survive inside a brief and one brand file. Three things to know before deploying it. The credentials come from a one-click deploy that wires a Notion connector, a Resend connector, a Slack connector and Blob credentials, then prompts you for a Typefully key, and the email side still needs manual setup in the Resend dashboard for a sending domain and a segment, which the agent cannot do for you. Safety comes from approval rather than isolation, since the email specialist is given 47 of Resend's roughly 85 tools, so what is deliberately left out is the account administration surface. And this is a template rather than a product: the manifest version is 0.0.0, the import map points at an evals directory that is not in the tree, and the dependency block mixes caret ranges with exact pins, so expect to adjust it. MIT licensed, last pushed on 20 August 2026, no tagged releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vercel-labs/marketing-team-eve-template on GitHub