Steering the Reins

How Positive Instructions Shape the Reasoning Cycle That Selects the Next Tool

Author: apifunnel.ai Engineering
Date: August 2026

Most system prompts read like warning labels. Paragraphs of things the model shouldn't do.

"Do NOT use the sleep tool."
"NEVER call the database directly."
"Do NOT generate code comments that narrate what the code does."

We've been writing and shipping system prompts for agentic systems in production for over a year. The single biggest improvement in our prompt quality came from a shift we now think about as offensive prompting vs. defensive prompting — and the reason it works is mechanical, not stylistic.

The Sleep Tool

Here's the concrete case. We have an AI coding agent with access to tools: sleep, subagent launcher, file operations, search. We want the agent to multitask — launch subagents for parallel work instead of sleeping and polling.

Defensive version:

"Do not use the sleep tool. If a task can be done in parallel, do not sleep."

Offensive version:

"Multitasking is typically achieved by launching a subagent for parallel work, then continuing on the current task in the same turn."

Same goal. Same tools available. The offensive version wins — and not because "positive phrasing is nicer." The mechanism is specific.

The Reasoning Cycle Is the Mechanism

When the model reads your system prompt, it's not indexing a rule book for later retrieval. The instruction is part of the live reasoning context — the same context being evaluated right now to produce the next tool call.

This is the part nobody is naming clearly.

Defensive: the model encounters "do not use the sleep tool." It loads a prohibition. Prohibitions are subtractive — they remove one path without making any other path more likely. The model knows what it can't do. The space of things it could do is wide open. It has to independently discover that the right alternative is launching a subagent. Maybe it will. Maybe it'll do something unrelated. You've created a gap where you needed a bridge.

Offensive: the model encounters "multitasking is achieved by launching subagents." That instruction is actively being reasoned about in the same cycle where the model is about to select its next action. The subagent tool is right there in the tool list. The model's own reasoning now has a natural, low-friction path: I should multitask → the instruction says subagents → the subagent tool is available → call it.

The defensive version hopes the model figures out the right alternative after you've banned the wrong one. The offensive version puts the right alternative directly into the reasoning that's making the decision. One is a fence. The other is a rein.

This Is Not "Be Positive"

The generic advice exists: "tell the model what to do, not what not to do." Fine as far as it goes. But offensive prompting is a more specific claim about why it works.

Saying "be helpful" is positive phrasing. It's not offensive prompting.

Saying "when facing parallel tasks, launch a subagent using the Task tool to handle independent work streams" — that's offensive prompting. It connects the intent (parallel work) to the specific affordance (Task tool) in a way that the model's reasoning can execute on immediately. The instruction, the intent, and the tool are all active in the same inference step.

The difference is whether your instruction sets a vibe or builds a reasoning pathway to a specific tool call.

Patterns From Production

We've been converting defensive instructions to offensive ones across our system prompts. Here's what the before and after looks like:

Tool preference steering:


# Defensive (replaced)
"Do NOT use shell commands for file operations (reading, writing, editing).
 Use the specialized tools instead."

# Offensive (shipped)
"Use specialized tools instead of terminal commands when possible,
 as this provides a better user experience. For file operations,
 use dedicated tools."

Multitasking behavior:


# Defensive (replaced)
"Do not sleep and wait for background tasks."

# Offensive (shipped)
"Multitask on independent work while backgrounded jobs run,
 or finish your turn and rely on the end-of-turn completion
 notification."

Commit discipline:


# Defensive (replaced)
"NEVER commit changes without being asked."

# Offensive (shipped)
"Only create commits when requested by the user. If unclear, ask first."

In each case, the offensive version does the same thing: it puts a concrete next action into the reasoning context at the moment the model is deciding what to do. "Multitask on independent work" — the model reads that and its next thought is what independent work can I do? Which leads directly to productive tool selection. The defensive version just leaves a hole.

When Defensive Prompting Is Right

Defensive prompting has a narrow, legitimate use case: hard safety boundaries where the consequence of violation is severe and the rule is binary.

"Never execute destructive database commands without explicit user confirmation." That's a fine defensive instruction. The downside is catastrophic, the rule is unambiguous, and there's no "better alternative" to steer toward. The model must not do the thing. Period.

But for behavioral steering — which tool to prefer, which workflow to follow, how to decompose work — offensive prompting is the better tool. It's more reliable in practice because it works with inference instead of against it.

The Broader Observation

This pattern rhymes with something we've written about before. The Proof of Work pattern works because the enum shows up in the moment of decision — right when the model is reasoning about its next tool call, not 30k tokens earlier in a system prompt. Same principle. Context that participates in the active reasoning cycle has more influence than context that was processed and moved past.

Offensive prompting takes that observation and applies it to the system prompt itself. If the instruction describes the desired behavior in terms of the available tools, and the model encounters that instruction while reasoning about what tool to call next, you've put the answer in the question.

The assistants want to do a good job. They really do. Give them a clear path and they'll take it. Give them a list of fences and they'll spend tokens figuring out where the path is supposed to be.

Your system prompt shouldn't read like a warning label. It should read like a playbook.

The Proof of Work Pattern — Leveraging trained behavior at the exact moment of decision
The Scratchpad Decorator Pattern — Infrastructure-level memory without a dedicated memory tool
Agentic Workflows: A Purist Approach — Agent-as-workflow and compiled skills through one MCP surface

APIFunnel↗ uses offensive prompting across its system prompt stack. The instructions describe what to do in terms of the tools available, and the models take the path. Ken Wiltshire↗ is the founder.

The TPM Meeting Assistant Is Here (Beta): Agency Starts Where the Meeting Starts

Steering the Reins: How Positive Instructions Shape the Reasoning Cycle That Selects the Next Tool