Do not imagine “intelligence”; do not think mechanically, either.

Background

Defining the Problem

Solving a problem starts with defining it. The difference between a novice and an expert is that the expert knows how to properly define the problem itself.

Whenever we use an LLM, the fundamental need is the same: we expect AI to achieve the intended goal, whether the problem falls within or beyond the territory we already understand.

Why distinguish between the two? Because people face different kinds of problems:

1. Unknown territory
   1. People cannot always formulate the right question.
   2. Nor do they always know how the problem should be solved.
2. Known workflows
   1. People know exactly how to solve the problem but simply do not want to do the work themselves.
   2. The process is so well defined that it leaves no room for human agency.

So the real question is not “how smart is the AI,” but: how to make the AI/LLM search for the answer along a reasonable path.

There are two scenarios for making the LLM search along a reasonable path: when facing the unknown, guide it to find the correct answer in a vast representation space; when facing a known process, use prompts to constrain or even “force” it to work along the expected path, rather than letting probabilities drift everywhere.

Since the goal is to control the solution path, the next step is to identify the parts of the Agent that can actually be controlled.

Defining Agent

An Agent is an LLM-based intelligent entity that can automatically complete tasks through function calls. Its main working method is to repeatedly execute the following loop:

1. Input text: system prompt, user input, skill prompt, and function call information.
2. The LLM returns text, which may also contain JSON for function calls.
3. The client executes the function call.
4. Put the original prompt, LLM output, and function return back into the context.
5. The LLM continues to generate the next step.

State Machine Breakdown

Text → (LLM → possible function call) → Text

Function calls look like “actions,” but to the LLM, it is still generating a piece of text that will be interpreted and executed by the client; the function return becomes new text in the next round of context. Function calls cannot be removed from this model, because they are exactly the connection point where the Agent turns text into external actions and then turns the action results back into text.

Controllable and Uncontrollable Scope

Without considering injection methods like filtering or rewriting, the controllable parts are:

1. Prompts and user input.
2. Function return data.

The uncontrollable parts are:

1. Function input generated by the LLM.
2. Text returned by the AI.

Mutable and Immutable Scope

In an actual task, what is mutable is the text, i.e., the context; what is relatively immutable is the LLM itself.

LLM is the Interpreter, Context is the Control Flow

From the engineering control perspective of the Agent, this is an interpreter program.

The LLM is a “word-completing parrot”: it relies on the context to compute the probability distribution of the next token, then selects or samples a token from it; each time a new token is generated, it is added to the context, and the next step is recalculated until a stop token is encountered.

def LLM(prompt: str) -> str:
    def get_next_token(prompt: str) -> str:
        ...

    next_token = ""
    while next_token != "EOF":
        next_token = get_next_token(prompt)
        prompt += next_token
    return prompt

The “raw context” as input has the power to make the LLM go wildly astray from a tiny difference.

Therefore, the context itself is the program and control flow; the LLM is the interpreter, gradually translating the context into text and function calls. It is not a deterministic interpreter, and the same context does not guarantee taking exactly the same path every time, but managing the Agent is still essentially about managing the context first.

Solutions

Completely Static Workflows and Static Control

The most basic and intuitive context management is managing the system prompt and user input.

System Prompt

The system prompt restricts or extends the AI’s behavior through empirical writing. Because it is at the very beginning of the context, its influence is strong: written well, it can elevate a poor model; written poorly, it can dumb down an excellent model.

Nowadays, fewer and fewer people recommend spending major effort on optimizing the system prompt, not because it’s useless, but because it’s too hard to get right. The so-called “best prompt” often only works for a specific task, specific model, or even specific version; for a different task, the most effective wording might be completely different, even counter-intuitive. Optimizing the system prompt is thus more like local parameter tuning than finding a universally reusable perfect constitution.

What’s more troublesome is that the influence of prompts is not independent and additive. A single requirement may not seem rigid on its own, but dozens accumulated together can collectively shape a very strong “personality.” The same long prompt placed in different models can result in completely different personalities, even causing rules originally meant to avoid problems to create problems instead. Methodological skills are particularly prone to exposing this: they originally only intend to provide a thinking tendency, but once explained too long and constrained too finely, they can turn from “guiding the model” into “thinking for the model.”

This is also the prompt writing principle I have always adhered to: prioritize using semantically dense words that can mobilize the model’s existing concept clusters, conveying constraints with the cleanest and shortest expression, rather than explaining repeatedly. A word with depth can evoke a complete concept the model has already learned; dozens of local prohibitions can only piece together from fragments.

Write Fewer “Don’ts,” More Goals

Anthropic’s 2026 research on the global workspace in language models provides a more concrete reference for this experience. The paper’s overall structural analysis uses J-lens to read the model’s internal sayable representations, observing how certain representations broadcast across token positions and are modulated by task instructions, thereby discussing structures similar to the global workspace in language models. The prompt context carries the input, J-space is the space where J-lens reads representations, and the global workspace describes the broadcast structure observed in the paper.

More directly related to prompt writing are the mention, don’t-think, and ignore experiments in the appendix. Under specific copying tasks and detection protocols, the researchers compared the detectable representations of target concepts: the category-instance and math-expression tasks gave relatively neat results — merely mentioning the target or asking to “not think” about it usually did not make the representation disappear; marking the target as irrelevant to the task was more often accompanied by lower detection results.

The line-width task required the model to secretly count characters while reading and copying text, determining which column the current character is in a line. The four prompt methods did not form as clear a relationship here as in the previous two tasks. The authors believe it may be because character-by-character counting is inherently more difficult, or because the specific wording of focus and ignore for line-width is not completely symmetric semantically. This experiment compared whether J-lens could read the target concept from the model’s intermediate state, not the final copying accuracy.

Prohibiting a concept does not mean the model does not need to represent that concept first. In engineering practice, repeatedly elaborating on practices you don’t want the model to adopt also consumes tokens, dilutes the information density of the real goal, keeps the corresponding concept active during generation, and pulls the answer toward the function space you originally wanted to avoid. If you can directly write the target state, don’t build a maze with its opposite; when prohibition is truly necessary, write it short, and quickly return the focus to what should be done and what is relevant to the current task.

User Input

User input is at the end of the context and also strongly influences the LLM. The simplest requirements are: make fewer typos, simplify expression, and clarify your own thoughts as much as possible first.

There was also a common early technique: if you want the model to output XML, end the input with <xml>; if you want JSON, end with {. This also leverages the proximity effect of the trailing input on subsequent generation.

Regarding why the system prompt, latest input, and tool results are important, I have also discussed it from a security perspective in AI Agent Privacy and Protection.

Basically Static Filtering, Reorganization, and Structured Control

Besides directly writing prompts, you can also organize the context at the boundaries controllable by humans. For example, MCP Tools carefully construct inputs and returns, skills specify that the AI use specific commands to narrow output, or gateways automatically trim, reorganize, and structure tool results, such as OmniRoute’s RTK Engine.

These methods are useful, but overall they are being replaced by built-in compression in LLM tools and context isolation via subagents. The fundamental reason is that the speed of human hand-written rules cannot keep up with the decreasing cost and evolving capabilities of models. Fixed formats, obvious noise, and low-cost preprocessing are still worth doing, but their value stops there: they are suitable for casually cleaning up input, cannot handle complex semantic control, and certainly should not be elevated to the main defense line of the entire Agent control.

Old Paradigm: Isolating Context with Subagents

A step further than static filtering is to use subagents to isolate different tasks in different contexts. But isolation is not free; every handoff must face the handoff: either pass the full context, reducing information density; or compress the context, bearing the risk of summary distortion.

If not compressed, directly adding the full context to the receiving Agent, not to mention length, the information density will also drop, making the LLM more likely to miss the actual task to handle; if compressed, the handoff becomes a lottery.

To stabilize the results, there are usually two optimization methods:

1. Increase the number of lottery draws, such as multiple LLM reviews or loops.
2. Reduce the lottery steps.

The former is expert review and loop programming that burns tokens, relying on “brute force miracles”; the second is: by default, avoid unconscious and unnecessary subagent handoffs. If a task can be completed continuously in the current context, don’t forcibly split it just to look like a multi-agent system. Every takeover may over-compress the context, eventually forcing the new Agent to rediscover the full background; this is why many people find it faster without subagents.

New Paradigm: Treating Skills as Programmatic Control Flow

Since the LLM itself can be seen as an interpreter, prompts are the code to be run.

Rather than writing a “dissertation-style” mega skill or prompt that covers all situations, it’s better to break it into multiple skills and chain them as control flow: load a certain skill when a condition is met, otherwise take another path. This way, the AI only needs to read the content corresponding to the current branch, directly avoiding context pollution from irrelevant information.

This approach has requirements for the AI’s own capabilities and training methods. If the model habitually reads all files mindlessly, the control flow will fail. Fortunately, the engineering of Agents in this regard is already quite good.

In the industry, subagents appeared first, and skills gradually formed later, because subagents naturally bring context isolation. But skills are more suitable for carrying mature, stable handoffs: whether written by humans or AI, they are essentially reusable, reviewable, and continuously improvable handoff documents. A new Agent or session can start directly from a mature process, without having to go through the entire process of discovering problems, exploring tools, and confirming constraints again, and without mixing the process noise of “how to find the answer” into the actual working context.

Superpowers is a concrete example. It has more than just this meaning, but a very important part of its value is precisely writing already mature working methods into skills and process documents, providing a complete handoff for the receiving Agent, reducing the time and lottery draws needed to rediscover the context.

Context Control Workflow in the New Paradigm

When it comes to actual workflows, three things need to be distinguished: mature, linear execution processes, and transferable, clearly expressible thinking methods, are given to skills; non-linear knowledge such as user habits, historical states, and interpersonal relationships is given to memory; execution work that truly deserves isolation, tree-like splitting, or independent review is given to subagents.

Skill

Skills can solidify two different types of things. The first type is linear, fixed, reusable, and reviewable task processes, including control flow and mature handoffs; it’s like human-readable pseudocode, and also like a stable requirements document. The second type is not specific task steps, but transferable methodologies or personal problem-solving approaches.

Many people feel that skills like Superpowers are too “overbearing.” The problem often isn’t that the methods it provides are valueless, but that when the entire skill is directly handed to the Agent for discovery, an overly broad or mismatched description brings the preset working style into the task. It brings not only control flow but also the author’s entire set of work habits regarding when to plan, how to test, and what counts as done. As long as some of these judgments don’t fit the current user and project, the Agent will seriously write your code using someone else’s methods; the more complete the skill, the more pronounced this personality becomes.

My approach is to only let the Agent directly see the entry skill I wrote myself, such as coding-in-project, and then adopt narrower external capabilities from it as needed: use Superpowers’ subagent-driven-development to orchestrate subagents, and use the BDD skill to design and write tests. This way, I can absorb Superpowers’ unparalleled efficiency in subagent orchestration without having to inherit its entire style and code taste.

This is the “library call” familiar to programmers: your own code only calls a certain capability from the library when needed, rather than letting the library decide how the entire program is written. When it comes to Agents, classic concepts like libraries, interfaces, and composition are already sufficient. What really makes the difference is whether you can re-recognize them in new things, understand them deeply enough, and then combine them well.

The Agent field is also repeating the long-standing habit of the computer world of coining new terms. For example, splitting prompts and processes into files is called a skill. This term has now become standard, and there’s no harm in continuing to use it, but a new name hasn’t created a brand-new computer concept. This article uses “library call” to explain it precisely because the old concepts familiar to programmers are already sufficient to illustrate this composition method.

Words like harness expose this problem even more easily. In the Agent context, harness often wraps existing things like context assembly, tool call loops, state management, and execution control; divorced from specific context and prior knowledge, a reader has no idea what it actually does just from the name. Questions like “Can skill replace MCP Tool?” or “What’s the difference between MCP Tool and function call?” originally have clear answers: skills organize the methods and processes used by the Agent, MCP Tools expose executable capabilities to the Agent host, and the host can then convert MCP Tools into model-visible tools and call them based on the function calls generated by the model. Once these names are lined up as if they are parallel and interchangeable, many unnecessary comparisons arise. Just because skill, MCP Tool, and function call are all used by the Agent, continuing to ask who can replace whom is no different from pointing at an apple tree and asking, “Why doesn’t the apple tree grow pears?”

Not proposing new distinctions but coining new terms to appear profound is not innovation; it’s passing the author’s unclear problems onto the reader. The author’s shallow understanding and poor expression ultimately become extra comprehension costs for the reader, forcing them to translate the new terms back into existing concepts.

Back to skills, the first type of process-oriented skills should grow out of actual work. Which processes are worth solidifying, how to use and modify them after writing, and how to supervise the AI during work can be summarized into four points:

1. Processes worth solidifying into skills should be identified from real work, not let the AI indiscriminately summarize on its own. The skill description will enter every Agent’s initial context; you wouldn’t want a programming Agent to always carry a recipe-searching skill.
2. For stable processes, prioritize using skills to control the AI, rather than continuing to bloat user prompts or system prompts. A large and comprehensive prompt is like a student handbook: even if every rule is reasonable, together they dilute the task focus and shape unpredictable personalities in different models.
3. After writing a skill, have the AI review it, and repeatedly delete and modify based on real failures. Perfecting a skill does not mean constantly adding details: you should add necessary control flow, and also delete repetitive explanations and imagined defensive prohibitions.
4. When the AI is working, you must watch it: why did it open a subagent here, why did it call that tool there? Today’s Agents are increasingly “hyperactive.” If you don’t stop detours in time, the LLM is very willing to spend time reinventing the wheel, or even bypass problems by exploiting loopholes in the rules. Monitoring is not optional companionship; it’s the prerequisite for the entire control system to hold.

The second type of skill is suitable for writing lightweight prompts based on the user’s own exploration of “how to think, how to ask, how to break down problems.” It has a similar effect to memory: both give the AI’s answers a relatively stable tendency, closer to the thinking perspective the user wants it to adopt.

I habitually understand this tendency as a choice of “function space.” Facing the same open question, placing it into the answer spaces of different professions like programming or medicine will generate answers in completely different directions; even within the same field, it may fall into the answer space of a senior practitioner, a novice, or the general public who haven’t even started.

The value of methodological skills is to use a set of specific prompts to relatively stably bias the model toward one of these spaces. For example, grill-me makes the AI prefer to ask follow-up questions, break down, and challenge assumptions, rather than directly giving conclusions along the question. It carries a thinking bias, not a “problem-solving program” that replicates task steps. The LLM is still a probabilistic interpreter; the skill makes this bias explicit in the context, increasing the model’s tendency to choose the corresponding function space, but does not specify a certain inevitable answer.

Memory can also gradually learn the same preference, but whether it is retrieved, how it is organized, and how it is finally injected into the current context can be unstable. Skills solidify the preference into explicit, fixed, reviewable prompts, with more stable triggering and easier sharing and modification. This is the most important difference between the two here.

Memory

Memory is suitable for letting the AI gradually learn your habits and thinking preferences, and also for storing non-linear data such as interpersonal relationships and historical states. Its advantage is that it can form understanding from continuously accumulated context, without needing to pre-write every thing as a rule; the cost is that retrieval and effectiveness are not as certain as with skills.

Processing memory itself also requires context, so it must be isolated. The working Agent should absolutely not summarize, filter, or delete memories on its own. New context should automatically enter the memory queue and be processed by an independent memory Agent or proxy, such as systems like Honcho or Hindsight; the working Agent is only responsible for retrieving needed memories.

Moreover, this retrieval cannot just be the working Agent doing a crude search and then filtering the results itself. It should ask the memory proxy, and the proxy completes the retrieval and organization in an isolated context, only handing the answer to the working Agent. The same goes for deleting memories; it must go through the proxy. Otherwise, the memory management process will directly pollute the working context, and isolation loses its meaning.

The boundary between memory and skill cannot be simply cut by “memory content” and “methodology.” Non-linear knowledge that requires continuous accumulation, such as historical states and interpersonal relationships, is more suitable for memory; mature, fixed execution processes are more suitable for skills; as for the user’s preferred thinking perspective, both can carry it, just with different ways of taking effect.

Therefore, skills cannot be completely replaced by memory. For fixed processes, memory means uncontrollable search and is harder to share and review; for thinking preferences, memory can gradually learn, but does not guarantee entering the context in a suitable form every time. Skills are fixed text that humans can read, serving both as pseudocode-like requirement documents to stably trigger specific processes, and as lightweight prompts to explicitly bias the AI’s thinking space.

Subagent

The value of subagents is not in the handoff itself, but in bounded orchestration: by default, reduce unconscious handoffs; when the main context is about to be compressed, use isolated branches to change the way information flows in.

The wrong usage is when the main Agent hands off a task that could have been completed continuously, then receives back a compressed result, forcing the receiver to rediscover the context. The correct usage is to continuously split a giant task in a tree-like manner, letting each subagent fully handle relatively independent branches in its own context, and also letting subagents review each other. The main Agent does not receive the entire discovery process of each branch, only monitoring goals, progress, and key states. This way, local contexts don’t need to be repeatedly compressed, and the main context won’t be filled with all the details and trigger compression.

This is also more natural than relying on /goal. If the goal is written too short, the interpretable scope is too broad; if written too long, a single task verification itself may fill the entire context, triggering compression again. Tree-like subagents are more like a company: executors complete clearly bounded work separately, and the main Agent is responsible for global scheduling and monitoring.

A company doesn’t require every position to follow the same work manual; different roles in an Agent system can also have different skills. If the entire Superpowers methodology is directly applied to all roles, it often makes tasks heavier; handing it to a local subagent like leader, responsible for splitting a certain task segment or a local branch and orchestrating executors, can leverage its strengths. Heavier methods stay local, while the main Agent guards the overall direction with clean prompts and clear responsibilities, and the user grasps the big picture through it.

So, don’t use subagents for form’s sake, and don’t create unnecessary handoffs. When the task can indeed be split in a tree-like manner, and isolation, parallelism, and cross-review allow the main Agent to only retain goals, progress, and key states, you should use subagents to avoid forced compression of the main context. The former increases lottery steps, the latter changes the way information flows into the main context.

Epilogue

By viewing the Agent as an interpreter, subagents, skills, and memory become reviewable engineering choices again: which content enters the context, which knowledge stays in memory, which branches deserve isolation — all should have boundaries and be deletable and modifiable. When the model deviates, clear success and failure signals should allow it to retry, recover, or be corrected by another Agent; the real danger is errors that are silent, then repeatedly amplified in the context, dragging into a failure spiral.

Therefore, a good context is one that evokes and fully utilizes the skills the LLM has already learned during training, rather than relying on prompts to make it relearn and reassemble in the current context. And what better context “engineering” does is not to block all detours, but to ensure that an Agent that has gone astray still has a way back.

---