The Prompt Engine That Runs Sanju Samson

My love for Sanju Samson is not a secret. It is embarrassingly plain. I dread and sweat buckets when he is mid-twenties and I switch off when he gets out. His mastery in hitting short balls out of the boundary and directly into the hands of the fielder keeps every ball interesting to watch. But watching him bat against the West Indies was like watching all things coming together. Performance meets potential. The true Kerala Story.

Which got me thinking. What would it take to design a prompt configuration that runs Samson? Which got me to this piece.

Sanju Samson's skill, muscle memory, and talent are all beyond the scope of this article. However Sanju's identity, his decision making and the brain which orchestrates everything is very much fair game.

The Architecture

Any prompt configuration that takes inputs and produces outputs has three parts. There is identity: stable configuration that does not change between runs. There is context: dynamic state that gets passed alongside identity, different every time. And there is routing: the orchestration layer that decides what context to pass and when.

Put another way: output = f(identity, context(state, time)). The identity is fixed. The context is a function of what is happening and when. The routing is the f.

For Samson, identity is the system prompt. Context is the match situation. Routing is the brain.

We will keep variables simple. Let's assume one system prompt is enough. What changes is what gets passed alongside it, and when.

You are Sanju Samson. Right-hand batsman, wicketkeeper.
Your objective is to maximise your team's probability of winning.
You time the ball exceptionally. You have fast hands, strong wrists,
and 360-degree range.

That is the system prompt. Short. Does not change between matches. Does not need to know the target, the phase, the bowler. All of that comes later, from context.

But a system prompt alone does not produce the right shot. What matters just as much is what gets loaded alongside it, and in what order. In any prompt system, the sequence in which inputs arrive determines their weight. Inputs that persist carry background influence. Inputs that arrive last carry the most authority. The system prompt sets the floor. The most recent signal calls the shot. This is why the loading order matters.

The Loading Order

In any system, not all inputs arrive at the same time. Some are permanent. Some last a session. Some last a single request. Some exist for a fraction of a second. The shorter the lifespan, the higher the priority. A config file does not override what the user just typed. The most recent data is the most relevant.

Samson's system works the same way. The system prompt is always there. The innings situation lasts twenty overs. The bowler context lasts six balls. The ball in the air lasts less than half a second. And the ball in the air decides the shot.

These inputs split into two categories. There is macro context — the innings-level state. Mode, position, phase, required rate, wickets in hand. It loads once at the start and only updates when something significant happens: a wicket falls, the phase changes, the rate spikes. It is the strategic layer. It tells the system what kind of innings this is.

Then there is micro context — everything that is immediate and temporary. The bowler's type, the field, the patterns observed this over. The stance, the trigger, the preparation for this specific ball. And finally, the ball itself — length, line, pace, movement, trajectory — classified in a fraction of a second and gone after the shot is played. Micro context is tactical. It tells the system what to do right now.

The load sequence runs from permanent to momentary:

LOAD SEQUENCE:

T0 ─── SYSTEM PROMPT
        loads once, never changes
        identity + capability
        │
T1 ─── MACRO CONTEXT
        loads at innings start
        mode, position, phase, required rate, wickets
        │
        │   sits in the window for the entire innings
        │   updated ONLY on events (wicket, phase change, rate spike)
        │
T2 ─── MICRO CONTEXT: PRE-OVER
        loads once per over
        bowler type, patterns, field
        │
        │   persists for 6 balls then gets replaced
        │
T3 ─── MICRO CONTEXT: PRE-DELIVERY
        loads per ball
        stance, trigger, preparation
        │
        │   overwritten every ball
        │
T4 ─── MICRO CONTEXT: POST-RELEASE
        loads 0.4 seconds after the ball leaves the hand
        five classification variables: length, line, pace, movement, trajectory
        │
        │   highest priority, shortest lifespan
        │   gone after the shot

The system prompt is permanent. The macro context survives the whole innings but gets patched when events fire. Pre-over micro context lasts six balls. Pre-delivery lasts one ball. Post-release classification exists for less than half a second.

The shorter the lifespan, the higher the weight. The system prompt is always there but it does not pick the shot. The ball in the air does.

When Layers Disagree

Layers will conflict. That is the normal state of the system on most deliveries.

MACRO says:    phase = POWERPLAY  →  attack
MICRO says:    bowler = fast, new ball, slips in  →  caution
BALL says:     full, on pads, no movement  →  hittable

Three layers. Three different instructions.

In a deterministic system, conflicts are simple. You write priority queues, explicit rules, if-else chains. The system always knows which layer wins. Every run produces the same result.

Prompts do not work that way. All layers coexist in context simultaneously. The model weighs them implicitly. There is no guaranteed resolution order. The same conflict can produce different outputs on different runs. That is the nature of the thing.

But the system still has tendencies. The resolution leans a certain way, most of the time:

RESOLUTION RULES:

1. Ball data overrides micro context
   (what the ball IS beats what you expected)

2. Micro context overrides macro context
   (the immediate situation beats the innings plan)

3. Macro context overrides system prompt
   (the match situation beats general identity)

4. System prompt is the tiebreaker
   (when everything else is neutral, identity decides)

Most of the time ball data wins. Bad form is this going wrong. Not wrong inputs. Wrong weights. The ball says hit but an old constraint is still loaded from three overs ago, overriding everything. Stale data and wrong inputs leading to less than ideal outcomes. Or maybe it's just a short ball that begged to be hit to the fielder.

The Prompts, Plain

Strip the pseudocode. Here is what the system runs on.

System Macro Context — loaded at innings start, updated on interrupts Micro Context — loaded per over, updated per ball Per-delivery — loaded 0.4 seconds after release

One system prompt. Four layers of context loading at different speeds. A set of resolution rules that are really just tendencies.

In Kolkata, against the West Indies, the engine ran clean. He reached his 50 and took guard again. Wickets fell around him and he played singles. The prompt said attack. He chose to survive. Then the constraint cleared and he opened up.

Ninety-seven not out. Game won. Come on Sanju. The prompt that will win us the World Cup.