Pi behavior is weird when workflow execution is triggered via the editor component keyword.

[rwese]

Hi, currently, when a workflow is triggered from the editor component, the Pi process becomes idle, and you have to use the /workflow command to inspect the running workflow.

When workflows are used without the trigger being enabled, the LLM calls the tool itself and displays the workflow progress inline. In my opinion, this provides a much better experience.

I would prefer the editor-triggered workflow behavior to be more consistent with the normal workflow tool usage. Ideally, the Pi process would remain active while the workflow is running, so the interaction continues and users can queue additional prompts.

So the solution is to disable the trigger, but loses the nice animation.

A solution would be to have the trigger word enable the workflow tool, and prompts. Currently this extension adds a lot of system prompt tokens, all the time.

[QuintinShaw]

Thanks @rwese — sharp observation, and it lines up with #88. You've put your finger on the core issue: a keyword-triggered run currently rewrites your message and forces a background workflow, so Pi goes idle and you have to /workflows to watch it — whereas when the LLM calls the tool itself you get the inline experience and can keep interacting.

Your suggestion — have the trigger word enable the workflow tool (and let the model call it inline) rather than force a background run — is the right direction, and it also eases the always-on prompt-token cost you mentioned (@Whamp is separately trimming that in #65). Together with #88's over-triggering/default-on feedback, I'm treating keyword-trigger behavior as a design track to reshape rather than patch. Thanks for laying it out so clearly.

[Whamp]

Well enabling the tool part way through a session will break prompt cache and either get very expensive or make your subscription provider angry. I'm working on changes that teach the models it has the option to use either a background non blocking workflow or a blocking workflow. Part of the existing instructions in the tool description tell it to default to background workflows but don't tell it how which is one of the things I'm fixing in my PR.

Quick update on that. I'm moving lots of tool instructions to a skill to teach the model the available contracts and am running auto research to make it as concise as possible while still teaching a dumb model to execute it and pass all my workflow writing tests. Which hopefully means smarter models will have no problem.

[QuintinShaw]

Update now that the redesign landed (#93, on main for the next release): the keyword trigger no longer forces a background run — it arms the tool and the model decides, so a message that merely mentions workflows is answered inline instead of kicking off a detached run. And when it genuinely should run one, the tool now tells the model that a background run legitimately ends the turn and its result is delivered back automatically, so it stops treating that as a stall.

@Whamp — good call on the cache. To be clear, #93 does not enable/disable the tool mid-session (that would churn the prefix cache exactly as you say); the tool stays always-available and arming only adds a short per-turn directive. The blocking-vs-background choice you're teaching the model — plus the more concise contract via a skill — is the complementary piece that gets Pi staying interactive inline, and it's yours to land. Leaving this open until that ships.

[QuintinShaw]

3.0.0 is out with the root fix from #93: a keyword-triggered run no longer forces a detached background workflow — the model decides, and it's now told that a background run legitimately ends the turn and its result auto-delivers, so it stops going idle. The finer piece you asked for — Pi staying interactive inline, i.e. teaching the model to choose a blocking vs background run — is @Whamp's in-progress work, so I'm leaving this open to track that. Thanks @rwese.

[rwese]

Thanks for the update, will check it out!