Apply-Free Is Not Tool-Free

"'Apply-free' describes the turn, not the toolbox. It means no conversation is created — not that Pippa works with her hands tied."

Two Different Axes People Confuse

"Apply-free" is a phrase that invites a wrong inference. It sounds like a reduced mode — fewer capabilities, a lighter Pippa. It isn't. It describes exactly one thing: a Prompt Macro's call does not create a conversation turn. It's a one-shot utility invocation, run and returned, that doesn't append to a canonical conversation. That's the only thing "apply-free" means. It says nothing about tools, and conflating the two axes is a real bug source:

Turn axis: does this create a conversation turn? (Ask: yes. Macro: no — "apply-free.")
Tool axis: which tools are available? (Both: the full canonical tool surface.)

These are independent. "No conversation turn" does not imply "no tools," any more than "a quick errand" implies "empty-handed."

The Full Tool Surface, Even Apply-Free

A Prompt Macro's apply-free call still receives the complete canonical tool surface — the allowlist is all. If a macro's instruction needs Pippa to run a tool to do its job well, she can, because being apply-free never stripped her capability; it only declined to log a conversational turn. The mental model: apply-free is about bookkeeping (don't create a turn), not about power (keep every tool). Strip tools from apply-free and you've quietly turned a utility into a crippled one for no reason the user asked for.

Don't Inherit the Wrong Boundary

This is where a lineage caution matters. Pippa Go borrowed its focused-capture shape from the travel client, but that client drew an apply-free/no-tools boundary suited to its purpose. Pippa Go is a full Pippa client: its Ask uses canonical streaming chat with every tool the selected brain supports, and even its macros keep the full tool surface. Inheriting the travel client's tool restriction here would be borrowing a constraint that made sense there and misapplying it. Reuse the shape, not the unrelated limit. When you adopt a pattern from a sibling, adopt its structure — and re-examine every boundary it drew for reasons that may not be yours.

Code

Turn axis and tool axis are independent·typescript

// Ask: creates a conversation turn, full tools.
const askConfig  = { createsTurn: true,  toolAllowlist: "all" };

// Prompt Macro: apply-free (NO turn), but STILL full tools.
const macroConfig = { createsTurn: false, toolAllowlist: "all" };
//                                  ^^^^^                  ^^^^^
//                    'apply-free' lives here    tools are unchanged here

// WRONG mental model: apply-free => toolAllowlist: "none"
// That conflates 'no conversation turn' with 'no capability' — two different axes.

Exercise

Name two independent axes for a feature you've built (e.g. 'creates a record' vs 'has permission to write files', or 'logged' vs 'privileged'). Show how conflating them produces a wrong default. Then apply it to macros: write the config for apply-free-but-full-tools and the buggy apply-free-implies-no-tools, and explain which user need each serves — and which is a phantom restriction no one requested.

Hint

The conflation always looks like a reasonable simplification ('it's just a utility, so lock it down'), but it removes capability the user never asked to lose. Keeping the axes separate lets a utility be lightweight in bookkeeping while staying fully capable in power.