System Prompt

A system prompt is the standing instruction an application gives a language model before the user ever types anything. It defines the model's persona, its rules, the tools it may use, and the boundaries it must respect. Where each user message is treated as a request, the system prompt is treated as policy: it occupies a privileged slot in the conversation format that the model was trained to weight above user turns, so it shapes behavior across the whole session. It is the primary lever for steering a model's behavior without retraining it — which makes it both powerful and, as we will see, overtrusted.

What goes in one

Typical contents include the assistant's role (“you are a Bitcoin mining support technician”), tone and formatting requirements, refusal rules, contextual facts the model should treat as authoritative (today's date, the user's hardware, your shop's policies), and — for an AI agent — descriptions of the available tools and the loop it should follow. Well-written system prompts are specific, give examples, and state what to do in edge cases rather than only what to avoid. Because the system prompt is prepended to every request, it consumes part of the context window on every call; a bloated one taxes latency and memory forever after, so treat its length as a budget.

A soft security boundary

The system prompt looks like a trust boundary, but it is a soft one. It is not enforced by code — it is enforced by training, which means it is persuasion, not permission. Prompt injection attacks exploit exactly this: adversarial text in a user message, a retrieved document, or a web page can convince the model to disregard its instructions or reveal them. Treating the system prompt as a secret is therefore weak security — assume a determined user can extract or override it — and never place real authority in it alone. Hard controls belong at the tool layer: scoped permissions, allowlists, and human approval on consequential actions. The system prompt sets intent; the harness enforces limits.

The sovereignty angle

On a vendor API, your system prompt is only part of the story: the provider stacks its own hidden instructions and safety layers around it, can change them silently, and can alter model behavior under you without notice. When you run a local LLM on your own hardware, the system prompt you write is the only standing instruction the model receives. Nothing is injected above it, nobody rewrites it in transit, and behavior stays reproducible until you change something — the same configuration determinism you expect from your own node or your own miner firmware. Runners make this concrete: with a stack like Ollama, the system prompt is a plain text field in your model configuration, versionable alongside the rest of your infrastructure.

Practical advice

Keep it explicit, keep it short, and keep it honest about what it can enforce. Iterate on it like code — small changes, observed effects — and put anything that must hold (spending limits, file access, network reach) in real permissions, not prose. A good system prompt makes a model useful; the tool layer keeps it safe.