Give your agents real math.
There is no learned-prediction primitive in an agent session: no training, no validation, no memory of what converted. ax1om exposes trained models over MCP, so your agent calls a real model for scores and the factors behind them instead of writing a plausible number. Starting with scoring.
Copies one line. Paste it into Claude Desktop, Claude Code, Cursor, or any MCP client and it sets itself up.
Agents reason brilliantly. They predict badly.
Your agent can read the pipeline, plan the play, and write the follow-up. But ask it for a conversion likelihood and it generates a plausible number, not a prediction. There is no training run behind it, no validation, no memory of what actually converted. The guess arrives fluent and confident, which is exactly what makes it dangerous.
That leaves you exposed twice. To leadership, when an agent-driven call has nothing underneath it. And to your own team, because reps ignore agent output the same way they ignored black-box scores.
Wanting real math under your agents is not skepticism about AI. It is what taking agents seriously looks like.
Your agent didn’t predict that number. It wrote it.
Two machines, two jobs.
LLMs and trained prediction models are different machines, good at different jobs.
| Dimension | The LLM (your agent) | ax1om (the engine it calls) |
|---|---|---|
| Job | Judgment, orchestration, language - reads context, plans, writes, decides what to do next | Learned prediction - what converts, who churns, when to engage |
| Learns from | Pretraining plus the current session | Your own outcome history, continuously |
| On a number | Generates a plausible one and presents it with confidence | Trains, validates, predicts - and shows the factors and validation state behind it |
| Audit trail | None - the number cannot be reproduced or defended | Every prediction carries its SHAP factors and its validation state |
The fix is not a smarter prompt. It is a real model: trained on your outcomes, gated by validation, callable by the agent, explained down to the field. Agents reason. ax1om predicts.
What your agent can call today
Honest inventory, because that is the house style.
Conversion scoring is live on the MCP surface. The
server runs at POST https://api.ax1om.ai/mcp, streamable HTTP,
eleven tools. An agent can run a scoring trial end to end:
assess_fit checks whether your data is ready, and answers
honestly when it is not. generate_export_spec and
validate_csv prepare a scrubbed export without anything
leaving your org. train_model trains on your own
conversion history, get_readout reports the model quality
in plain terms, and score_records scores live, with the
factors behind each score on the response.
Customer health and timing ship in the product. Both are trained model families on the same rails: your outcomes in, validation gate, prediction with factors out. They are not on the MCP surface today, and we will say so here the day that changes.
The calculator that won’t let your agent lie with statistics
An agent would happily train a plausibly-wrong model and act on it. Leakage in the training data, labels too young to be trusted, a metric that flatters the model: none of these announce themselves, and a language model will not catch them for you.
ax1om’s gates stand between raw data and a callable model. Leakage detection flags fields that give away the answer before training. Label-maturity checks catch outcomes too recent to learn from. Validation gates every model before anything acts on it, and every prediction ships with the SHAP factors behind it, so a human can audit what the agent acted on.
This is not agent moderation. Moderation polices what a model says; these gates police the statistics, the leakage and immature labels that make a model plausibly wrong. Nothing acts on an unvalidated model.
From your CRM to a number your agent can defend
Connect your data
Salesforce · HubSpot · CSV. Or start scrub-first: your agent prepares a de-identified export before anything is connected at all.
Train on your outcomes
A dedicated model per customer, trained on your own conversion history. First-party data only, never shared, from as few as 50 conversions.
Validation gates it
Leakage detection, label-maturity checks, and validation before anything acts. A model that fails does not go live.
Your agents call it
Scores, predictions, and the factors behind each one, over MCP and API. Your team gets the same numbers in the CRM fields they already work.
Evaluate through your agent before you connect anything
You do not have to connect your CRM to find out if this works. Four of
the eleven MCP tools (assess_fit,
generate_export_spec, validate_csv,
safe_export_policy) run entirely in your agent’s
process and never touch the network, so the preparation happens with
nothing leaving your org.
The export policy is defined by field class: which columns may leave,
which never may. Record ids are hashed so returned scores still join
back to your CRM; email addresses are reduced to the domain, with the
personal part stripped before anything is exported; dates are
truncated to the calendar day. validate_csv lints the
file locally against the drop rules and never repeats back a value it
flagged. In the warehouse lane the same policy compiles to SQL, so the
scrub runs where the data lives.
A dataset that never contained direct identifiers usually does not need an infosec review, a DPA, or procurement, so you can evaluate on real data without asking anyone’s permission first.
What operators ask before connecting an agent
What stops my agent from acting on a bad model?
The model never exists. Leakage detection, label-maturity checks, and validation gates run before a model becomes callable, so a model that fails validation is not there for the agent to call. Every score the agent does get carries the SHAP factors behind it, so a human can audit any decision built on it.
How much control do I keep over what an agent can do?
All of it. You set the rules; agents operate inside them. Each agent authorizes with per-user OAuth, you approve exactly what it may do (score records · upload data · train models · read model results), and you can revoke a grant at any time under Settings · Connected agents. Revoking cuts the agent off immediately. Scores stay advisory: your thresholds, your writeback, and nothing routes until you say so.
What does my agent send to ax1om?
Only what the export policy allows, and you can see the policy before anything moves. Four of the eleven tools never touch the network, so fit checks and export preparation happen entirely on your side. What uploads is a scrubbed file with direct identifiers dropped or hashed, and what comes back to the agent is scores and factors, not your records.
Who else benefits from my model?
Nobody. ax1om trains a dedicated model per customer on that customer’s own conversion history: first-party data only, no third-party enrichment, no cross-customer pooling. Your models are yours.
Do I need a data-science team to run this?
No. ax1om handles the pipeline: feature engineering, training, validation, scoring, and writeback. The guided setup adapts to your data volume, and a first model trains on as few as 50 conversions. No code, no notebooks, no platform team.
Can my agent call the health and timing models too?
Not over MCP yet. Customer health and timing are trained model families that ship in the product, on the same rails as scoring: your outcomes in, validation gate, prediction with factors out. What agents call over MCP today is conversion scoring, end to end.
Your agent’s next number can be a real one.
Connect your agent and run the fit check in minutes, or start from your data and train first. Either way, every prediction is trained on your outcomes, validated before anything acts, and explained down to the field.