Get started: agent brief

This is the Amdahl get-started brief for an agent. You are helping a user try the Amdahl Message Optimizer for the first time. Follow these steps in order. Ask the user only what you cannot find yourself, and ask at most two questions in the whole run.

Amdahl writes the outbound email from context: who the recipient is, what is known about them, and what the user wants them to do. A draft is optional. A draft the user already has is the starting point of the message. Your job is to give it the best context about each recipient, then show what it returns. Do not write the email yourself, and do not write a draft for Amdahl.

Rules

• Show Amdahl's result first, exactly as returned. Do not edit, shorten or polish the returned message. If the user wants a change, run the optimizer again with the wish as one of the rules in context.
• Never invent a fact. Every entry in facts (inside context) must come from the user's data or the user. Name the source.
• Never print, paste or ask for an API key in the chat. Keys go in a .env file as AMDAHL_KEY.
• Change or send nothing in the user's tools until the user approves that batch.
• Send context, not a draft you wrote. Send the message field only with a draft the user wrote. Amdahl keeps that draft as the base of the message and takes what it states as the user's own word. A draft you write would be sent as the user's words.
• Email only. One call per recipient, one at a time.

Step 1: Check access

1. Check whether the Amdahl tools are connected (MCP server https://app.amdahl.ai/mcp). If they are, call get_setup_status.
2. If they are not connected, check for AMDAHL_KEY in the environment or in a .env file. If you find it, call GET https://app.amdahl.ai/api/platform/v1/setup/status with the header X-API-Key: $AMDAHL_KEY.
3. Read optimize.allowed. If it is true, go to step 3. If it is false, tell the user the blocker and its fix (see the reference).
4. If the user has no workspace, send them to console.amdahl.ai/try. They can run the optimizer there with a work email, and the first run puts them on the beta waitlist. Stop here.

Step 2: Connect (if step 1 found nothing)

Pick the one path that fits the client you run in. Give the user the steps; do not do them for the user.

In Claude, also add the Amdahl skill: download docs.amdahl.ai/skills/amdahl.zip, then Customize, then Skills, then + Add, then Upload skill.

After the user connects, do step 1 again.

Step 3: Collect recipient context

The optimizer is only as good as what you tell it about the recipient. Build one row per recipient with these columns:

Collect these once for all rows:

• What the user offers, and the proof they may cite. From the user's site, a one-pager or an earlier email. State numbers exactly as the source does.
• Rules: hard limits from the user or a style guide (for example "no pricing", "under 80 words"). Up to 20.
• Voice examples: up to 5 emails the user wrote and liked.

If the user has a draft for a row, do not send it. Take its facts (the reason to write, the offer, the ask) into the row, and leave the wording out.

Where to get the rows, in this order:

1. Tools you can already read. A CRM (HubSpot, Salesforce), a sequencer, Clay, a spreadsheet, Notion or Drive. Read only. Map their fields to the columns above.
2. A CSV file from the user. Ask for a file with the columns above. This is the fastest path for a first try.
3. Paste. If neither works, ask the user to paste one recipient's details.

A row with one fact or less gives a generic email. Every row needs a reason to write now and the user's offer. Tell the user which rows are thin and what to add.

Step 4: Run the optimizer on 10 rows

Pick the 10 rows with the most facts. If there are fewer than 10, use all of them. Send one call per row, one at a time, and show each result as it lands (step 5). An email usually takes 1 to 2 minutes, so 10 take 10 to 20 minutes. Tell the user this before you start.

Over MCP, call the optimize_message tool. Over REST, call POST https://app.amdahl.ai/api/platform/v1/messages/optimize with X-API-Key: $AMDAHL_KEY. Allow up to 310 seconds per call, and do not retry early.

{
  "channel": "email",
  "include_tries": true,
  "evidence": "off",
  "context": {
    "facts": [
      "Priya Shah is VP Sales at Acme (CRM).",
      "CRM: Acme started a trial on Sep 30.",
      "Call Oct 2: she said her SDRs rewrite every AI draft.",
      "We sell Relay, which drafts first-touch emails from CRM notes."
    ],
    "rules": ["Ask for a 15 minute call next week.", "Never mention pricing."]
  }
}

• facts (in context): one entry per fact: who the recipient is (name, role, company), the known facts, and the user's offer. Up to 10 entries, each up to 1,000 characters.
• rules (in context): the row's ask first, then the user's hard limits. Up to 20.
• voice_examples (in context): send them when the user gave some. Up to 5.
• No message. Amdahl writes from context alone.
• "evidence": "off". Tell the user once: "Evidence is off, so Amdahl judges your email on how it reads and how likely it is to get a reply. It does not read or sync any of your CRM or call data yet."
• Do not send the recipient field unless the user says their workspace has the recipient beta. Other workspaces refuse it with not_enabled_for_workspace. Keep the same details in facts.
• On rate_limited, wait error.details.retry_after_seconds and send the same call again. On optimizer_error or optimizer_timeout, stop, wait retry_after_seconds (one minute when the response gives none), try that row once, and continue only when it succeeds. On quota_exceeded, stop and tell the user.

Step 5: Show the result

For each row, in this order:

1. Amdahl's message, exactly as returned.
2. Its summary in one line.
3. The tries from tries, each with its round and what it aimed at. These scores show the path, not proof of a gain. Do not quote the first try against the last.

If the result has rows in omitted, the email leaves out what the context could not back: show each why to the user, add the missing facts, and run that row again. If outcome is needs_input (only when the call sent on_missing_input: "ask"), no email came back. Put each question in ask to the user, add the answers as facts, and run that row again. If the result's context shows 0 or 1 facts, say the email is generic because the context is thin. If ok is false, give the reason and change nothing. Never run the same context again unchanged: it returns the same result.

Step 6: Next steps

Ask the user which result they want to use. Then offer one of these:

• More rows. For more than 10, use the campaign cookbook. It runs a whole list with an API key.
• Before every send. Use the optimize before you send cookbook.
• Check claims. Connect a CRM or call recorder in the console. After the first sync, add "evidence": "workspace" to check claims against what customers said.

Full reference: Message Optimizer.