Half of Claude's Intelligence Comes from System Prompts

A Discussion About "How Autonomous Models Really Are"

Recently, a discussion on Hacker News about "Claude System Prompts" garnered 662 upvotes and 256 comments. On the surface, this seemed like another routine exchange about prompt techniques, but what truly sparked heated debate was a more fundamental and easily overlooked question: How much of the Claude we see is actually pre-defined behavior?

When we marvel at Claude's caution, structure, and sense of boundaries when answering questions, we instinctively attribute these behaviors to "the model being smart." But this discussion brought the real question to the forefront—to what extent do the model's system constraints, tool rules, and behavioral boundaries shape its performance?

This topic matters because it touches the core logic of current large model applications: The "intelligence" users see is the product of the model's foundational capabilities layered with external rules, not the model's pure capabilities alone.

System Prompts: A Continuously Running Behavioral Operating System

The discussion began with the most easily overlooked layer—the system prompt.

Many people's understanding of system prompts remains stuck at "a temporary instruction entered by the user." But in reality, system prompts are more like a continuously running behavioral operating system. They take effect before the conversation begins and persist throughout the entire interaction.

From a technical implementation perspective, the system prompt is an independent message role (role: system) in large language model API calls. Together with user messages (role: user) and assistant replies (role: assistant), it forms the complete conversation structure. During each inference, the system prompt is placed at the front of the conversation context, and the model references it as the highest-priority instruction when generating replies. This is fundamentally different from prompts users casually input—user prompts are single-task instructions, while system prompts are persistent constraints spanning the entire session lifecycle. Major model providers like OpenAI, Anthropic, and Google all support this mechanism at the API level, though implementation details and priority handling vary slightly among providers.

It defines several key things:

• What role the model plays
• What format to use to organize answers
• Which things require extra caution
• Under what conditions it must stop

From this perspective, the message users input is actually just "a task after entering this set of rules." In other words, the same model, once given a different layer of system constraints, may change its tone, structure, and boundaries accordingly.

This explains a common phenomenon: why different products integrating the same underlying model present vastly different "personalities." The difference often isn't in the model itself, but in that invisible layer of system prompts.

Tool Rules: The Key to Actually Changing Model "Actions"

If system prompts determine how the model "speaks," then what truly changes how the model "acts" are tool rules.

When Claude has the ability to read files, search information, and call external tools, the role of system prompts extends beyond the expression level to the action level.

The technical foundation for these capabilities is the Function Calling mechanism. Since OpenAI first introduced this capability in the GPT series in 2023, mainstream large model providers have followed suit. The core principle is: developers define available tools' names, function descriptions, parameter types, and constraints in JSON Schema format during API calls. The model judges whether to call a tool during reasoning and generates a structured call request. Critically, the model itself doesn't directly execute tool operations but outputs a call intent, with external systems responsible for actual execution and returning results to the model. This means the wording of tool descriptions and the strictness of parameter constraints directly affect the model's calling decisions—the more precise the description, the more predictable the model's behavior.

Specifically, tool rules can:

• Require the model to confirm parameters before calling tools
• Mandate that high-risk actions must stop and request human approval
• Define tool descriptions, input formats, failure handling, and result return methods

These rules become important references for the model's next judgment. In other words, the descriptions and constraints of tools themselves guide the model's behavioral path.

This point is particularly critical for understanding current AI Agents. AI Agents are one of the hottest directions in large model applications today, referring to AI systems that can autonomously perceive environments, formulate plans, call tools, and iteratively execute tasks. Unlike traditional single-turn Q&A, Agents emphasize multi-step reasoning and autonomous decision-making. Typical Agent architectures include paradigms like ReAct (Reasoning + Acting) and Plan-and-Execute, which rely on a core loop: the model observes the current state → thinks about the next step → calls tools → gets results → thinks again. What we often call "Agent behavior" is, in many cases, not an independently emergent capability of the model, but the result of the model's capabilities combined with tool rules. Many seemingly intelligent Agent behaviors are actually achieved through carefully designed prompt chains and tool constraints, rather than the model truly possessing fully autonomous planning capabilities.

Why Does the Same Request Trigger Different Actions?

A very enlightening example in the discussion nicely illustrates how system rules influence model behavior.

Imagine a user saying: "Send out all these files."

Facing this identical request, different systems might behave worlds apart:

• A system focused only on task completion might directly start operating and send all files out in one go;
• A system that builds permissions and risks into system rules would first ask about scope, confirm recipients, or proactively stop and wait for confirmation before executing high-risk actions.

The key here is: The behavioral difference between the two doesn't necessarily come from the model becoming smarter or more cautious, but from how behavioral boundaries are defined at the system level.

This example actually touches on a core concept in AI safety—Alignment. Alignment operates at multiple levels: the bottom layer uses training methods like RLHF (Reinforcement Learning from Human Feedback) and Constitutional AI to internalize safe behaviors into model weights; the middle layer sets runtime behavioral norms through system prompts; the outermost layer constructs safety Guardrails through engineering measures like tool permissions and review filters. Anthropic particularly emphasizes a "defense in depth" strategy in Claude's development, not relying on a single safety mechanism but using multiple constraints across training, prompt, and system layers to reduce risks. This also explains why the same model's safety performance can vary dramatically across different products—not because the model changed, but because the thickness of outer protections differs.

The same model, placed in a "just get it done" framework, will behave recklessly; placed in a "assess risks first" framework, will behave maturely and steadily. The "intelligence" users actually experience is the capability after filtering and constraining through this rule system.

Practical Implications for Developers and Users

While this discussion used Claude as an entry point, the patterns it reveals have universal significance.

For product developers, this means designing system prompts and tool rules is no less important than choosing which underlying model to use. With the same model, good system design can make it safer, more controllable, and better aligned with business needs; poor design might cause a powerful model to take dangerous or out-of-control actions. In actual engineering practice, this has spawned an emerging professional direction—Prompt Engineering is no longer just "writing good prompts" but has evolved into system-level behavioral architecture design, encompassing an entire engineering methodology including layered prompt management, tool permission matrices, exception fallback strategies, and more.

For ordinary users, understanding this layer helps us view AI performance more rationally. When Claude behaves cautiously and thoughtfully, we should realize that behind this may be carefully designed behavioral constraints at work, not the model being "naturally benevolent." Conversely, when an AI product behaves recklessly, the problem may not lie with the model but with missing system rules. This awareness also helps users make wiser judgments when choosing AI tools—evaluating an AI product's quality can't just look at which large model it uses, but must also consider the product team's skill at the system design level.

Conclusion: The Duet of Capability and Rules

Returning to the initial question: Is Claude really smart?

The answer is—it does possess powerful foundational capabilities, but what we ultimately use is that portion of capability shaped by system prompts and tool rules. The model provides potential, while system rules determine how that potential is released, in what manner, and within what boundaries.

Understanding this point may be more important than learning any set of prompt techniques. Because it reveals the true structure of contemporary AI applications: The intelligence you see is the result of capability and rules playing together.

Key Takeaways