Primitives

Amdahl gives you three calls. The Message Optimizer needs nothing but a draft. Search and Eval are the two primitives over your buyer conversations, which Amdahl holds server-side, and everything else on the API is either built from those two or manages the data behind them.

The Optimizer

POST /messages/optimize (the messages tool over MCP) takes one outbound draft, an email or a LinkedIn message, and returns a stronger version in the sender's voice on the same call, usually in under 30 seconds. When nothing it tries beats the draft, it returns the draft unchanged with edits the sender can make.

• It needs no connected data. Its default is a style pass: how the draft reads and how clearly it asks. That is why it is the first result a new workspace can get.
• It keeps what must stay exact. Names, numbers, dates, links and merge fields come back as written, and a rewrite that changes one is discarded.
• It can read your corpus when you ask. With "evidence": "workspace" on a workspace with synced conversations, it also grades the draft against what your customers said and lists the claims nothing in their words backs.
• It sends nothing. It hands back text, and nothing in your tools or your corpus changes. Where the text goes is your decision.

Scope: messages:execute. Start with Optimize a cold email; the reference is Message Optimizer.

The corpus

The corpus is every customer conversation Amdahl holds for your workspace: call and meeting transcripts, email, and CRM records, synced from your connections. You never send it with a request. What you send is a question or a draft, and the server reads the corpus to answer.

That is the main difference from a model API. The state your call depends on is already on the server, scoped to your workspace and to what your credential may read. It also means a call on an empty workspace has nothing to read: check GET /search/overview before you trust an empty result.

The two primitives

	Search	Eval
Call	POST /search/query	POST /evals/run
Shape	Synchronous, one blocking call (a 15 second ceiling on the default path)	Async: returns a run id, you poll with wait_ms
You send	Typed filters, a plain-language question, a meaning to match, or a quoted phrase	A prompt, a drafted message, or both, plus optional scope
You get back	Rows or utterances, the SQL or terms that produced them, and a corpus block naming the store that answered	A pass or fail per rubric line, the customer quotes each verdict rests on, a send/hold bit, and an improved reusable prompt
Scope	data:read	evals:execute to run, evals:read to read
Changes your data	Never	Never. A run is read-pure.
Reference	Search	Evals API

Search

Search answers a question about your conversations. Every call lands on one of four lanes: filter (typed predicates compiled into one SELECT, no model involved), fuzzy (a plain-language ask turned into SQL), semantic (ranked by meaning against customer-side utterances), or lexical (exact terms, reached by quoting a phrase). The response names the lane that ran in mode_ran, and the lanes read different stores at different grains, so read that field before you compare two results.

Eval

Eval answers "is this draft any good, and what would make it better", scored against what your customers said. The built-in instrument is prompt-and-message-eval: five binary rubric lines on the message, five on the prompt, quotes that are retrieved and never written by the model, and a judge that scores your draft and the improved version blind in one call. How grading works explains the run; the Evals API is the field reference.

Choosing between them

You want	Reach for
A better version of one outbound draft, now, with nothing connected	The Optimizer
That, plus the draft's claims checked against what your customers said	The Optimizer with evidence: "workspace"
A number, a list, a slice of deals or conversations	Search, mode: "filter" when you know the fields; plain language otherwise
What customers said about a topic, in their words	Search, mode: "semantic" with hydrate: true
Whether a specific word or name was said	Search with the term in double quotes (the lexical lane)
Every claim in a draft ruled on, with the quotes behind each verdict	Eval, the default rewrite mode
A verdict on copy before it goes out	Eval, inputs.mode: "gate" for just the send/hold bit
A better prompt for next time	Eval, the default rewrite mode
An answer that needs several steps, outside market signal, or a written deliverable	A Chat, which calls both for you

The orchestration layer

These are conveniences built on the two primitives. None of them reads anything Search and Eval cannot.

• Chat runs an agent server-side that calls Search, Eval and, when you allow it, outside market search. You get handles back and poll. The default depth answers from your own corpus; depth: "deep" adds market search.
• Agents are saved instructions a Chat can run by name.
• Routines fire a Chat on a cron.
• Subscriptions fire a Chat when an event happens.

Use them when you would otherwise write the loop yourself. Skip them when you want control flow in your own code: two Search calls and an Eval are cheaper and easier to test than a Chat that does the same thing.

Data behind the primitives

Connections manage the CRM, call recorder, email and other sources that fill the corpus: what can be connected, what is connected, and how healthy each sync is. They change what Search and Eval can see; they do not answer questions.

Two ways to call them

The same operations are reachable over REST (https://app.amdahl.ai/api/platform/v1, with an API key) and over MCP (https://app.amdahl.ai/mcp, see Connect your agent). Over MCP, Search is the search tool, Eval is the evals tool, the orchestration layer is the agents tool, connections are the connections tool, and rewriting an outbound draft is the messages tool.

Next

• Optimize a cold email: the Optimizer on one draft, read end to end.
• Evidence and trust: the fields that say how far a result can be trusted.
• Patterns: the call sequences that work.
• Use cases: GTM jobs mapped to these calls.