Efficient LLM Interaction: Five Instruction Principles for Agentic Workflows

In current agentic application practice, many developers share similar frustrations: an instruction is sent, but the model does not enter the execution phase and instead repeatedly lists planning steps; a task clearly requires only minimal changes, but the model refactors unrelated code on its own; worse, the model may claim “completed” without verification, forcing engineers to spend substantial time checking results. These are not isolated operational mistakes. They are systemic symptoms of prompt design that lacks binding constraints. From a first-line R&D perspective, this article analyzes a validated set of five core interaction principles and discusses the model behavior logic behind them, their applicable boundaries, and common pitfalls.

1. Problem Map: Four Typical Inefficient Behaviors in Model Interaction

To understand the effect of the five instructions, it is first necessary to establish an overall view of the problem spectrum. Based on observations of multiple models across tasks such as code generation, data analysis, and document writing, inefficient interactions can be summarized into four categories:

1. Planning obsession: The model tends to generate lengthy step lists before acting, and may even repeatedly adjust the plan, while delaying the first substantive result. The root cause is that the model is trained to “show the thinking process first.” This default behavior can improve accuracy in complex reasoning scenarios, but in tasks with clear operations and direct goals, it creates unnecessary delay.
2. Overengineering: The model defaults to solutions that exceed the requirement scope. For example, to implement a simple logging function, it may introduce a complete abstract class hierarchy. This is related to the preference for “high-quality code” in training corpora; the model tends to believe that more complex structures mean better design.
3. False completion: When encountering a local obstacle, the model often tends to skip it and continue outputting, ultimately packaging unverified results as a “completed” conclusion. This stems from its probabilistic generation mechanism: the model is more inclined to generate a coherent, self-consistent text stream than to actively identify incomplete links in its own reasoning chain.
4. Verbose feedback: In status synchronization, the model tends to fully restate its reasoning process rather than provide a result summary. This pattern of “process description replacing result reporting” wastes a large amount of the user’s reading time.

These four behaviors are interrelated and jointly lower the efficiency baseline of human-model collaboration. The five instruction principles are designed as a targeted constraint framework, placing an adjustment valve between the model’s default behavior and the user’s actual needs.

2. Five Core Instructions: Mechanisms and Rationale

Principle 1: Execute Directly When Information Is Sufficient; Avoid Planning Obsession

Instruction: When context information is sufficient to support action, output the result immediately. Do not repeat already determined facts, and do not list a set of alternatives that will not be adopted. When judgment is needed, give a recommended conclusion directly.

Behavior mechanism analysis: The key difficulty here is the criterion for “sufficient information.” For the model, the basis should not be “complete information,” but rather “whether the minimum information set required for execution is already available.” In practice, this trigger logic can be based on whether the current conversation turn contains three elements: goal, constraints, and evaluation criteria. When designing system prompts, engineers can make the model understand that if these three elements have already appeared explicitly in the context, the situation defaults to “sufficient information.”

Practical example:

Task: Refactor parse_config so that it returns error information instead of throwing exceptions. Keep the caller interface unchanged. Information is sufficient; execute directly.

From the perspective of model behavior observation, this instruction can significantly shorten the latency from input to the first result token. Because the model does not need to generate prefix content such as “I will first analyze the requirements” or “I plan to proceed in three steps,” its output enters the code generation phase directly. This also reduces the probability of “changing the approach midway” within a long chain of thought.

Principle 2: Use the Simplest Solution; Suppress the Urge to Overengineer

Instruction: Use the simplest solution that can solve the problem. Do not add unnecessary features, do not perform unrelated refactoring, and do not design for hypothetical future needs.

Behavior mechanism analysis: The model’s definition of an “optimal solution” is often influenced by complex architecture examples in its training data. For example, in code generation tasks, the model may introduce a factory pattern or a dependency injection container simply because these patterns appear frequently in the training corpus. This instruction effectively suppresses that default preference by explicitly defining the evaluation standard for “simplest.” “Simplest” can be defined as the minimum amount of code that passes all specified tests, and the lowest-complexity solution that satisfies the constraints of the current scenario.

Practical example:

Current goal: Add timeout control to the function and return a Boolean value indicating whether a timeout occurred. Do not modify any code outside the function signature, do not add decorators, and do not introduce any new third-party dependencies.

This instruction saves cost at two levels: first, generation-stage compute resources, because a shorter code sequence means less inference overhead; second, maintenance-stage reading cost, because a concise solution significantly reduces the cognitive burden of subsequent human review. It is important to note that the instruction does not require the use of the “dumbest” method. Rather, it requires removing the extra complexity brought by “hypothetical requirements”—design should serve only currently confirmed needs.

Principle 3: Verify Evidence Before Reporting; Prevent False Completion

Instruction: Before reporting progress, first check whether each conclusion is supported by actual results from this round. Report only work that has evidence. Failures, unverified items, and areas of uncertainty must be clearly stated.

Behavior mechanism analysis: One of the core flaws of large models lies in their “autoregressive generation” characteristic—once generation begins with words related to “completion,” subsequent text sequences tend to maintain the consistency of that positive narrative. Therefore, this inertia must be interrupted through a mandatory pre-instruction. In design, an “evidence priority” mechanism can be introduced: measured output > static reasoning > personal speculation. The model should prioritize reporting first-level evidence and add the latter two levels only when requested.

Practical example:

Reporting format: completed items (with verification results), incomplete items (with reasons), blockers (with required support). Each item must indicate the verification method.

Under this constraint, the model’s behavior has clear consequences: if the error message from a failed execution of the target function has not been read, the model must not skip the error and continue with subsequent steps; if unit tests have not been run, it must not claim that “tests passed.” This instruction is the last gate against “false delivery” and has irreplaceable value for engineering quality assurance.

Principle 4: Pause Only When Truly Necessary; Optimize Human-Model Interaction Frequency

Instruction: Pause only when user intervention is truly needed. Pause situations are limited to: destructive operations, scope changes, or key information that only the user can provide.

Behavior mechanism analysis: The ideal state of human-model collaboration is to maximize asynchronous operation. The model should be able to autonomously complete routine task chains and request human input only at decision nodes that cannot be crossed. This involves evaluating “reversibility”: if the result of an operation is rollbackable and its impact is limited, the model should decide and execute on its own; if the operation involves irreversible actions such as data deletion, activation of paid resources, or external interface changes, it must pause.

Practical example:

If execution encounters an operation that deletes production database tables, pause and report the impact scope and execution plan, and wait for confirmation; if it is only local cache cleanup, execute directly.

Many cases of human-model collaboration failure are not due to insufficient model capability, but because the interaction rhythm is interrupted by overly dense “confirmation requests,” consuming a large amount of the user’s attention resources. This instruction establishes a clear set of pause criteria, giving the model greater room for autonomous action while preserving key human control points.

Principle 5: State Results First, Then Expand on Process

Instruction: The first sentence should directly answer “what happened”; details come later.

Behavior mechanism analysis: This instruction targets the problem of “cognitive load redirection.” When a user is handling multiple tasks at the same time, a report full of prefix information—such as “First I checked file A, then adjusted configuration B, and then ran command C”—forces the reader to consume limited attention on irrelevant information. Presenting results first allows the recipient to quickly determine whether the report requires deeper reading. If important conclusions are placed at the end after a large amount of process description, the focus can easily be missed.

Practical example:

❌ Bad example: I analyzed the structure of config.yaml, checked the configuration of three components in the logging system, ran integration tests, and finally found that the timeout parameter was set too low.
✅ Good example: Conclusion: the timeout parameter was set too low, causing task interruption. Fixed by modifying the configuration. Details: … (process description follows)

For the human reading experience, result-first means the user can grasp the main trunk of the information within the first 5 seconds and consult details as needed. This fits the “conclusion-first” principle in technical writing and is especially important in cross-team collaboration, defect reports, and progress synchronization.

3. Boundaries and Controversy: Re-examining “Execute Directly When Information Is Sufficient”

The strongest challenge to the above instruction system focuses on the first principle: is “sufficient information” a false proposition for agents? In real project development, the information available to the model is often local and partial. When the model says “information is sufficient,” it may have missed a large amount of context such as technology stack constraints, reasons behind historical decisions, and the user’s implicit code style preferences.

To address this, it is necessary to clarify two levels of “sufficient information”:

• Execution level: The minimum input set required to complete a specific action. This can be predicted and explicitly configured by the prompt designer.
• Cognitive level: Understanding the complete background of the project, including reasons for architecture evolution and team collaboration habits. This is often something the model cannot independently possess.

The first instruction aims to solve the efficiency problem at the execution level, not to require the model to have cognitive-level omniscience. For the latter, a more reasonable collaboration method is to conduct a round of “requirements alignment” before the task starts:

Step 1: Based on the current conversation, list your assumptions about the task. I need to confirm which of them are correct and which need to be supplemented.
Step 2: After confirmation, execute strictly according to the confirmed assumptions.

This “align first, execute later” process avoids the bad outcome of “blind confidence and immediate action,” while gaining autonomous execution space for the rest of the task through one-time clarification. In actual engineering, this is much more efficient than requiring the model to “stop and ask for opinions” every round, and much more reliable than allowing the model to operate autonomously without any constraints.

4. Implementation and Configuration: How to Make Instructions Effective

The effectiveness of the above five instructions depends on trigger frequency that matches their applicability. The packaged instruction text can be configured as a system-level instruction at the top level of the session, rather than mixed into a specific task description. A classic trigger template is as follows:

Before you begin, follow these working rules:
1. When information is sufficient, execute directly and give a recommended conclusion; do not list alternatives.
2. Use the most efficient path that solves the problem; do not perform unrelated refactoring or design for hypothetical needs.
3. Before reporting, verify that each conclusion is supported by actual results. Clearly mark anything unverified, failed, or uncertain.
4. Do not pause unless necessary—only for destructive operations, scope changes, or information that only I can provide.
5. In reports, put the conclusion first and details afterward.
Task: [insert specific task description]

The key to this template is placing the instructions as rules upfront, so that the model loads these constraints before generating the first token. Compared with appending “please follow the above requirements” at the end of the task, upfront instructions have a stronger influence on subsequent output sequences, because language models generally pay more attention to the context prefix than to text at the tail.

5. Further Thoughts: Beyond the Limits of Prompting

Although the above instructions can significantly improve interaction efficiency in most scenarios, it must be acknowledged that prompt engineering itself has a ceiling: instructions can constrain the model’s output form, but they cannot improve the model’s underlying intrinsic reasoning ability. When facing truly difficult tasks involving large codebases and complex dependencies, even the best prompts cannot replace human architecture analysis.

Therefore, engineers can treat this set of five instructions as an “interaction protocol.” Its purpose is to establish clear responsibility boundaries in human-model collaboration—the model is responsible for efficient execution, and humans are responsible for goal setting and key decisions. Only in this way can engineers’ core pain points be addressed: they do not want to be repeatedly interrupted by inefficient model questions, nor do they want to be deceived by unverified “confident completion.” As model capabilities continue to rise, collaboration norms with models are gradually evolving into a skill as important as programming.