Architecture
How the research engine actually works
Enough detail to judge whether the approach is sound, without turning into an implementation guide. The short version: it researches one account, decides whether there is a defensible reason to start a conversation, and is built to stop when there isn't.
The pipeline
Evidence collection, commercial reasoning, message generation and quality control are separate, inspectable stages. The quality gate can end a run before anything is sent - the opposite of how most tools in this category behave.
Research first.
Reason second. Send last.
Amoris separates evidence collection, commercial reasoning, message generation and quality control into inspectable stages.
Input
Company, lead and campaign context enter the system.
Research
Agents gather observable signals before reasoning.
Reason
Evidence becomes a bounded GTM hypothesis.
Compose
The system turns the hypothesis into an outreach draft.
Judge
A separate evaluator tests the output against the quality rubric.
Approved outputs can flow back into CRM, campaigns and downstream GTM workflows.
Nothing continues past a HOLD. There is no queue it lands in, and no setting that overrides it into sending.
- A dormant cohort, reviewed one record at a time.
- Each one is checked against evidence that was recorded when the deal died.
- A few have a defensible reason to reopen. Most do not.
- The system resolves most of them to HOLD, and stops.
- Maximum economically justified activity - not maximum activity.
- The ratio depends on your data. This is a shape, not a benchmark.
Built today, and being extended
The diagram above describes the whole design. Not all of it is deployed, and it is worth being exact about which part is which.
Built and running
- Live web research against a named account, returned as a structured read
- Observations carried with the source behind each one
- A fit and signal assessment produced from that evidence, not from a database
- An HTTP API, with every run written to disk so a decision can be re-read later
Built, in private testing
- The reasoning layer that turns a signal into a commercial hypothesis and message angle
- The judge, and the second HOLD that can stop a message after it has been written
- Deployment of the reasoning layer alongside the research layer
- A wider experience library for the reasoning step to draw on
Tested against a small number of real accounts. No completion date is being promised.
Evidence, and the line between fact and inference
Research produces observations, and each one carries the source it came from. That constraint is what everything downstream leans on: a claim that cannot be traced back to an observation is not supposed to survive to the output.
The distinction the system is built to hold is between what was observed and what was inferred from it. An observation can be stated. An inference is written as curiosity - a question about how something is handled - rather than as a diagnosis of a problem the company never said it had.
This is the difference between a message that reads as though someone looked, and one that reads as though a model guessed confidently. Most AI-written outbound fails precisely here.
The judge
Once a draft exists it is evaluated against 14 checks before anything reaches you. The checks are aimed at the account and the reasoning, not at prose style. In categories, they ask:
- Whether each claim about the company traces back to something actually found in the research
- Whether inference is visibly marked as inference rather than asserted as established fact
- Whether anything about the company - a claim, a result, a relationship - has been invented
- Whether a referenced piece of experience is real, rather than whether the analogy is elegant
- Whether the message makes one clear argument, stays short, and asks for something small
- Whether it reads as generic AI outreach, and whether a senior person would actually reply
What the judge is not
It is an evaluation mechanism, not an oracle. Two limits are worth stating plainly, because they affect how much weight the output deserves.
Separation matters, and it is worth asking about. An evaluator that shares a pass with the writer has no outside vantage point on its own work. Separating them is what makes a quality gate meaningful rather than decorative, and it is a fair thing to probe on a first call.
A READY is not a verdict on the account. It says the reasoning survived the checks. It does not say the company will reply, will buy, or has the problem the hypothesis proposes.
HOLD
There are two exits, and they fire at different moments for different reasons.
The first fires before anything is written. If the strongest available signal is too weak, too generic or too contradictory to support a credible commercial argument, the run stops and says so. No draft is produced, and the work of producing one is never done.
The second fires after a draft exists. If a claim about the company cannot be traced back to the research, or an inference has been dressed up as fact, the draft is held with the reason attached. It exists, and it is marked unsendable.
A HOLD is a quality gate, not a correctness guarantee. It lowers the chance of sending something the evidence does not support. It cannot tell you that a message is right, and it is not a substitute for reading the output.
The rate of HOLDs across a batch tends to say something true about the list, not about the system.
Where the system stops and you start
The output is a file you read. Nothing is connected to a mailbox, there is no sending integration, and autonomous sending is not on the roadmap - it is a design decision, not a missing feature.
The division is deliberate: the system does the research and the first draft, which is the part that scales badly and consumes senior time. The decision to contact a specific person stays with the person whose name is on the message.