Runtime Intervention for LLMs: How Mentat Steers Agent Reasoning Without Fine-Tuning

Most production LLM control sits between two extremes: prompt engineering (brittle, context-dependent) and fine-tuning (expensive, slow iteration). Mentat, a YC F24 launch, introduces a third path: runtime intervention that modifies token probabilities mid-generation without retraining weights. For financial agents that need deterministic behavior and auditable reasoning, this matters.

The core claim is simple. You send a request to their API with steering rules, and the model adjusts its reasoning path in real time. No gradient descent. No dataset curation. No waiting for training runs.

How Runtime Steering Works

Traditional inference generates tokens by sampling from a probability distribution over the vocabulary. Runtime intervention modifies that distribution before sampling, based on rules you define.

The mechanics:

Your request includes a base prompt plus steering directives (e.g., “avoid financial jargon,” “prioritize conservative estimates”)
Mentat’s API intercepts the forward pass at specific transformer layers
Activation vectors are adjusted to bias the model toward or away from certain reasoning patterns
Token probabilities shift accordingly
The model generates text with the modified distribution

This is not prompt injection. The steering happens inside the model’s computation graph, not in the input text. You’re changing how the model thinks, not what it reads.

Key difference from fine-tuning:

Fine-tuning bakes behavior into weights through backpropagation. Runtime steering applies temporary adjustments per request. Weights stay frozen. Rules are ephemeral.

Latency and Throughput Trade-Offs

Every intervention adds compute. The question is how much.

Latency penalty sources:

Layer activation retrieval (forward pass must expose intermediate states)
Steering rule evaluation (pattern matching against activation vectors)
Modified probability distribution computation
Potential cache invalidation if KV caching assumes unmodified activations

Mentat has not published benchmarks, but similar techniques (representation engineering, activation steering) typically add 10-30% latency overhead per token. For multi-turn agent workflows with hundreds of tokens per turn, this compounds.

Scaling considerations:

Dimension	Standard Inference	Runtime Steering
Per-token latency	Baseline	+10-30%
Memory overhead	KV cache only	KV cache + activation buffers
Batch efficiency	High (shared compute)	Lower (per-request rules)
Horizontal scaling	Straightforward	Requires rule state management
Cold start penalty	Model load time	Model load + rule compilation

For financial agents running compliance checks or risk assessments, the latency cost may be acceptable if it eliminates the need for separate fine-tuned models per use case.

Versioning and Audit Trails

When steering rules live outside model weights, you need a different versioning strategy.

What changes between requests:

Steering rule definitions (which patterns to amplify or suppress)
Rule parameters (strength of intervention, layer targets)
Combination logic (how multiple rules interact)

Compliance implications for financial agents:

Reproducibility: You must log the exact rule set and version for each inference call
Auditability: Regulators may ask why the model gave a specific recommendation. “We applied steering rule v2.3.1” is not sufficient without explaining what that rule does
Drift detection: If rules change frequently, you need to track when behavior diverged from baseline
Rollback: Unlike fine-tuned models (where you version entire checkpoints), you version rule configurations separately from weights

Practical architecture:

import mentat_client

# Define steering rules with explicit versioning
steering_config = {
    "version": "2.3.1",
    "rules": [
        {
            "id": "conservative_estimates",
            "type": "bias_suppression",
            "target_layers": [12, 16, 20],
            "pattern": "optimistic_financial_projection",
            "strength": 0.7
        },
        {
            "id": "jargon_removal",
            "type": "vocabulary_constraint",
            "target_layers": [24, 28],
            "forbidden_tokens": ["synergy", "paradigm", "disruptive"],
            "strength": 0.9
        }
    ],
    "metadata": {
        "use_case": "client_facing_risk_report",
        "compliance_framework": "SEC_regulation_best_interest"
    }
}

# Log the full config before inference
audit_log.record(
    request_id=req_id,
    timestamp=now(),
    config=steering_config,
    input_hash=hash(prompt)
)

# Make the steered inference call
response = mentat_client.chat_completion(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    steering=steering_config
)

# Log the output with config reference
audit_log.record(
    request_id=req_id,
    output=response.content,
    config_version=steering_config["version"]
)

This gives you a paper trail: input, rules, output. If a regulator asks why the model avoided certain language or emphasized conservative estimates, you can point to the exact rule and its strength parameter.

When Steering Beats Fine-Tuning

Use runtime steering when:

You need different behavior per request (client A gets conservative language, client B gets technical depth)
Rules change faster than you can retrain (regulatory updates, policy shifts)
You want to test behavioral changes without committing to a new model checkpoint
Compute budget for fine-tuning is prohibitive
You need to explain why the model behaved a certain way (rules are more interpretable than weight deltas)

Stick with fine-tuning when:

Behavior is stable and applies to all requests
Latency is critical (every millisecond counts)
You need the model to internalize domain knowledge, not just suppress patterns
You have the infrastructure to manage model versioning and deployment

Avoid both when:

Prompt engineering with structured outputs is sufficient
You don’t actually need deterministic control (sampling diversity is fine)

Failure Modes

Coherence collapse:

If you steer too aggressively, the model may generate incoherent text. Suppressing financial jargon might force it into awkward circumlocutions. Biasing toward conservative estimates might make it refuse to answer legitimate questions.

Rule conflict:

Multiple steering rules can interfere. If one rule says “avoid technical terms” and another says “prioritize precision,” the model may oscillate or produce generic mush.

Invisible drift:

If you update steering rules without versioning, you lose the ability to reproduce past outputs. A client asks why last month’s report said X, and you can’t recreate the exact reasoning path.

Latency budget exhaustion:

In a multi-agent workflow with 10 turns and 200 tokens per turn, a 20% latency penalty per token adds up. Your agent loop may time out or miss SLA targets.

Technical Verdict

Use Mentat-style runtime steering when:

You operate financial agents that need different compliance postures per client or jurisdiction
You iterate on behavioral rules faster than weekly (fine-tuning cadence is too slow)
You need auditable, versioned explanations for why the model behaved a certain way
Latency penalty of 10-30% per token is acceptable for your use case

Avoid it when:

You need sub-100ms response times for high-frequency trading or real-time risk alerts
Your behavioral requirements are stable enough to bake into weights
You lack the infrastructure to version and log steering configurations rigorously
You’re building agents that need to internalize deep domain knowledge (steering adjusts reasoning, it doesn’t teach new facts)

Runtime intervention fills the gap between brittle prompts and expensive fine-tuning. For financial agents navigating shifting compliance rules and client-specific requirements, that gap is wide enough to matter.

Agentic AI, minus the noise.