Humanity’s problem is that the people doing the work are always too young. The AI industry is rediscovering Cybernetics (Wiener, 1948) [1].

Do not imagine “intelligence,” but do not think of it as merely mechanical either.

Background

Defining the Problem

Solving a problem begins with defining it. What separates a novice from an expert is that the expert knows how to define the problem itself correctly.

Our fundamental need when using an LLM is simple: we expect AI to reach the intended goal, whether within a domain we understand or one we do not.

Why distinguish the two? Because the problems people face are not all alike:

1. Outside the expected domain
   1. People are not always capable of asking the right question.
   2. Nor do they always know how the problem should be solved.
2. Within the expected domain
   1. People know exactly how to solve the problem, but cannot be bothered to do it themselves.
   2. The process is so well defined that it leaves no room for human initiative.

The real question, then, is not “how intelligent is the AI?” but: how do we make the AI/LLM search for the answer along a reasonable path?

There are two cases. When facing the unknown, we guide the LLM toward the right answer within a vast representation space. When the procedure is already known, we use prompts to constrain—even “force”—it to follow the expected path instead of letting probability wander in every direction.

Once the goal is to control the path to a solution, the next step is to identify what can actually be controlled inside an Agent.

Defining an Agent

An Agent is an LLM-based agent that can complete tasks automatically through function calls. Its basic mode of operation is to repeat the following loop:

1. Input text: the system prompt, user input, skill prompts, and function-call information.
2. The LLM returns text, which may also contain function-call JSON.
3. The client executes the function call.
4. The original prompts, the LLM output, and the function result are placed back into the context.
5. The LLM continues with the next step.

Breaking It Down as a State Machine

Text → (LLM → possible function call) → Text

A function call looks like an “action,” but to the LLM it is still text that the client will interpret and execute. The function result then becomes new text in the next round of context. Function calls cannot be removed from this model: they are precisely the junction where an Agent turns text into action in the outside world, then turns the result of that action back into text.

Controllable and Uncontrollable Scope

Leaving aside injection techniques such as filtering and rewriting, what we can control is:

1. Prompts and user input.
2. Data returned by functions.

What we cannot control is:

1. Function arguments generated by the LLM.
2. Text returned by the LLM.

Mutable and Immutable Scope

During an actual task, the mutable part is the text—that is, the context. The relatively immutable part is the LLM itself.

The LLM Is the Interpreter; Context Is the Control Flow

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

An LLM is a “word-completing parrot”: from the context, it computes a probability distribution for the next token, then selects or samples one. Each newly generated token is added to the context, and the next token is computed again, until a stop token appears.

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

A minute difference in the “raw context” supplied as input can send an LLM miles off course.

Context itself is therefore the program and the control flow; the LLM is the interpreter that translates it, step by step, into text and function calls. It is not a deterministic interpreter—the same context does not guarantee exactly the same path every time—but managing an Agent still begins, fundamentally, with managing its context.

Solutions

Fully Static Workflows and Static Control

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

System Prompts

A system prompt constrains or extends AI behavior through empirically developed phrasing. Because it sits at the very beginning of the context, its influence is powerful: written well, it can elevate a poor model; written badly, it can make an excellent model stupid.

Fewer people now recommend devoting most of one’s effort to optimizing the system prompt—not because system prompts are useless, but because they are so difficult to get right. A supposed “best prompt” often holds only for a particular task, model, or even model version. Change the task, and the most effective wording may be entirely different, even counterintuitive. Optimizing a system prompt is therefore closer to local parameter tuning than to discovering a perfect, universally reusable constitution.

Worse, prompt effects do not accumulate independently, one rule at a time. A single requirement may not seem rigid, yet dozens together can produce an extremely strong “personality.” Put the same long prompt into different models and that personality may change completely; rules intended to prevent problems may even begin to create them. Methodological skills expose this especially clearly. A skill may intend only to encourage a way of thinking, but once it becomes too long and too tightly qualified, it can shift from “guiding the model” to “thinking in the model’s place.”

This is why I have always followed one rule when writing prompts: prefer semantically dense words that activate conceptual clusters the model already possesses, and convey constraints in the cleanest, shortest form instead of explaining them repeatedly. One word with depth can evoke a complete concept the model has already learned. Dozens of local prohibitions can only assemble one from fragments.

This also explains why the industry encounters the problem of “prompt migration”: broadly effective prompting methods often carry across models, but their exact wording may not transfer unchanged. The same text can unfold along different generation paths in different models: wording that works well for one may produce only a suboptimal result from another. A study of natural-language prompts found that merely rephrasing components or changing their order can substantially alter results; this order dependence appeared across several two-level fractional factorial design instances and different GPT and Gemini models (Ying et al., 2026) [2]. If a simple prompt achieves similar results across multiple models, there is stronger reason to believe that it captures a general method; complex wording that yields an additional benefit on only one model is more likely to depend on that model’s particular response tendencies.

Write Less “Don’t”; State the Goal Instead

Anthropic’s 2026 research on a global workspace in language models [3] provides a more concrete reference point for this experience. Its overall structural analysis uses J-lens to read the model’s internal verbalizable representations, observing how certain representations are broadcast across token positions and modulated by task instructions, and from there discussing structures in language models analogous to a global workspace. Prompt context carries the input; J-space is the space of representations read by J-lens; and global workspace describes the broadcast structure observed in the paper.

More directly relevant 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 detectable representations of target concepts. The category-instance and math-expression tasks produced fairly consistent results: merely mentioning a target or instructing the model “not to think” about it usually did not make its representation disappear, whereas marking the target as irrelevant to the task was more often associated with lower detection results. This relationship was not equally clear across every task, however: the line-width task, which required character-by-character counting, produced more mixed results. And J-lens measures whether the target concept can be read from the model’s intermediate states, not whether the model ultimately copied the text correctly.

Prohibiting a concept does not mean the model can avoid representing it first. In engineering practice, repeatedly describing an unwanted approach also consumes tokens, dilutes the information density of the actual goal, keeps the corresponding concept active throughout generation, and pulls the answer toward the very function space we hoped to avoid. When you can state the desired end state directly, do not build a maze out of its opposite. When a prohibition is genuinely necessary, keep it short, then return the emphasis as quickly as possible to what should be done and what is relevant to the task.

User Input

User input appears at the end of the context and can influence the LLM just as strongly. The simplest advice is to make fewer typos, simplify the wording, and clarify your own thoughts as far as possible before writing.

An early prompting trick illustrates the same principle: if you want XML output, end the input with <xml>; if you want JSON, end it with {. This exploits the local influence of the final input on what is generated next.

I have also discussed the security implications of why system prompts, the latest input, and tool results matter in AI Agent Privacy and Protection [4].

Mostly Static Filtering, Reorganization, and Structured Control

Beyond writing prompts directly, we can organize context at the boundaries humans control. An MCP Tool can carefully construct its input and return value; a skill can instruct the AI to use a particular command that narrows the output; or a gateway can automatically trim, reorganize, and structure tool results, as OmniRoute’s RTK Engine does.

These methods are useful, but overall they are being displaced by built-in compression in LLM tools and by context isolation through subagents. The fundamental reason is that hand-written rules cannot keep pace with falling model costs and advancing model capabilities. Fixed formats, obvious noise, and cheap preprocessing are still worth handling, but that is where their value ends: they are useful for casually cleaning up input, not for complex semantic control, and certainly not as the principal defense of an entire Agent control system.

The Old Paradigm: Isolating Context with Subagents

A step beyond static filtering is to isolate different work in separate contexts with subagents. But isolation is not free. Every transfer creates a handoff: either pass the entire context and reduce its information density, or compress it and accept the risk that the summary distorts it.

If the context is not compressed, handing all of it to the receiving Agent reduces information density even before length becomes a concern, making the LLM more likely to miss the task that actually matters. If it is compressed, the handoff becomes another lottery draw.

There are usually two ways to make the result more stable:

1. Increase the number of draws, through multiple LLM reviewers or loops.
2. Reduce the number of draws.

The first is token-burning expert review and loop programming: brute force in the hope of a miracle. The second is to avoid unconscious, unnecessary subagent handoffs by default. If a piece of work can be completed continuously in the current context, do not split it merely to resemble a multi-Agent system. Every takeover may compress the context too aggressively and force the new Agent to rediscover the entire background. This is why many people find that not using a subagent is sometimes faster.

The New Paradigm: Treating Skills as Programmatic Control Flow

If the LLM can be understood as an interpreter, then prompts are the code it executes.

Instead of writing one enormous, essay-like skill or prompt that contains every possible case, split it into multiple skills and chain them as control flow: when a condition holds, load one skill; otherwise, follow another branch. The AI then needs to read only the content for the current branch, directly avoiding context pollution from irrelevant information.

Stuffing every branch into one gigantic prompt is like writing all your control flow as spaghetti code.

This approach places demands on the AI’s capabilities and training. If a model habitually reads every file without discrimination, the control flow collapses. Fortunately, current Agent engineering is already quite good in this respect.

Subagents appeared in the industry before skills gradually took shape because subagents provide context isolation naturally. Skills, however, are better suited to mature, stable handoffs. Whether written by a human or an AI, a skill is fundamentally a handoff document that can be reused, reviewed, and continually refined. A new Agent or session can begin from a mature process instead of repeating the entire journey of discovering the problem, exploring the tools, and confirming the constraints—and without mixing the noise of “how the answer was discovered” into the context where the actual work happens.

Superpowers is one concrete example. Its significance is broader than this, but an important part of its value lies precisely in encoding mature working methods as skills and process documents, giving the receiving Agent a complete handoff and reducing both the time and the lottery draws required to rediscover the context.

A Context-Control Workflow for the New Paradigm

In an actual workflow, three things must be kept distinct. Give mature, linear execution processes—and transferable, clearly expressible ways of thinking—to skills. Give nonlinear knowledge such as user habits, historical state, and relationships to memory. Give execution work to subagents only when it genuinely deserves isolation, tree-shaped decomposition, or independent review.

Skills

A skill can codify two different kinds of things. The first is a linear, fixed, reusable, reviewable task process, including control flow and a mature handoff. It resembles both human-readable pseudocode and a stable requirements document. The second is not a sequence of task steps, but a transferable methodology or a personal approach to solving problems.

Many people find skills such as Superpowers too “overbearing.” The problem is often not that its methods lack value, but that exposing the entire collection for the Agent to discover allows descriptions that are too broad or ill-suited to the task to bring a preset working style along with them. What arrives is not only control flow, but the author’s complete set of habits about when to plan, how to test, and what counts as done. If some of those judgments do not suit the current user or project, the Agent will diligently write your code according to someone else’s methods. The more complete the skill, the more pronounced this personality becomes.

My approach is to expose only our own entry-point skill directly to the Agent—coding-in-project, for example—and adopt narrower external capabilities through it as needed: Superpowers’s subagent-driven-development to orchestrate subagents, and my own BDD skill to design and write tests. This captures Superpowers’s unmatched efficiency at subagent orchestration without inheriting its entire style and taste in code.

I can already imagine someone calling this a skill tree.

This is the “library call” programmers already know: your code invokes one capability from a library when it needs it, rather than letting the library decide how the entire program should be written. For Agents, the classic concepts of libraries, interfaces, and composition are already sufficient. What truly separates people is whether they can recognize those concepts again in something new, understand them deeply enough, and compose them well.

The Agent field is also repeating computing’s long-standing habit of coining terms. Split prompts and processes into files, for example, and call them skills. The term is now standard and there is no harm in continuing to use it, but a new name has not created an entirely new computing concept. This article explains it as a “library call” precisely because an old concept familiar to programmers already describes the composition involved.

Words such as harness expose the problem even more clearly. In Agent discourse, a harness often wraps existing things such as context assembly, the tool-call loop, state management, and execution control. Removed from a specific context and the reader’s prior knowledge, the name alone says nothing about what it actually does. Questions such as “can a skill replace an MCP Tool?” and “what is the difference between an MCP Tool and a function call?” once had straightforward answers: a skill organizes methods and workflows for an Agent; an MCP Tool exposes executable capabilities to the Agent host; the host can then turn an MCP Tool into a model-visible tool and invoke it in response to a function call generated by the model. Once these names are lined up beside one another, they begin to look like peers that might replace each other, and a host of unnecessary comparisons follows. Asking which can replace which merely because skills, MCP Tools, and function calls are all used by Agents is like pointing at an apple tree and asking, “Why doesn’t it grow pears?”

Coining a new term without identifying a new distinction, merely to sound profound, is not innovation. It transfers the author’s unfinished thinking to the reader. Shallow understanding and impoverished expression both become additional costs for the reader, who is then forced to translate the new term back into concepts that already existed.

Returning to skills: the first kind, process skills, should grow out of real work. Which processes deserve to be codified, how a skill should be used and revised after it is written, and how the AI should be supervised while it works can be reduced to four points:

1. A process worth codifying as a skill should be identified through real work, not indiscriminately summarized by AI. Skill descriptions enter every Agent’s initial context; you do not want a coding Agent to carry a skill containing a search recipe everywhere it goes.
2. For stable processes, prefer controlling the AI with skills rather than continuing to inflate the user prompt or system prompt. An all-encompassing prompt resembles a student handbook: even if every rule is reasonable on its own, together they dilute the task’s priorities and create an unpredictable personality in different models.
3. Once a skill is written, have AI review it, then repeatedly remove or revise material in response to real failures. Improving a skill does not mean endlessly adding detail. Necessary control flow should be added, but repeated explanations and imagined defensive prohibitions should also be deleted.
4. You must watch AI while it works: why did it start a subagent here, and why did it call that tool there? Today’s LLMs are becoming somewhat over-optimized for agentic work—and increasingly hyperactive. Unless detours are stopped promptly, an LLM will happily spend its time reinventing the wheel or even exploiting loopholes in the rules to evade the problem. Monitoring is not optional companionship; it is what makes the entire system of control possible.

The second kind of skill is suited to expressing the user’s own hard-won ways of thinking, probing, and decomposing problems as lightweight prompts. It resembles memory in an important respect: both give AI responses a relatively stable tendency, bringing them closer to the perspective the user wants it to adopt. This is also why I advocate watching AI while it works.

I tend to understand this tendency as a choice of “function space.” Put the same open question into the answer space of programming, medicine, or another profession, and it will produce answers in entirely different directions. Even within one field, it may land in the answer space of a senior practitioner, a novice, or a general audience that has not yet begun.

The value of a methodological skill is that a particular set of prompts can bias the model toward one of those spaces with relative consistency. grill-me, for example, makes AI more inclined to ask follow-up questions, decompose the issue, and challenge assumptions instead of simply following the question to an immediate conclusion. It carries a cognitive bias, not a “problem-solving program” that reproduces task steps. The LLM remains a probabilistic interpreter. The skill places the bias explicitly in the context, increasing the model’s tendency to select the corresponding function space without prescribing an inevitable answer.

Memory can gradually learn the same preference, but whether it is retrieved, how it is organized, and how it is ultimately injected into the current context may all be unstable. A skill fixes the preference in an explicit, stable, reviewable prompt, making it more reliable to trigger and easier to share and revise. That is the most important distinction between the two here.

Memory

Memory is well suited both to gradually learning your habits and preferred ways of thinking and to preserving nonlinear data such as relationships and historical state. Its advantage is that it can develop an understanding from context accumulated over time, without requiring every detail to be written as a rule in advance. Its cost is that retrieval and effect are less deterministic than with a skill.

Processing memory itself also requires context, so it must be isolated. The working Agent must never summarize, filter, or delete memories on its own. New context should enter a memory queue automatically and be handled by an independent memory Agent or proxy, such as Honcho or Hindsight; the working Agent should only retrieve the memories it needs.

Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents [5] adopts a similar architecture: the task-executing Agent remains unchanged, while an independently running memory Agent updates structured memory from recent trajectories and decides when to inject compressed, relevant memories into the task Agent’s context, mitigating “behavioral state decay” over long trajectories.

Nor should retrieval consist of having the working Agent perform a crude search and then filter the results itself. It should ask the memory proxy a question; the proxy should retrieve and organize the material in an isolated context and return only the answer to the working Agent. Deleting memory must likewise go through the proxy. Otherwise, memory management directly pollutes the active working context and defeats the purpose of isolation.

The boundary between memory and skills cannot be drawn simply between “remembered content” and “methodology.” Nonlinear knowledge that accumulates over time, such as historical state and relationships, belongs more naturally in memory. Mature, fixed execution processes belong more naturally in skills. A user’s preferred way of thinking can live in either; what differs is how it takes effect.

A skill therefore cannot be replaced entirely by memory. For a fixed process, memory introduces uncontrolled search and is harder to share and review. For a cognitive preference, memory may learn it gradually but cannot guarantee that it will enter every context in a suitable form. A skill is fixed, human-readable text: it can serve as a pseudocode-like requirements document that reliably triggers a concrete process, or as a lightweight prompt that explicitly biases the AI’s thinking space.

Subagents

The value of a subagent is not the handoff itself, but bounded orchestration: reduce unconscious handoffs by default, then, when the main context is approaching compression, use isolated branches to change how information flows back into it.

The wrong approach is for the main Agent to delegate work it could have completed continuously, then receive a compressed result and force the successor to rediscover the context. The right approach is to decompose a huge task repeatedly into a tree, allowing each subagent to handle a relatively independent branch completely in its own context and allowing the subagents to review one another. The main Agent does not receive the full discovery process from every branch; it monitors only goals, progress, and critical state. Local contexts need not be repeatedly compressed, and the main context is not stuffed with every detail until compression is triggered.

This is also more natural than relying on /goal. If a goal is too short, it permits too much interpretation. If it is too long, verifying the task against it may itself fill the entire context and trigger compression again. A tree of subagents resembles a company: workers complete clearly bounded tasks, while the main Agent coordinates and monitors the whole.

A company does not require every role to follow the same handbook, and different roles in an Agent system can likewise have different skills. Applying the complete Superpowers methodology directly to every role often makes the task unnecessarily heavy. Give it instead to a local subagent such as a leader, responsible for decomposing one segment or branch of the task and orchestrating its workers, and it can play to its strengths. Heavy methods remain local; the main Agent preserves the overall direction with a clean prompt and clear responsibilities, and the user retains command of the whole through it.

Do not use subagents for appearances, and do not create unnecessary handoffs. When a task genuinely admits tree-shaped decomposition—and isolation, parallel work, and cross-review allow the main Agent to retain only the goal, progress, and critical state—subagents should be used to keep the main context from being forced into compression. The former adds lottery draws; the latter changes how information flows into the main context.

Epilogue

Once we view an Agent as an interpreter, subagents, skills, and memory again become reviewable engineering choices. What enters the context, what knowledge remains in memory, and which branches deserve isolation should all have boundaries and remain open to revision or deletion. When a model goes astray, clear success and failure signals should let it retry, recover, or yield to another Agent that can correct it. The real danger is an error that passes silently, then compounds again and again within the context until it becomes a failure spiral.

A good context, then, evokes and fully uses capabilities the LLM already learned during training instead of relying on prompts to make it learn and assemble them anew in the current context. Better context engineering does not barricade every wrong turn; it ensures that an Agent that strays still has a path back.

References

1. Wiener, N. (1948). Cybernetics: Or Control and Communication in the Animal and the Machine. Hermann & Cie; The Technology Press; John Wiley & Sons.
2. Ying, D. D., Vazquez, A. R., & Xu, H. (2026). Prompt engineering using order-of-addition experiments: An application to generating two-level fractional factorial designs. arXiv:2607.05537.
3. Gurnee, W., et al. (2026). Verbalizable Representations Form a Global Workspace in Language Models. Transformer Circuits Thread.
4. xz-dev. (2026). AI Agent Privacy and Protection.
5. Wu, Y., et al. (2026). Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents. arXiv:2607.08716.

---