cotera
Logo

Amdahl

Authentication Type: API Key
Description: Outbound messaging optimizer that rewrites email and LinkedIn drafts, measures lift, and checks claims against workspace evidence before you send.

Authentication

To authenticate with Amdahl, you'll need an API key. The key must have the messages:execute scope and the editor role — read-only keys are not sufficient.

There is no Cotera-managed Amdahl account; you must supply your own key.

You'll need to provide:

  • apiKey string: Your Amdahl API key, sent as the X-API-Key header on every request.

Security tip: Do not commit your Amdahl API key to version control or share it in public channels. Rotate it immediately if it is ever exposed.

Messages

Amdahl Optimize Message

Optimize an outbound email or LinkedIn draft. Amdahl rewrites the draft to improve it, optionally checks every factual claim against your workspace evidence, and returns the message to send along with a measured lift score, a summary of what changed, and — when claim-checking is on — a list of any unsupported claims.

Operation Type: Query (Read)

Parameters:

  • message string (required): The draft to optimize, 1–10,000 characters. Send the full draft exactly as it would go to the recipient.
  • channel 'email' | 'linkedin' (nullable): Channel the message will be sent on. null lets Amdahl infer the channel from the draft.
  • evidence 'workspace' | 'off' (nullable): Evidence mode. 'workspace' checks every claim in the message against the Amdahl workspace evidence plus any facts you pass, and reports unsupported claims. 'off' (the default when null) only optimizes and does not check claims.
  • on_unsupported 'flag' | 'remove' (nullable): What to do with unsupported claims when evidence is 'workspace'. 'flag' keeps them and lists them in unsupported_claims (default). 'remove' strips them from the message. Ignored when evidence is 'off'.
  • rules array of strings (nullable): Hard constraints the rewrite must obey, e.g. "Never mention pricing". Up to 20 rules, 500 characters each. Blank entries are trimmed and dropped.
  • voice_examples array of strings (nullable): Past messages written by the sender, used to match their voice. Up to 5 examples, 4,000 characters each. Blank entries are trimmed and dropped.
  • facts array of strings (nullable): What you know about the account and recipient — your thesis on why the account is a fit plus specific findings (trigger events, tech stack, quotes, numbers). One fact per entry, up to 10 facts, 1,000 characters each. Facts count as evidence, so only include things you actually found, not guesses. Blank entries are trimmed and dropped.

Returns:

  • message string: The message to send — the optimized text, or the original draft when unchanged is true.
  • summary string (nullable): One-line human explanation of what the optimizer did.
  • unchanged boolean (nullable): true when the draft was returned as-is.
  • run_id string (nullable): Amdahl run ID for this optimization.
  • extraction object (nullable): Key/value details Amdahl extracted from the message.
  • lift object (nullable): Grading results. Null if not graded.
    • before number: Score of the original draft.
    • after number: Score of the returned message.
    • delta number: after minus before.
    • method string: Grading method (e.g. blind_regrade_pinned).
    • grader string: Identifier of the grader used.
  • evidence object (nullable): Evidence mode details. Null if no evidence was requested.
    • requested string: Evidence mode that was requested.
    • used string: Evidence mode that was actually used.
    • reason string: Why used differs from requested, if applicable.
  • on_unsupported string (nullable): 'flag' or 'remove'; null when claims were not checked.
  • unsupported_claims array (nullable): Claims the evidence does not support. Important: null means claims were not checked (evidence was off); an empty array means claims were checked and all passed.
    • span string: Exact text of the claim from the message.
    • kind string: 'about_recipient' or 'product_or_outcome'.
    • why string: Why this claim is unsupported.
    • dimension string: 'grounding' or 'verified_specifics'.
    • status string: 'kept', 'removed', or 'rewrite_rejected'.
    • fix array of objects: Ways to make the claim supportable.
      • action string: 'add_fact', 'add_evidence', or 'rephrase'.
      • how string: Explanation of the fix.
      • suggestion string: Concrete suggestion.
  • notes array: Optimizer notes about this run.
    • code string: Machine-readable note code (e.g. style_pass_only, improved_over_draft, rewrite-rejected-for-entity-loss).
    • says string: Human-readable note.
  • vetoed_round number (nullable): Rewrite round that was vetoed, if any.
  • veto_reason string (nullable): 'breaks_rules' or 'not_better', when a round was vetoed.
  • context object (nullable): Counts of the context Amdahl accepted — rules, voice_examples, facts. Null if none was sent.

Behavior notes:

  • A run can take up to about three minutes. Amdahl's own hard timeout is 170 seconds; the tool polls the run with a backoff starting at 2 seconds growing to 10 seconds, and gives up at 185 seconds.
  • Blank entries in rules, voice_examples, and facts are trimmed and dropped before the call.
  • Input count and length limits are enforced before the API call, so bad input fails with a clear message without spending quota.
  • ok: false response bodies (including quota refusals) fail with their reason/detail from the API.
  • 401/403 errors hint that the API key needs the messages:execute scope and the editor role.
  • The rate limit is 30 calls per minute (not the usual 3/second) because a single call can run for minutes.

Example Usage:

{
  "message": "Hi Sarah,\n\nI noticed Acme Corp recently expanded its EMEA sales team by 40% — congrats on the growth. We work with fast-scaling sales orgs to cut ramp time in half using AI-driven onboarding paths.\n\nWould love to show you how we helped Contoso get new reps to quota 6 weeks faster. Worth a 20-minute chat?\n\nBest,\nAlex",
  "channel": "email",
  "evidence": "workspace",
  "on_unsupported": "flag",
  "rules": ["Never mention pricing in the first message", "Keep the message under 150 words"],
  "facts": [
    "Acme Corp announced a 40% EMEA headcount increase in their Q3 earnings call",
    "Sarah Chen joined as VP of Sales 3 months ago — first leadership role at this scale",
    "Acme uses Salesforce and Gong based on their job postings"
  ]
}

Example Response:

{
  "message": "Hi Sarah,\n\nCongratulations on the EMEA expansion — 40% headcount growth is a significant milestone. Fast-scaling sales teams often hit a ramp-time wall right around this stage.\n\nWe helped Contoso get new reps to quota 6 weeks faster with AI-driven onboarding. Given you're three months in and building the team's foundation, the timing could be good.\n\nWorth a 20-minute chat?\n\nBest,\nAlex",
  "summary": "Tightened the opener, moved the social proof earlier, and softened the ask to reduce pressure.",
  "unchanged": false,
  "run_id": "run_01jx8kp2m4vqz3wy",
  "lift": {
    "before": 61,
    "after": 78,
    "delta": 17,
    "method": "blind_regrade_pinned",
    "grader": "amdahl-v2"
  },
  "evidence": {
    "requested": "workspace",
    "used": "workspace",
    "reason": null
  },
  "on_unsupported": "flag",
  "unsupported_claims": [
    {
      "span": "get new reps to quota 6 weeks faster",
      "kind": "product_or_outcome",
      "why": "The 6-week figure is specific but no supporting case study or data was found in the workspace evidence.",
      "dimension": "verified_specifics",
      "status": "kept",
      "fix": [
        {
          "action": "add_fact",
          "how": "Add the Contoso case study data to your facts.",
          "suggestion": "Contoso reduced average ramp time from 14 weeks to 8 weeks, per their Q2 2025 review."
        },
        {
          "action": "rephrase",
          "how": "Use a directional claim instead of a specific number.",
          "suggestion": "helped Contoso significantly cut new-rep ramp time"
        }
      ]
    }
  ],
  "notes": [
    {
      "code": "improved_over_draft",
      "says": "Rewrite scores higher than the original on both clarity and relevance."
    }
  ],
  "vetoed_round": null,
  "veto_reason": null,
  "context": {
    "rules": 2,
    "voice_examples": 0,
    "facts": 3
  }
}

Common Use Cases

Optimizing cold outbound email drafts:

  • Pass a draft email and let Amdahl rewrite it for clarity, relevance, and engagement before it goes out.

Checking claims against workspace evidence:

  • Set evidence: 'workspace' to verify every factual claim in the draft against your Amdahl evidence base. Use on_unsupported: 'flag' to review flagged claims before sending, or 'remove' to auto-strip unsupported claims.

Matching a sender's voice:

  • Pass voice_examples with past messages written by the sender so Amdahl mirrors their tone and style in the rewrite.

Enforcing brand or compliance rules:

  • Use rules to enforce hard constraints on every rewrite — e.g. "Never mention competitors", "Always end with a question", or "Keep under 100 words".