DEV Community

Cover image for APX Routines Are Deterministic Pipelines Around AI
Agent Project Context profile image Manuel Bruña
Manuel Bruña for Agent Project Context

Posted on

APX Routines Are Deterministic Pipelines Around AI

#ai #opensource #devtools #automation

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
Enter fullscreen mode Exit fullscreen mode

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'
Enter fullscreen mode Exit fullscreen mode

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}}
Enter fullscreen mode Exit fullscreen mode

That turns the prompt into a deterministic handoff point:

The following is current weather data for Bariloche, Argentina:

{{pre_output}}
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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}}
Enter fullscreen mode Exit fullscreen mode

Available in post commands:

$APX_LLM_OUTPUT
$APX_STATUS
$APX_SKIPPED
$APX_PRE_OUTPUT
$APX_PRE_OUTPUT_FILE
$APX_PRE_EXIT
$APX_ROUTINE
Enter fullscreen mode Exit fullscreen mode

Available in pre and post commands:

$APX_ROUTINE
Enter fullscreen mode Exit fullscreen mode

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_STATUS and $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.

Top comments (0)