APX Routines Are Deterministic Pipelines Around AI
A lot of agent automation fails because everything is treated like a prompt. The model gets a vague instruction, some tools, and a schedule, then everyone hopes the same thing happens tomorrow.
APX routines take a different shape. The agent part can still be flexible, but the shell around it is deterministic.
That shell is the important part:
pre_commands -> prompt -> agent result -> post_commands
A routine is not only "run this prompt every day." It is a small pipeline where each stage has a clear role.
Pre-commands collect facts
pre_commands run before the prompt. They are plain shell commands, executed in order.
That makes them useful for facts that should not depend on the model:
- fetch weather
- inspect build output
- read a local status file
- query an API
- collect git changes
- grep logs
- prepare a compact context block
For example, a weather routine can run:
curl -s 'https://wttr.in/Bariloche?format=%t+feels+%f+%C+wind+%w' \
2>/dev/null || echo 'No weather data'
The model does not need to decide how to fetch the weather. The routine gives it the exact input.
The prompt consumes pre-output
The combined stdout from pre_commands becomes available inside the prompt as:
{{pre_output}}
That turns the prompt into a deterministic handoff point:
The following is current weather data for Bariloche, Argentina:
{{pre_output}}
The LLM still decides how to summarize or reason about the data, but the data capture itself is explicit and repeatable.
That distinction matters. It keeps the fuzzy part where it belongs: interpretation, not input collection.
Post-commands decide what happens next
After the routine kind runs, post_commands run as shell commands too.
That is where you can deliver or archive the result:
apx telegram send "$APX_LLM_OUTPUT"
This is especially clean with exec_agent: the model writes text, then the shell sends it. The agent does not need Telegram tool access just to deliver one message.
Use super_agent when the routine must actually operate with tools. Use exec_agent when the product is text and the post step can handle delivery.
Available variables are the contract
The UI exposes the important variables because they are the contract between stages.
Available in the prompt:
{{pre_output}}
Available in post commands:
$APX_LLM_OUTPUT
$APX_STATUS
$APX_SKIPPED
$APX_PRE_OUTPUT
$APX_PRE_OUTPUT_FILE
$APX_PRE_EXIT
$APX_ROUTINE
Available in pre and post commands:
$APX_ROUTINE
These variables make routine behavior easier to debug. You can see what was collected, whether the pre step failed, whether the prompt was skipped, what the model returned, and which routine produced the run.
That is a better automation surface than "the agent probably did something."
Why this feels different
The point is not to make AI deterministic. The point is to make the automation boundary deterministic.
APX routines give you:
- deterministic data collection before the model
- explicit prompt injection through
{{pre_output}} - deterministic delivery or cleanup after the model
- visible status through
$APX_STATUSand$APX_SKIPPED - file-safe access to longer pre-output through
$APX_PRE_OUTPUT_FILE
That is the useful compromise. The LLM can still write, reason, or summarize. The routine decides when it runs, what facts it receives, and what happens with the output.
For scheduled agent work, that boundary is the difference between a clever demo and something you can keep running.
APC keeps the project context portable. APX routines turn that context into predictable local behavior. Pre-commands, post-commands, and available variables are the small pieces that make it practical.