Teaching an LLM Your Betting System: How to Build a Personal AI Research Assistant

[Betting Forum]

Most bettors who use LLMs for research are using them wrong. Not wrong in the sense of prompting badly - though that's often true as well - but wrong architecturally. They open a new conversation, ask a question, get an answer, close the tab, and repeat. Every session starts from zero. The model has no idea who they are, what they're trying to do, which competitions they follow, what their edge looks like, or what constraints they're operating under.

The result is generic outputs. The model is helpful in the way a knowledgeable stranger is helpful - it can answer questions, it can explain concepts, it can process information you give it. But it doesn't know your system. It can't filter analysis through your framework because it doesn't know your framework exists. It treats your question the same way it treats a question from someone who's never thought seriously about betting.

There's a better architecture. It takes a few hours to set up properly and maybe thirty minutes of maintenance every couple of months. After that, you have something that functions like a research assistant who understands how you think rather than a search engine that returns generic answers.

This is how to build it.

Recommended USA sportsbooks: Bovada, Everygame | Recommended UK sportsbook: 888 Sport | Recommended ROW sportsbooks: Pinnacle, 1XBET

What "Knowing Your System" Actually Means

Before you can teach the model anything, you need to know what you're teaching. That sounds obvious but it isn't - most bettors have an analytical approach that they've never fully articulated. They know what they look for, they know what makes a bet interesting to them, they know which competitions they're comfortable in and which they're not. But they've never written it down in a form that transfers to someone who doesn't already think the way they do.

That's the first step. Not a prompt, not a system message - a document you write for yourself that describes your betting approach as if you were explaining it to an intelligent colleague who knows betting in general but knows nothing about your specific method.

The document needs to cover five things. Your target competitions and why you focus on them - the specific reasons you're comfortable in the Championship but not La Liga, or active in the Scottish Premiership specifically. Your analytical framework - which variables you weight and in what order, which markets you approach, which you avoid and why. Your historical edge patterns - where you've found consistent positive CLV, what types of fixtures produce it, what types don't. Your account management situation - which operators you're working with, which have already restricted you, what your typical stake sizing looks like. And your constraints - time available per week, data access you have and don't have, competitions you've decided not to cover regardless of apparent opportunity.

This document doesn't go into the model wholesale - it gets refined into a system prompt. But writing the full version first forces you to think through what you actually believe rather than what you think you believe. Those are often different, and the gap between them is where a lot of betting inconsistency originates.

The System Prompt Architecture

A system prompt is the instruction layer that sits above a conversation. In Claude and GPT-4, it's the text you add to the system field before the conversation begins. In interfaces that don't expose a system field directly - and some don't - you put it at the start of your first message with a clear label, and it functions similarly.

The system prompt is what transforms a general-purpose model into your research assistant. It's not a query. It's a persistent instruction set that frames every response the model gives you within that conversation.

The architecture that works has four components, in this order.

Identity and purpose. A brief statement of who you are as a bettor and what you're using this assistant for. Not vague - specific. Not "I'm a sports bettor looking for value" but something like: "You are a betting research assistant working with a bettor who focuses on English football, primarily the Championship and Scottish Premiership, with occasional Premier League activity in specific market types. The focus is finding pre-match edges in total goals, Asian Handicap, and player prop markets. Match result markets in main competitions are treated as largely efficient and generally not targeted."

Analytical framework. The variables you weight and how you weight them. This is where the document you wrote becomes useful - you're compressing the relevant parts into something the model can apply consistently. "Primary analytical inputs are: xPoints divergence from actual points over the last eight matches, referee assignment and documented tendencies, squad depth relative to fixture congestion, and any publicly available information about player availability. Secondary inputs include PPDA trends over rolling five-match windows and set piece specialist availability. Correct score markets, first scorer props, and accumulator-adjacent markets are out of scope."

Constraints and filters. What you don't do, and why the model shouldn't suggest it. This is the part most people omit entirely and it's the part that stops the model being helpfully generic in ways that waste your time. "Do not suggest match result bets in markets with three-way lines unless there is a specific and unusual situational factor. Do not suggest bets in competitions outside the defined scope without explicitly flagging that this is outside normal coverage. When flagging potential opportunities, always note the account management implication - whether this type of bet is likely to attract scrutiny at soft operators."

Output format. How you want information delivered. "Structure analysis as: signal identified, mechanism explaining why it affects the market, market implication with specific bet type, confidence level on a three-point scale (marginal, moderate, strong), and any flags or caveats. Keep each analysis to a paragraph per point. Do not provide general background on teams or competitions unless specifically asked - assume I know the context and want the analysis."

That four-component structure is the architecture. What it does, specifically, is collapse the gap between a generic response and a response that's actually useful for your decision-making. The model isn't smarter with the system prompt. It's oriented correctly.

The Context Document: What It Contains and How to Use It

The system prompt sets the framework. The context document provides the specific knowledge that makes the framework operational.

The context document is a text file you paste into a conversation at the start of a research session. It contains your current working knowledge - the things the model needs to know to give you useful analysis right now, not in general.

It has three sections.

Current competition state. A brief status update on the competitions you're tracking - which teams are in form, which have unusual squad situations, which have referee assignments that are already known for upcoming fixtures. This doesn't need to be comprehensive. It needs to cover the things that affect your current analytical focus. Two or three paragraphs.

Active positions and constraints. Any bets already placed that affect what you're looking for - if you've already got a position on a team's next three matches, the model needs to know that before suggesting more exposure to the same side. Any operator-specific constraints active right now - if you've had a stake reduction at a specific book this week, that changes the value calculation for certain market types. A short paragraph.

Specific questions for this session. What you're actually trying to answer today. This sounds obvious but explicitly stating the session's purpose stops conversations drifting into general discussion that doesn't produce decisions.

The context document gets updated between sessions. It's not a static file - it's a living summary of your current analytical state. The update takes ten minutes. You add what's changed, remove what's no longer relevant, and carry the updated version into the next session.

The Prompting Architecture That Produces Useful Outputs

With the system prompt and context document in place, the individual prompts within a session become much simpler. Because the model knows your framework, you don't need to explain it every time. You're giving it specific inputs and asking for framework-consistent analysis.

The prompts that work follow a pattern: provide information, specify the analytical lens, request a specific output format.

"Here is the Tuesday press conference transcript for [manager]. Apply the injury language filter we use. Flag any player availability signals against the availability status I noted in the context document. Output format: player name, language used, availability category, confidence level."

"Here is the fixture list for this weekend within our scope. Cross-reference against the referee assignment data I've pasted below. Flag any fixtures where the assigned referee's documented tendencies produce a meaningful deviation from the market's implied card or foul rate. Output format: fixture, referee, relevant tendency, market implication, confidence level."

"I've pasted the rolling xPoints table for the Championship. Identify fixtures this weekend where both teams show significant xPoints divergence from actual points, in opposite directions, suggesting a strong quality signal for one side. Output format: fixture, divergence summary, direction of signal, implied market."

Notice what these prompts don't contain. They don't explain what xPoints is. They don't explain why referee tendencies matter. They don't explain what you mean by an injury language filter. The system prompt has already established all of that. The individual prompt can focus entirely on the specific task.

This is the difference between the architecture that produces useful outputs and the one that produces generic ones. Generic prompts produce generic answers because the model is filling in its own assumptions about what you want. Specific prompts within a defined framework produce specific answers because the model knows your assumptions already.

Persistent Context Across Sessions

Here's the honest limitation. LLMs don't retain memory between separate conversations. Each new session starts from zero regardless of what you covered last time. The system prompt and context document are your solution to this - they're the portable memory you carry from session to session.

The practical implication is that maintaining the context document is not optional. If you skip the update before a session, you're working with a model that has your framework but not your current state. It'll give you framework-consistent analysis based on outdated information, which is worse than useless because it looks right.

The update discipline is the hardest part of this workflow to maintain. It requires five to ten minutes at the end of each session - updating the context document with anything that changed, anything you decided, anything that should be carried forward. Treat it like closing your position records. If you wouldn't skip updating your CLV tracker, don't skip updating the context document.

For Claude specifically, the Projects feature allows you to attach a persistent system prompt and documents that load automatically into every new conversation within the project. This removes the manual step of pasting the context document each time. If you're using Claude, set up a project for your betting research and attach both the system prompt and context document there. The context document still needs updating, but the loading is automatic.

Calibrating the Model to Your Analytical Voice

After a few weeks of using the assistant regularly, you'll notice something. The model develops a consistent analytical voice across your sessions because the system prompt creates consistent framing. But it also reveals gaps - places where your framework as you've articulated it doesn't quite match your framework as you actually apply it.

When this happens, update the system prompt. If you find yourself repeatedly correcting the model's output in the same way - "no, I don't bet this market type even when the signal is strong" or "the confidence threshold for this competition needs to be higher than you're applying" - that correction belongs in the system prompt, not in individual session prompts.

The system prompt is a working document. Treat it like a staking plan that you review and update as you learn what works - not as a fixed instruction set you write once and never revisit.

The calibration process also surfaces something useful about your own analytical consistency. If you're correcting the model in ways that contradict each other across different sessions, that's not a model problem. That's your framework being less systematic than you thought it was. The model is a mirror as much as a tool. What it reflects back is sometimes uncomfortable.

What the Assistant Doesn't Replace

The data. The model doesn't have current match results, current injury lists, current referee assignments, or current odds. You provide all of that. The assistant analyses what you give it through your framework - it doesn't go and find the information independently.

The judgement calls on genuinely novel situations. Your framework was built from your historical experience. When a fixture presents a combination of factors that sits outside your documented edge patterns, the model will apply your framework to it and produce an answer, but the answer is extrapolating from your framework into territory it wasn't specifically designed for. That's where your own judgement still has to carry more weight.

The account management decisions. You can describe your account management constraints in the system prompt and the model will flag implications, but it doesn't know your specific operator relationships at the level of detail that actually matters for stake sizing and market selection. The system prompt can get you close but not all the way.

Anyway. The architecture is the bit most people skip because setting up a system prompt feels like overhead before you can start doing actual analysis. It isn't overhead. It's the thing that makes the actual analysis worth doing. Thirty minutes of setup produces a tool that thinks about your betting the way you think about your betting, not the way a generic AI thinks about betting in general.

That difference is significant enough that once you've worked with a properly configured assistant for a few weeks, working without one feels like starting every session by explaining who you are to someone who's never met you.

FAQ

Q: How long should the system prompt be?

Long enough to cover the four components properly, short enough that you're not padding. In practice, four hundred to six hundred words covers most analytical frameworks adequately. Beyond eight hundred words you're typically including things the model doesn't need to apply consistently, which creates noise rather than signal. The test is whether every sentence in the prompt is doing work - if a sentence restates something already covered or adds a constraint you'd never actually enforce, remove it.

Q: What happens when the model applies my framework incorrectly?

Correct it explicitly within the session, then decide whether the correction reveals a gap in your system prompt. "That's not how I apply the xPoints signal - the threshold for acting on a divergence is five points over eight matches, not three points over five" is a correction that belongs in the system prompt if you find yourself making it repeatedly. One-off misapplications can be corrected in the conversation. Recurring ones indicate the framework isn't articulated precisely enough in the prompt.

Q: Should I use one assistant for everything or separate assistants for different purposes?

Separate configurations work better once your workflow is established. A research assistant with a full analytical framework, a press conference assistant configured specifically for transcript analysis, and a CLV tracking assistant configured to analyse your bet log are three genuinely different tools that benefit from different system prompts. The research assistant needs your full framework. The press conference assistant needs only the injury language filter logic and the baseline profiles. The CLV assistant needs your competition scope and your market type categorisation. Mixing all of that into one system prompt produces a prompt that's too long and too diffuse to apply consistently. Set up separate projects for separate purposes and keep the configurations focused.