DEV Community

Cover image for Opening the APC/APX Working Line
Agent Project Context profile image Manuel Bruña
Manuel Bruña for Agent Project Context

Posted on • Originally published at github.com

Opening the APC/APX Working Line

#devtools #agents #ai #opensource

Opening the APC/APX working line

We opened the first public GitHub Discussion for the Agent Project Context organization:

Join the discussion on GitHub

This is the starting point for a more organized APC/APX working line. The goal is simple: agent projects need a stable context layer and a runtime layer that can act on it without mixing durable project knowledge with private sessions, credentials, or tool state.

APC and APX are separate on purpose.

  • APC keeps portable project context in the repository.
  • APX handles local runtime behavior outside the repository.
  • The boundary between them should stay clear enough that teams can share project knowledge without leaking private execution state.

Current working line

We are focusing on four connected areas.

1. Portable project context

APC should store durable instructions, agent definitions, reusable skills, project rules, and MCP hints that are safe to share with collaborators.

It should not store raw conversations, runtime sessions, private memories, credentials, generated caches, or local tool state. Those belong to the runtime, not the portable project contract.

2. Local runtime orchestration

APX is the runtime side: daemon state, agent execution, MCP routing, Telegram bridges, scheduled routines, and multi-runtime dispatch.

That split matters because runtime behavior is powerful but personal. It can depend on local credentials, local tools, local schedules, and local message channels. Keeping that outside APC lets the repository remain portable and safe.

3. Deterministic automation around agents

A useful routine should not be just “run this prompt every day.” It should behave like a small pipeline:

pre_commands -> prompt -> agent result -> post_commands
Enter fullscreen mode Exit fullscreen mode

The model can reason, summarize, or write. Shell steps can collect facts before the model runs and deliver or archive output after the model returns.

That keeps the flexible part flexible and the automation boundary predictable.

4. Clear handoff variables

Routine variables are part of the contract between stages:

{{pre_output}}
$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

These make each run easier to inspect and debug. You can see what was collected, what the model returned, whether a step failed, and which routine produced the output.

What we want from discussions

The GitHub Discussions space is open for practical questions and concrete workflow examples:

  • what belongs in .apc/ and what must stay runtime-local
  • APX routine patterns and edge cases
  • useful pre_commands and post_commands examples
  • when to use exec_agent vs super_agent
  • MCP scoping and secret-safety decisions
  • portable multi-agent workflow examples
  • docs, naming, CLI ergonomics, and default behavior

The goal is not to make agents magical. The goal is to make agent work repeatable, inspectable, and safe enough to share across tools and teams.

If you are experimenting with APC or APX, bring the workflow you are trying to build. Concrete use cases will shape the roadmap better than abstract feature lists.

Start here: GitHub Discussion #1

Top comments (0)