A semantic skill selector can make an agent prompt smaller. It can also make an agent less capable if it quietly removes the only map to available skills.
That is the boundary APX needs to protect.
APC is the portable context layer. A project can keep reusable instructions in .apc/skills/, review them in Git, and share them with compatible tools. APX is the local runtime layer. It decides what becomes active during one turn: a small catalog hint, a loaded skill body, or an optional semantic match.
Those jobs are different. Storing every skill body in every prompt wastes context. Hiding every skill behind a selector risks making useful instructions undiscoverable.
The safe default: catalog first
APX's normal skill path is deliberately simple. Its prompt can include a compact list of skill slugs, while list_skills and load_skill let the agent inspect and fetch the full body only when the work calls for it. The durable files remain owned by APC; APX treats them as on-demand runtime material.
Consider a project with four skills:
release-checklistsecurity-reviewsupport-triagedocs-style
For a request such as “explain this test failure,” loading all four bodies would add noise. A short catalog is enough. If the task becomes a release, the agent can load release-checklist. If it becomes an audit, it can load security-review.
That is prompt discipline without losing discoverability.
Where a selector can fail
APX also has an opt-in Skill Inspector. It can use embeddings to inspect the current request and inject a matching skill body or hint. This is useful when the request clearly maps to a known procedure.
But semantic selection is not ground truth. The request may be vague. A local embedding fallback may have weak signal. A new skill may use terms the request does not repeat. The relevant skill may be close enough to help but not close enough to win a ranking threshold.
If the runtime suppresses the normal catalog whenever the inspector is enabled, those cases produce a bad outcome: no loaded skill and no visible path to discover one. The agent cannot ask for the missing tool because it does not know the tool exists.
APX's runtime rule addresses this directly: the inspector replaces the static hint only when it can actually see the available skills. On the offline TensorFlow fallback, the catalog stays. The same per-turn resolution must run across HTTP, Telegram, and WhatsApp surfaces, so one channel does not silently receive less context than another.
A practical test
When adding retrieval-based skill selection, test the negative case:
- Enable the selector.
- Give it an ambiguous request that matches no skill confidently.
- Verify the agent still receives a compact catalog or another explicit discovery route.
- Repeat through every supported channel.
Do not only test the happy path where retrieval selects the obvious skill.
The broader APC/APX lesson is small but important. APC preserves reusable project knowledge. APX may route that knowledge intelligently, but routing must never erase the escape hatch. A catalog is not prompt bloat when it is the only reliable way to reach the right instruction.
Smart selection should narrow context. It should not make a project forget what it knows.
Top comments (0)