Amdahl documentation

Amdahl writes the outbound your team and your agents send. Tell it who the recipient is, what you know about them and what you want them to do, and get an email or a LinkedIn message back in the sender's own voice. It does not improve a draft: it writes from your context. That needs no connected data and no setup beyond signing in, and it answers on the same call, usually in 1 to 2 minutes.

Connect your CRM, call recordings and email and Amdahl can do more: look the recipient up in your own data, check the message's claims against what your own customers said, grade a draft line by line with the quotes behind each verdict, and search those conversations for rows and quotes. Every answer says how far it can be trusted, so your code can decide whether to act.

Start with the Optimizer

No data connected, nothing to configure. Pick the door that fits how you work:

Then put it to work:

Cookbook	What you get
Optimize a cold email	One message from the Optimizer, every field of the answer read end to end
Optimize a campaign	A script that turns a CSV of recipients into one message each
Optimize before you send	The call between the code that knows the recipient and the queue that sends the message, with its fallback
Keep your voice, rules and facts	The facts the message is written from, and the sender's rules and voice
Check claims against your customers	Once your data is connected: the claims nothing backs, listed before you send

Go deeper with your own conversations

The conversations are your CRM, call recordings, meeting notes and email, synced into one corpus. That corpus stays on the server; you do not send it with each request. Once it has synced, three more things open up.

The Optimizer, checked against your customers. Add "evidence": "workspace" to the same call and it also grades the message against what your customers said, and lists the claims nothing in their words backs. On a workspace with recipient evidence turned on, send recipient too, and Amdahl adds what your own data holds about that person.

Search and Eval, the two primitives that read the corpus:

Orchestration on top. Chat runs an agent that calls Search, Eval and outside market search for you when the ask needs several steps; Routines fire a Chat on a cron; Subscriptions fire one when an event happens; the agent library stores the instructions those runs use. Connections manage the data sources that fill the corpus. See Primitives for how the pieces fit.

Which call when

You want to	Use	Needs synced data
Write one message from what you know about the recipient, in the sender's voice, usually in 1 to 2 minutes	Message Optimizer (messages.optimize)	No
The same, with its claims checked against what your customers said	Message Optimizer with evidence: "workspace"	Yes
Grade a draft or copy against what customers said, pass or fail per rubric line with the quotes	Eval (prompt-and-message-eval)	Yes
Pull real customer quotes, or rows, on a topic	Search (search.query)	Yes

The Optimizer writes: from your context, on its default style pass it judges how the message reads and how clearly it asks, and once your conversations are connected it can also flag the claims nothing backs. The eval grades: it rules on every rubric line, with the quotes behind each verdict, and writes a better prompt. Every other GTM job maps onto these in Use cases.

Amdahl

• the message, and the checks that keep names, numbers and claims honest
• the corpus, synced and kept current
• retrieval, grading and the evidence behind every verdict

You

• the context: who the recipient is, what you know, and the positioning
• the orchestration around the calls
• the approval step before anything ships

What Amdahl is not

The misreads worth ruling out before you build:

You might expect	What it is instead
A tool that only improves your draft	The Optimizer writes the message from the context you send, and it is only as specific as that context. A draft is optional: sent with context, it is the starting point. On its default style pass it does not check a claim against your customers.
A predictor of reply rate	The Optimizer's checks and the eval's grade are rubric verdicts about the writing. Neither predicts replies or conversions; say so when you report them.
A CRM or a sequencer	Amdahl reads your CRM and call data, and nothing it does sends a message or changes your data. The Optimizer hands back text; you decide where it goes.
Web search	Search reads your own corpus only. Outside market signal comes in through a Chat at depth: "deep" or an eval with include_external: true.
A second opinion from the model that wrote the message	The Optimizer's returned message is re-checked by a different model, and the eval's judge scores both versions blind, against quotes it retrieved and cannot invent.

More ways to start

No workspace yet? Sign in at console.amdahl.ai/try with your work email to try the optimizer with 25 free runs. Your first run also puts you on the beta waitlist, and we email you when you are in. If your company already uses Amdahl, ask an admin there to add you.

You reach everything over REST (https://app.amdahl.ai/api/platform/v1, with an API key), over MCP (https://app.amdahl.ai/mcp, see Connect your agent) or from a terminal with the CLI. The operations are the same either way.

These docs are also an MCP server, at https://docs.amdahl.ai/mcp. It holds no data and needs no key, so an agent can read and search every page here on its own. See Read the docs over MCP.

Learn the model

• Optimizer, step by step: one email from context to result, with every try scored.
• Context: what to send so the message is specific.
• Primitives: the Optimizer, the two calls over your corpus, and the orchestration layer.
• Evidence and trust: the fields that say how far an answer can be trusted, and a policy for acting on them.
• How grading works: what an eval run does, and what its score is and is not.
• Patterns: the call sequences that work, such as optimize before send and gate before send.
• Use cases: GTM jobs mapped to the calls that serve them.
• Models and limits: versions, latency, caches, data handling and known limits.

Reference

• API reference: the live REST reference generated from the OpenAPI spec, with a built-in try-it console.
• Tool catalog: every operation an agent sees, projected from the operation registry.
• Errors: the error shapes and the codes worth handling.