A Thinner Slack Front Door

ForgeApps owns the instructions and skills. Hermes connects Slack. The open decision is which runtime should do the thinking and the work.

Recommendation: remove duplicate ownership first. Keep a minimal, stock Hermes baseline; evaluate a direct Codex bridge only if Codex runtime behavior is essential.
This is a proposed design, not an audit of the installed configuration. No runtime or Slack settings changed.

The Distinction That Matters

Codex model access is not the Codex runtime. Hermes can use ChatGPT/Codex subscription-backed inference while retaining its own prompts, tools, memory, and execution loop. That does not make it Codex CLI behind Slack.

01 / Smallest Practical Setup

One Source Of Truth, One Active Agent

Slack→Stock Hermes→ForgeApps Instructions + Skills

ForgeApps Owns

Shared instructions, identity, and working conventions.
The canonical skill library and reusable procedures.
Project knowledge, scripts, tests, and work outputs.
Integration knowledge required to perform tasks.

Runtime skill locations link to the shared library. Do not create divergent copies.

Hermes Retains

Slack connection, authorized senders, and thread routing.
Conversation state, delivery, recovery, and logs.
One chosen model provider and the execution loop.
Only the tools needed for the intended Slack workload.

A minimal agent still needs enough tools to execute its skills. A skill is guidance, not an executable capability by itself.

Remove Or Disable Duplication

Separate persona text that repeats repository rules.
Independent Hermes memory when the same knowledge belongs in ForgeApps.
Unused plugins, model fallbacks, background curation, and schedulers.
Unneeded toolsets and duplicate gateway supervisors.

Inventory dependencies and preserve useful records before removal. These are proposed reductions, not findings from a live audit.

Do Not Remove

Sender authorization and channel boundaries.
Command approvals and secret protection.
Thread continuity and enough logs to diagnose delivery.
Restart recovery and duplicate-event handling.

Thin means fewer competing responsibilities—not fewer safeguards.

Practical configuration direction: run from the ForgeApps root, load its shared project instructions, link the canonical skills, and keep Hermes-specific configuration limited to connectivity and execution necessities. Prefer stock settings over source patches.

02 / Actual Codex Behind Slack

A Transport Boundary, Not A Second Supervisor

Slack Thread→Hermes Messaging→Codex Session→Same Slack Thread

The desired bridge forwards the request and returns Codex output without another model rewriting the task or summarizing the answer. Codex owns reasoning, tools, and repository work; the bridge owns transport and session routing.

Minimum Bridge Contract

Map each authorized Slack conversation to the correct resumable Codex session.
Preserve message text, attachments, and explicit user intent.
Define whether mid-run messages queue, steer, or cancel.
Relay approval requests and record the approving identity.
Return results and files to the originating thread.
Recover after restarts without silently rerunning side effects.

Implementation Gate

A supported, configuration-only Hermes Slack-to-Codex-runtime relay has not been verified in this discussion.

First inspect documented extension boundaries and Codex session interfaces. If the integration requires a long-lived Hermes fork, its maintenance cost may defeat the goal.

Candidate paths include a supported gateway extension or a small adapter against a supported Codex execution interface. These are investigation targets, not confirmed working routes.

Avoid the tempting shortcut: “Always delegate to Codex” still leaves a Hermes reasoning loop in front of Codex. It creates two agents and two histories rather than a deterministic transport bridge.

03 / Reliability, Maintenance, Behavior

Which Version Is Actually Thinner?

Dimension	Minimal Hermes	Messaging → Codex
Agent behavior	Hermes execution, guided by ForgeApps.	Actual Codex execution, if the bridge is correctly implemented.
Maintenance	Lower expected burden: stock runtime and narrow configuration.	Additional adapter and interface compatibility to maintain.
Reliability	Fewer integration boundaries. Still requires delivery tests.	Adds session mapping, lifecycle, and approval failure modes.
Context ownership	One active agent history; repository knowledge stays canonical.	Codex owns reasoning history; bridge retains routing state only.
Latency and cost	One reasoning loop. Actual usage depends on tools and provider settings.	Also one reasoning loop only if routing is deterministic. No measured performance claim.
Best fit	Slack access with the least new infrastructure.	Codex runtime parity is a firm requirement.

04 / Proposed Sequence — Not Executed

Decide Before Building A Bridge

First: Establish The Thin Baseline

Inventory the active gateway configuration, injected instructions, skill paths, memory sources, enabled tools, background jobs, and supervisors. Classify each as keep, redundant, or required by a real workflow.

Pass condition: one canonical instruction/skill source, one gateway supervisor, and no unnecessary parallel knowledge system.

Then: Test The Need For Codex

Compare representative Slack tasks with direct Codex tasks: skill selection, file edits, validation, approval flow, and follow-up handling. Identify concrete behavior differences rather than relying on model names.

Pass condition: either minimal Hermes is sufficient, or specific Codex-runtime requirements justify the bridge.

If A Bridge Is Justified, Prove These Before Switching

A normal request and a follow-up resume the same intended conversation.
Unrelated threads and unauthorized users cannot inherit its context or approvals.
Duplicate delivery does not repeat an external action.
A gateway or worker restart does not lose the result or silently restart completed work.
Approvals, cancellation, attachments, and returned files work from Slack.
A failed worker produces a truthful error rather than a fabricated completion.
The previous working path can be restored without running two responders.

Evidence And Limits

Confirmed, Proposed, Unresolved

Documented: Hermes supports model-provider configuration, project context, tools, memory settings, and a messaging gateway. Its Codex OAuth provider is described as inference access.

Recommended: centralize repository knowledge, disable redundant runtime features, and favor a stock minimal setup before custom integration work.

Unresolved: a supported direct Slack-to-Codex-runtime handoff, installed-version compatibility, actual latency, cost, and migration effort. No live configuration audit or bridge test has been performed for this brief.