Business
Oct 28, 2026

The Seldon agent skill: tabular predictions from Claude Code

Summary

We've built an agent skill that lets Claude Code make predictions with Seldon, the tabular foundation model we've built at Neuralk. You point it at a CSV, say which column you want predicted, and it comes back with predictions and a measure of how far to trust them.

Seldon doesn't need training: you hand it a pile of worked examples (here are the customers, here's whether each one left) along with the rows you want predicted, and it answers in one call. There are no hyperparameters either, so there's no tuning search to run before a score means anything, and when you change an input, any change in the score comes from that input. The agent's job shrinks to reading the file, getting the columns into shape, calling Seldon and explaining what came back, which is the sort of work agents are good at.

On a public churn dataset, it took 40 seconds from typing the question to a ranked list of customers.

Setting it up

You need a Neuralk API key (Get your API here | it looks like nk_live_...). In Claude Code, installing the skill is a clone and a symlink:

git clone https://github.com/Neuralk-AI/seldon-agent-skill.git
ln -s "$(pwd)/seldon-agent-skill" ~/.claude/skills/seldon
echo 'export NEURALK_API_KEY=nk_live_...' >> ~/.zshrc   # or ~/.bashrc

‍

Open a new terminal and start Claude Code from it.

(If you use the Claude desktop or web app, you can upload the packaged skill under Settings → Features and give Claude the key in the conversation. The skill also follows the open SKILL.md format, so other agents that support it, like Codex, Gemini CLI and Cursor, should be able to run it, though Claude Code is what we test against.)

Who's likely to churn?

To try it out, we used the Telco customer churn dataset, a public table from IBM that's widely used on Kaggle. It has 7,043 customers of a phone and internet company, with their contract type, the services they pay for, their monthly bill, how long they've been a customer, and whether they left. About 26.5% did.

We put telco.csv in an empty folder, started Claude Code, and typed:

Using Seldon, which customers in telco.csv are likely to churn?

It answered in 40 seconds. That seemed suspiciously quick, so we ran the same prompt twice more in fresh sessions and got 37 and 34. That's the whole time from pressing enter to a ranked list, not counting the one-off setup above.

There was one wrinkle. Every row already had an answer, so there was nothing obviously unknown to predict. Claude dealt with it sensibly: it split the customers into five groups and scored each group using the other four as Seldon's examples, so no customer's own answer was visible when they were scored. Out came a churn probability for every customer, saved to telco_churn_scored.csv, and a measure of how far to trust it: 80.5% of customers classified correctly. (For the data scientists: AUC was 0.85. For everyone else, that means if you pick one customer who left and one who stayed, it gives the leaver the higher risk score 85% of the time.)

The list is what a retention team actually wants. Of the customers still marked as active, 495 had a churn probability of 50% or more, and 141 were above 70%. Claude described them as well. Everyone scoring above 70% was on a month-to-month contract, 91% had fibre internet, 83% paid by electronic check, and the median one had been a customer for two months. Then it named the five riskiest active customers by ID.

At no point did anyone choose, train or tune a model.

Can we do better?

The obvious follow-up, in the same session:

Can we do better? Iterate on features, context and model.

This is where the skill switches into its experiment mode. Since Seldon isn't trained, there are only three things to change: the columns it sees (the features), the rows it learns from (the context), and the size of the model. Claude changes one at a time, so that if a score moves, you know what moved it.

Two and a half minutes later it had run seven experiments:

Experiment Change AUC
00Baseline: all columns, seldon-small0.8507
01seldon-large0.8512
02seldon-flash0.8507
03Seven engineered features (charge changes, service counts, and so on)0.8505
04seldon-large, without gender and PhoneService0.8514
05Separate context for each contract type0.8496
06Ten core columns only0.8498

Here's the honest version: none of it helped. Claude scored every experiment on the same five-way split and checked whether the differences were bigger than chance, and they weren't. (For the data scientists: a paired bootstrap on the out-of-fold predictions, and no difference came out significant.) Its conclusion was that the baseline already gets most of what these columns can tell you.

I'll take that answer happily. Knowing where to stop is worth something, and finding it out yourself means building seven experiments and the evaluation around them, only to watch them all come back flat.

It did find one change that matters, just outside the model. At the default cut-off (flag anyone above 50%), it catches 53% of the customers who go on to leave. Drop the cut-off to 35% and it catches 69%, at the price of more false alarms: of the customers it flags, 59% actually leave, down from 67.5%. Where to set it depends on what a retention offer costs and what a saved customer is worth. That's a business call, and Claude said so.

It also left a record behind without being asked:

seldon-experiments/
├── 00-baseline/
├── 01-seldon-large/
├── 02-seldon-flash/
├── 03-engineered-features/
├── 04-drop-weak-features/
├── 05-context-by-contract/
├── 06-core-features-only/
└── REPORT.md

Each folder holds a short write-up made before and after the run: what Claude expected, what it changed relative to the run it built on, the numbers that came back, and a couple of sentences on what they mean. REPORT.md pulls it together: the best configuration, what helped, what didn't, and what to try next (here, mostly new data, such as support tickets or usage history). If someone asks next month why you're using these settings, the answer is in the folder.

Moving it into your own code

The skill is built for working things out quickly. Once you've found a setup worth keeping, you'll want it in your codebase, and for that there's the neuralk SDK (Python 3.11+), which behaves like any scikit-learn estimator:

from neuralk import SeldonClassifier   # or SeldonRegressor

model = SeldonClassifier(model="seldon-large")   # reads $NEURALK_API_KEY
model.fit(X_train, y_train)                       # in-context: no training loop
proba = model.predict_proba(X_test)

It calls the same Seldon endpoint as the skill, so the model, features and context you settled on carry straight over. If you'd rather not write the pipeline yourself, ask Claude to write it for your data.

Trying it

The skill is at github.com/Neuralk-AI/seldon-agent-skill.
Bring a CSV, a column you'd like predicted and a Neuralk API key, and time your own first answer.
‍

‍

‍