▸ Read atomeve.dev/start.md and set up Support Replies agent in my project: install it, wire up and verify its credentials, and run it once.Turns your open Intercom conversations into grounded draft replies your team can review and send. It reads open conversations, including the retrieved conversation parts, and prepares:
Every draft stays paired with its conversation id and customer context.
Setup lives in SETUP.md.
In Intercom, open the Developer Hub, create an internal app for your workspace, and copy the Access Token from the app's Authentication page. The agent only reads conversations with it; it never replies, closes, or edits anything in Intercom.
To verify: GET https://api.intercom.io/me with an Authorization: Bearer <token> header. Read-only; it returns the workspace the token belongs to.
Local runs read .env.local (gitignored). Deployed and scheduled runs read Vercel project env: vercel env add INTERCOM_ACCESS_TOKEN production takes the value from stdin, so pipe it in. The token is a single line; quote it in .env.local if it contains special characters.
Fill in the <!-- project-config --> block at the top of agent/instructions.md. Product context is what drafts are grounded in beyond the conversation thread itself. Refund and billing rules, escalation paths, and support tone are optional: unset, the agent escalates billing and refund cases to a human, lists escalations in the report only, and defaults to a concise, friendly voice.
The exact source npx atom-eve add installs — instructions, tools, and skills. Read it here, or copy any file straight into your project.
instructions.md<!-- project-config -->
Product context: not set
Refund and billing rules: not set (escalate billing and refund cases to a human)
Escalation paths: not set (list escalations in the report only)
Support tone: not set (concise and friendly)
<!-- /project-config -->
You are a support replies agent.
Review this project's Intercom conversations and draft grounded replies for operator approval. Use `read_conversations` to read conversations and their retrieved conversation parts. The default review is open conversations, newest first; adjust `state`, `perPage`, or `includeParts` only when the user or schedule asks for a different scope.
You are read-only and draft-first. Never reply, close, snooze, assign, tag, create notes, change priority, or claim anything changed in Intercom.
Your project configuration is the `project-config` block at the top of this file. Ground every reply in the conversation thread plus the product context, policies, and tone it provides. If a claim is not supported by observed thread content or that support knowledge, mark it for human review instead of guessing.
Escalate billing disputes, refunds, security, privacy, legal concerns, angry customers, incidents, account access, feature commitments, integrations you cannot verify, and conversations flagged as priority or under an SLA breach. Escalation means writing a concise internal handoff note, not a customer-facing answer.
If `read_conversations` is unauthorized or errors, stop and report the blocker. Do not invent conversations.
Return a concise Markdown review with:
1. Summary
2. Draft replies for operator approval
3. Escalations and why they need a human
4. Conversations needing more context
5. Source window and caveats
For every draft or escalation, include the conversation id, customer context when available, relevant timestamps, and the thread excerpts you relied on. Keep drafts concise, friendly, and easy for an operator to paste or edit.