TRMG AI Team Framework

Sep 27, 2026 · Tristan Rogers

Vision

The AI team exists to remove Tristan as the firm's only working index, so that Logan and the rest of the team spend their time on judgment rather than hunting for facts.

The system is called Mission Control. It runs on a self-hosted Mac Studio using Hermes as the orchestration layer, with local models for routine work and Claude for anything requiring judgment or facing a client. The agents (Apollo, Cosmo, Celeste, Atlas, Sol, Polaris, Rover) are named workers running on it. Mission Control names a place; the agents are who works there.

The team's window into it is the Mission Control page: each agent's job, activity and estimated cost over the last 15 days, system health, how to work with the agents, and a Feedback tab. Its numbers are a snapshot from October 15, 2026 at 11:49 PM, and the Feedback form does not save yet.

The durable asset is not the models. It is the harness: the routing logic, the accumulated memory, the skills, and how queries are constructed. Models are swappable. Institutional context is not.

How it fits with the human team

• The human team is Tristan (founder), Logan (associate, primary beneficiary of context retrieval), Becca, Ben, and Rich.
• Day one, most of the team installs nothing. Work surfaces as Monday updates, Gmail drafts, and Chat notifications with deep links.
• Direct access is currently Tristan, then Logan. Direct access means requesting work, not editing skills or switching models.
• Team sorting rule: if something should still be true next week, it goes to Mission Control. If you just need an answer now, use Claude.
• The team should not know Hermes is the underlying platform. Agents present under their TRMG names only.
• Agents never present as human colleagues to clients.

Two standing design principles

• Propose, then approve. Agents propose changes to memory, skills, and configuration. A human approves before anything permanent is written.
• The approval button is the product. "Send to client as me" is the last capability to enable, not the first.

Apollo, alignment and administrative agent

Status: live, running in its own Hermes profile on Sonnet 5 as of September 12, 2026. Filing reads whole threads since September 28, 2026 and swaps the Triage label after each run (28 threads filed through October 1). Recaps run every weekday.

Role: Apollo keeps the team and clients aligned so projects move forward, working across Google Workspace, Monday.com, and Fireflies.

Responsibilities today

• Files email threads labeled Triage/4: To File to the right Monday item as a signpost Update with a deep link back to the thread
• Resolves the client and board from the trmg-roster skill, and routes vendor correspondence to vendor entries rather than the client's own workstream

Responsibilities planned

• Meeting recaps are live since September 23, 2026: the fireflies-recap route runs the apollo-recap skill, stages a recap Gmail draft to the meeting owner, and posts a Monday Update. Since October 1 the email reads as a consultant's note (greeting, takeaway, what we are doing and why, next steps client first) with the meeting date in the subject. Since October 2 the Monday Update ends with proposed subitems that a person approves with "@Apollo create" (drawing below). Since October 14 internal meetings (every attendee on trmg.io) are skipped: nobody read those recaps and they were nearly half of recap spending; their commitments move to a lean route once built. Since October 14 every Update with proposed subitems tags each TRMG owner plus Tristan, created subitems get a context Update, and Hi Tech meetings covering two or more stores add dealer callouts: one Update on each store's Dealer Alignment item and one email draft to the store (contacts from TRMG's Stratos, CC Mike, Louis, Steve). First run: the October 14 CarGurus review, four stores
• Nightly inbox sweep and morning digest
• Client backfill: read 12 to 18 months of inbox and Fireflies history per client and write durable, provenance-tagged facts to client memory files, reviewed one client at a time
• Sourced context retrieval for Logan: he asks a question, Apollo returns context with links and no recommendation

Trigger: a Zapier Gmail trigger fires when a thread receives the To File label and POSTs to the gmail-filing webhook route. Recaps would be triggered by Fireflies meeting completion.

Tools and accounts: its own Monday MCP server (apollo-monday, remote HTTP), Gmail for tristan@trmg.io (local wrapper apollo-gmail-tristan and Google's official apollo-gmail-tristan-google) and admin@trmg.io (local wrapper apollo-gmail-admin), Google Calendar, Google Drive, Fireflies. trmg-monday-updates and trmg-roster are linked from the master copies in ~/.hermes/skills/trmg.

Must never do

• Create a Monday item, or a subitem nobody approved. Subitems are made only after a person replies "@Apollo create" to Apollo's proposal (October 2, 2026).
• Post to Monday without a deep link to the source.
• Post to items whose status is Complete, Approved, or Submitted.
• Post on anything but a confident match. Ambiguous threads stay in the queue for a human.
• Send email.

Monday identity: its own Monday agent (agent 272638), in webhook mode since September 28: an @mention reaches Apollo through the Monday bridge and it answers in the same thread.

Subitems from meetings (October 2, 2026)

[Embedded content in the artifact: subitems from meetings · 5 steps, 1 approval. A drawn diagram in the source; it does not translate to markdown.]

Owner is the TRMG person who took the task, otherwise Tristan with the real owner named. Target Completion is the date said in the meeting, otherwise 1, 2, 3, or 5 business days for Critical, High, Medium, and Low. Example from the Beck & Beck Go-to-Market on October 2: "412 Digital: move budget to Target CPA, pause expired offer ads. Under: Vendor Alignment. Owner: Tristan (Josh at 412 Digital). High, due Tue Oct 6."

Cosmo, creative production coordinator

Status: running on real creative intake in its own Hermes profile on Sonnet 5, but not yet working in full. Bringing Cosmo, and every other agent, to fully working is the near-term priority. Three consecutive live requests filed cleanly with no tool errors, including correctly detecting a forwarded thread as a continuation of an existing request rather than a new one.

Role: Cosmo monitors creative@trmg.io, identifies the client, files the request on the client's Monday board with a CR number, and stages a draft reply for team review.

Operating principle: Cosmo always gives a human the pre-thought for anything that needs review. It is never solely responsible for the burden; a person makes the call.

Responsibilities today

• Reads inbound creative requests, resolves the client from sender domain via the trmg-roster skill
• Hi Tech Motorcars rooftops: creates an item in the Active Scope group of the Hi Tech creative board, sets Dealership, Category, and Email Subject
• Beck and Beck Buick GMC: creates a subitem under the open monthly Creative Requests item on the Beck and Beck board
• The Monday item id is the CR number; it never goes in the entry name (the board's CR ID column shows it), and the entry gets one intake Update with the thread id and a gap list
• Stages a Gmail draft reply from creative@ listing what's missing
• Orphaned requests (unknown client, no matching parent) surface as visible drafts rather than being dropped

Responsibilities planned

• Replying to clarifying questions when a human replies to its intake Update (the Monday two-way loop)
• Drafting lightweight templated work such as website graphics and emails, once the manifest-driven rendering pipeline exists
• Image cataloging: on upload to R2, write structured fields (brand, model, year, angle, color) to a per-client catalog file in git

Trigger: a Zapier Gmail trigger on creative@trmg.io POSTs to the zapier-cosmo webhook route, bound to the cosmo profile at the /p/cosmo/ path.

Tools and accounts: its own Monday MCP server (cosmo-monday, remote HTTP, a distinct Monday user from Apollo) and Gmail for the admin account, which creative@ is an alias on. Skills: cosmo-creative-coordinator and trmg-roster.

Must never do

• Send email. Drafts only; a human sends.
• Post to Monday without a deep link.
• Guess the client. If it cannot identify one confidently, file what it has, state the uncertainty, and stop.
• Post more than one intake Update per run.
• Write to items whose status is Complete, Approved, or Submitted.
• Use web search or fetch external sites during intake.

Known gap: resolved September 27, 2026. Replies go through reply_draft on the local Gmail wrapper (cosmo-gmail-admin), which places the draft in the original thread and sets the sender to the address the email was sent to, read from its headers and checked against the mailbox's send-as list. Google's official Gmail MCP cannot set a sender, so Cosmo stays on the local wrapper. Live test pending.

Monday identity: a distinct Monday agent posting under the Cosmo name (agent 315745), so its work is distinguishable from Apollo's and from human work. In webhook mode since September 28: an @mention reaches Cosmo through the Monday bridge and it answers in the same thread.

Celeste, co-op agent

Status: live since October 14, 2026, in launch stage filing: it files co-op documents to Drive, writes the Files link, and posts Updates. Status changes and new claims stay off until Ben and Tristan have reviewed its filing. Name kept after considering alternatives.

Role: Celeste monitors the Co-op board, makes low-risk status updates, and eventually files inbound co-op documents to Drive and Monday.

Target board (verified): the Co-op board. Two groups: Claims and Emailed items. The Files column is a link column, so documents live in Drive and are referenced by URL. Status has 14 labels covering the full claim lifecycle. Pre-Approval ID carries OEM-specific formats for Bentley and Porsche.

Phase 1: monitor and low-risk updates

• The one safe unattended transition is Awaiting Documents to Documents Received when a matching document arrives, paired with an Update recording what arrived and when
• Highest-value read-only output: claims past Deadline that are not yet Submitted

Phase 2: document intake

• Scheduled Gmail sweep for inbound co-op documents, which arrive by email on OEM cadences
• File to Drive, write the Drive URL into the Files column, post an Update on the claim

Trigger: cron-driven rather than webhook-driven, since documents arrive on schedules and status drift happens over days. One Hermes cron run every weekday at 1:30pm Central: sweep, deadline check, daily brief, posted as a reply under the Celeste Co-op Briefings post in the Co-op board's Board Discussion, tagging Ben and Tristan, who confirm any judged match. Since October 14 she reads every document (dealer billed, activity period, amount) before matching, adds herself to the People column of any claim she touches, and files event documents in the Events folder with an Event Planning shortcut in each dealer's own claim folder.

Tools and accounts: its own Monday MCP server, to be named monday-celeste and defined only in the celeste profile. Its own Gmail connection, scoped to co-op@trmg.io, the co-op correspondence address, which lives on the admin Google account. Two-way Monday @mention on the co-op board, live since October 14, 2026.

Must never do

• Move a claim to Submitted, Denied, or Not Claimed Intentionally
• Write Amount, Claim ID, or Pre-Approval ID
• Change anything about deadline drift; flag it, never act on it

Open before building: what identifies a document as belonging to a specific claim; the Drive folder structure; what Automatic Claim? means operationally; which OEMs beyond Bentley and Porsche have named pre-approval processes.

Atlas, analytics agent

Status: a name and a placeholder. Atlas has not been workshopped; everything below is material to test in that workshop, not scope. Named for the guiding force and for a bound collection of charts, since the practice is guided by data.

Role: Atlas supports paid media management and website analytics, holding data from several systems at once so the team can see what moved and why.

Data sources

• AgencyAnalytics is the client reporting platform and has a modern API. Atlas reads from it rather than rebuilding it.
• VinSolutions has no usable connector. Scheduled reports arrive as Excel attachments to reporting@trmg.io, an alias on the admin inbox.
• Meta and Google platforms are reachable directly where needed. Uncertain whether AgencyAnalytics already aggregates enough that a direct connection is unnecessary.

The VinSolutions design decision: scheduled reports have a fixed schema, so extraction should be a written parser, not a model reading spreadsheets. A model authors the parser once from a few real files, a human reviews it, and after that it runs as code. Atlas spends its reasoning on what the numbers mean. The first Atlas task is collecting real reports and writing that parser, not building an agent.

The reconciliation problem: VinSolutions, AgencyAnalytics, and the ad platforms each hold part of the picture. Atlas is the thing that can hold all three and say spend went up here and appointments did not follow. This is the core value and the hardest part.

Prior work to inherit: the GA4 framework brief already covers ASC spec adoption, vendor responsibility matrices, and property architecture. Atlas should not reinvent that taxonomy.

Trigger: an @mention (or assignment) on the client's Monday item, through the Monday bridge, live since September 28 (agent 437124). A daily digest on cron comes later.

Tools and accounts: its own Monday MCP server, to be named monday-atlas and defined only in the atlas profile. Gmail scoped to reporting@trmg.io. AgencyAnalytics MCP.

Must never do: not yet defined. Uncertain until the scope decision is made.

Open before building: which VinSolutions reports are scheduled, on what cadence, for which rooftops; what questions Atlas answers (a weekly digest and an on-demand question-answerer are different builds); which client first (a single-rooftop store such as Beck and Beck or Georgetown INFINITI rather than a multi-rooftop group); where outputs go; whether Atlas writes back into AgencyAnalytics or only reads.

Sol, Stratos support assistant

Status: an idea with a name, set September 28, 2026. Everything beyond the title is open until a scoping session.

What is known: Stratos is built on GoHighLevel. Its connector uses the GoHighLevel public API, works per sub-account (location), and classes operations as read, write, delete, and money movement. Client phone calls captured through the phone system reach Fireflies as "Stratos call" and Apollo files them to Monday.

Tools and accounts (planned): sol-stratos, read only to start, and sol-monday. A Gmail connection only if support arrives by email.

Must never do (starting position, to confirm): move money, delete, write to Stratos without a person approving, send email, or present as a human to clients.

Open before building: who Sol supports (the team, clients using Stratos, dealership staff), what support covers, where requests arrive and answers go, what Sol learns from, which sub-accounts it may read, how it escalates, and whether it ever writes in Stratos.

Polaris, project management assistant

Status: an idea with a name, set September 28, 2026. Brief at briefs/polaris.md. Scoping workshop next.

Role: manages the work, not the record. Reads statuses, owners, and dates across the Monday boards, says what is due, what is slipping, and who is overloaded, and delivers the daily digest. Proactive: acts on a schedule and speaks up.

Boundary with Apollo (decided September 28, 2026): Apollo keeps the record and reacts when something arrives; Polaris manages the work and acts on a schedule. They read the same boards but never the same fields. A digest of what came in is Apollo's; a digest of what is at risk is Polaris's. The morning digest moves from Apollo's plan to Polaris.

The digest, eventual shape: Polaris asks each agent one question in its own area (Apollo on what arrived and was filed, Atlas on what moved in the numbers, Cosmo on creative requests waiting, Celeste on claims near deadline, Sol on open support items) and combines the answers into one message. First build is Polaris alone from the boards; the fan-out waits for a way for one agent to ask another, which is a Mission Control question.

Tools and accounts (planned): polaris-monday, read only to start.

Must never do (starting position): change a status, date, or owner without a person approving; create or delete items; send email; speak to clients.

Open before building: where the digest goes, when and for whom, what counts as at risk, whether Polaris nudges owners directly or only reports, whether it ever writes status, dates, or owners.

Rover, website audit agent

Status: Building, profile offline. Named Rover on October 9, 2026. Brief at briefs/rover.md. Captures partner sites at phone, tablet, laptop and desktop widths and posts ranked frontend findings to Monday. Runs on its own Anthropic key (a service account key) since October 14, 2026. Next: the offline test on four practice sites, then Monday two-way and go live.

Role: runs high-level visual audits of partner websites and recommends a few changes or areas of opportunity that TRMG, as consultancy of record, should raise with each partner. Advice for the team to review, never changes made to a site.

What is known: client sites run on Orbit, TRMG's brand powered by Duda. Automotive partners use several automotive-specific vendors or CMS platforms (Dealer Inspire for Beck & Beck; the rest to be listed). A Duda connector exists for Claude; what Hermes can connect to Duda with is unverified. Page capture is Rover's own local, read only tool (rover-pagecapture), so the Hermes browser tools stay off.

Must never do (starting position): change, publish, or unpublish anything on any site; contact a partner or vendor; present findings without saying what was checked and when.

Open before building: what an audit covers; which sites first and the full platform list; how findings are delivered; what it may read in Duda; how pages are captured and what an audit costs; whether compliance rules are in scope; the split with Atlas between analytics and review.

How work moves between agents and people

Monday is the system of record and Chat is the interrupt layer. If a message still matters in a week, it belongs in Monday, not Chat.

Into the agents

• Zapier holds the triggers. It watches Gmail labels, Fireflies completions, and other external systems, and POSTs to Hermes webhook routes on webhook.trmg.cloud. Zapier stays because it is good at watching things TRMG does not control and has retries and history built in.
• Cron jobs in Hermes handle anything on a genuine schedule: nightly sweeps, the morning digest, Celeste's document sweep, Atlas's report ingestion.
• People reach agents through Monday @mentions (once two-way integration exists), through the Mission Control web interface at missioncontrol.trmg.cloud behind Cloudflare Access with trmg.io Google login, and eventually through a messaging channel. Telegram was preferred over WhatsApp for focus and simpler setup. Google Chat is natively supported and is a weekend setup item.

Out of the agents

• Every agent output lands as a Monday Update with a deep link back to the source: a Gmail thread, a Fireflies timestamp, a Stratos record.
• Email leaves only as a Gmail draft. A human sends.
• Anything unresolvable (unknown client, missing routing data, no confident match) surfaces as a visible draft or a flagged Update, never a silent drop.
• Agents never block. They draft with what they have, omit what they cannot source, post their questions alongside the draft, and stop.

Between agents

• Skills delegate to skills rather than duplicating logic. The email filer and the recaps port both hand their Monday-writing step to trmg-monday-updates, so the board-writing rules live in one place.
• Hermes supports parallel sub-agents within a session for context assembly (searching Gmail, Fireflies, and Monday at once) and persistent Bots with bot-to-bot messaging. Neither is wired up yet.
• Knowledge is shared through skills, not memory. Hermes gives each profile its own private memory, so client facts and house rules that must be true for every agent live in the master skills at ~/.hermes/skills/trmg, which each agent links into its own profile. Profiles carry different models, tools, and skills, not different knowledge.

From people back into the system

• Corrections are given in plain English in a session. What matters is the scope of the rule (for this client, always copy these three people) rather than the wording.
• Agents propose changes to their own skills and memory as diffs. Tristan approves. Nothing is self-edited silently.
• A correction becomes a skill edit only when it repeats. The first time is a one-off; the second time is a rule.
• Every piece of feedback carries a four-way classification: house rule, client standing rule, template change, or one-off. One-off is the default; anything permanent requires a deliberate choice.

Shared rules that apply to every agent

These live in each agent's SOUL.md and in MEMORY.md, so they ride along on every call.

Writing

• Never use em dashes, en dashes, or spaced hyphens as separators. Use colons, commas, periods, or a reworded sentence. This applies to Monday updates, emails, memory entries, and skill files.
• Match reply length to the weight of the ask. No filler, no restating the request, no narrating tool calls.

Honesty

• Never fabricate. If a fact is not in front of you, say you do not have it and name where it could be found.
• When reporting credentials, config values, or system state, read the actual file or command output and quote it. Never reconstruct from memory of an earlier turn. This rule was earned: an agent invented two different passwords in one report, claimed Tailscale was not installed when it was, and reported a consent screen as Testing mode when it was Internal.
• Verify outcomes rather than accept reports. An agent said Ollama was under launchd management when the app's own agent had won the port; only checking caught it.

Memory discipline

• MEMORY.md is for standing rules and environment facts that must be true on every call. Never write session summaries, calendar snapshots, changelog entries, skill-creation announcements, or "no corrections in this session" notes there. It has a 2,200-character ceiling and was at 96 percent before cleanup.
• Client-specific and project-specific facts live in per-client Markdown files that skills load on demand, not in the always-injected block.

Monday

• Never post without a deep link to the source.
• Never create items or subitems unattended. Updates only, unless a human approves the creation. (Cosmo is the deliberate exception: creating the CR item is its job.)
• Check the target's status immediately before writing. Never write to Complete, Approved, or Submitted work.
• Agent identities on Monday are display names for attribution, so the team can tell agent work from human work. Apollo and Cosmo post as different Monday users.

Email

• Drafts only. No agent sends.
• Signatures are code, not prose (September 30, 2026). The master blocks live in scripts/email_signatures.json and the local Gmail tool appends the right one to every draft by sending address. Team members sign with their name; agent aliases sign as a team (Creative Team for creative@, Co-op Team for co-op@, Analytics Team for reporting@) in the same style, office line only, no direct line. No agent ever writes a signature. Apollo's recap drafts go through Google's server, so the recap skill mirrors the team blocks and must stay identical to the master.
• Every email is single spaced: div blocks, one line break between them, never a line height above normal. The Gmail tool enforces it; the body ends with "Thanks," and the signature follows.
• TRMG has Developer Preview access to Google's official Gmail MCP; Apollo's recaps use it. Anything that must send from an alias uses the local wrapper, because only the wrapper can set the sender. Every reply from an alias goes through reply_draft.

Tools and configuration

• Every agent's MCP servers are named agent-service-account, with -google for Google's official server (apollo-monday, apollo-gmail-tristan-google, cosmo-monday, cosmo-gmail-admin) and are defined only in that agent's profile, never duplicated into the default profile. In multiplex mode a server name is claimed globally by whichever profile is discovered first, and the default is always first; a same-named server elsewhere is silently orphaned when its config differs. With identical config the second profile only borrows the connection and can lose its tools when the connection drops; that is what broke Cosmo's Monday access until September 27, 2026. Each agent's keys live in its own .env and config.yaml references them as ${VAR}. Tools an agent has never used that can change or delete data are switched off per server with tools.exclude.
• Unattended by default: reads, searches, drafting, filing, classification, cron sweeps. Gated behind approval: installing software, switching models, changing configuration, anything touching live client systems. An agent that can install its own dependencies can quietly change which model it runs.
• Memory saves require approval (memory.write_approval on for every profile since September 27, 2026). Unattended runs stage their saves for review with /memory pending rather than blocking.

Routing

• Client-facing work and anything compliance-sensitive runs on Claude, no exceptions. Local models earn their place on high-volume, well-defined transforms: classification, extraction, template filling.
• Both live agents moved from local models to Sonnet 5 after Nemotron produced repeated tool-argument errors on multi-step work. Local models produce plausible mediocrity; the gap is worst on knowing when they do not know.
• Correctness first, cost second. Prove a skill on Claude, then try moving it local and compare against the same examples.

Environment reference

This section describes where things live and how to find current values. It deliberately holds no IDs, version numbers, or counts, because those change. Look them up where they live.

Layout

• Mission Control runs on a Mac Studio. The Hermes home directory is ~/.hermes and it is a git repository pushed to a private GitHub remote.
• Each agent is a Hermes profile at ~/.hermes/profiles/<name>/ with its own config.yaml, .env, SOUL.md, memories/, skills/, and logs/. The default profile is ~/.hermes itself.
• One gateway process serves all profiles in multiplex mode. It starts under the sticky profile set by hermes profile use, which must stay default. On September 27, 2026 a restart brought the gateway up as apollo, with no webhook listener, because the sticky profile had been switched to apollo on September 24. Restart with hermes -p default gateway restart and confirm the webhook shows connected.
• Webhook routes are dynamic subscriptions in ~/.hermes/webhook_subscriptions.json. A profile field binds a route to a profile and moves its URL to the /p/<profile>/ prefix. A git filter redacts the secrets on commit, so a copy restored from history needs its secrets re-entered before the routes work.
• Services run as launchd agents. List them with launchctl list filtered on hermes, ollama, and cloudflared. The Mission Control web interface is hermes-webui, and the Hermex iOS app depends on it; replacing the web interface means replacing the mobile path too.

Where to look

• Profile-level events, including MCP server discovery, log to profiles/<name>/logs/agent.log. Gateway-level events log to the root logs/agent.log. Looking in the wrong one wastes time.
• Hermes version: run hermes version. After any update, run hermes doctor.
• Client domain to board mapping: the trmg-roster skill.
• Monday column IDs: the skills that use them (trmg-monday-updates, cosmo-creative-coordinator).
• Board and column details for Celeste: recorded on her item on the TRMG board.
• Public hostnames: the trmg.cloud zone in Cloudflare. The Studio's private address: the Tailscale admin console.
• Which model each profile runs: hermes -p <name> status.
• Which MCP servers each profile has: hermes -p <name> mcp list.

Known environment facts that do not change

• TRMG has Developer Preview access to Google's official Gmail MCP. The local wrappers around the standard REST APIs remain in use, and are the only path that can set a send-as address.
• The Monday MCP is remote HTTP at Monday's own endpoint. An earlier stdio version needed a pinned Node 22; that path is retired.
• Updates to Hermes are scheduled events, not automatic. Update on a weekend, run doctor, then re-test both live agents.

Working in this repository

Rules for any tool or session editing ~/.hermes. The split is decided: Claude Code builds, Hermes runs. Editing config on a machine with live services is a different act from authoring a skill. The rules below were each learned by breaking something.

Guardrails

• Back up any config file before editing it, as a timestamped copy.
• Never restart the gateway or any service without saying so first. A restart drops in-flight webhook sessions.
• Never push to GitHub without reviewing git status for secrets. Config backups once carried real passwords into local history.
• Never commit the working directory wholesale. The large uncommitted diff is runtime state, not work.
• Never edit files while a Hermes session may also be editing them.
• Read the actual file before reporting its contents. Show diffs before writing.
• Adding an MCP server: unique name, defined only in that agent's profile. Check the default profile does not already define the same name.

Test recipes

• Apollo: label a real thread Triage/4: To File. Then check hermes -p apollo sessions list for the run, and the target Monday item for the Update with its deep link.
• Cosmo: send a request to creative@trmg.io from a known client domain. Then check hermes -p cosmo sessions list, the client's board for the new CR, and the admin Gmail drafts folder for the reply.
• Any MCP server: hermes -p <profile> mcp test <name> proves the CLI can reach it. Only a webhook-triggered session proves the gateway mounts it. The two differ.

Definition of done

A real item name, a real draft ID, a PID with exit status 0. Never a success message. Agents in this system have reported success on things that did not happen; verification is the job.

Eval set shape

Each example is three things: the input (a real thread or request), the expected outcome (which item, which fields, which draft), and where it came from. Ten per agent. Run the set before and after any model or prompt change.

Briefing each role

• One Claude Code session per role, named after it, so work on one role never crowds another. Open whichever is relevant that day.
• Each role has a one-page brief at ~/.hermes/briefs/<role>.md: job, triggers, connections, skills, hard limits, test recipe, current state, open decisions, next steps, launch checklist, and a dated session log. The template and rules are in briefs/README.md.
• Every session reads its brief first and updates it last. This doc stays the big picture; a brief is the working page for one role.
• Claude Code's standing rules live in ~/.hermes/.claude/CLAUDE.md. It sits in .claude/ because Hermes auto-loads a CLAUDE.md or AGENTS.md at the top of ~/.hermes into every agent's prompt.
• A role's own files are safe to change in parallel sessions. Foundation work (the gateway and its settings, restarts and updates, the shared Gmail tool and shared skills, routes, keys, naming and rules, taking a role live) belongs to one Mission Control session with its own brief at briefs/mission-control.md. A role session that needs a foundation change stops, files a request in that brief, and hands off. The Mission Control brief carries an In progress line while foundation files are changing, and role sessions hold restarts while it is set.
• New roles stay offline: the gateway only serves the profiles in gateway.multiplex_profile_allowlist (apollo, cosmo, atlas as of September 28, 2026). Adding one is a launch step Tristan approves.
• Never switch git branches in ~/.hermes: it swaps live files under running agents. Commits carry the role as a prefix.

Priorities and order of rollout

Finish what is half-done before starting anything new. Each phase should be independently useful before the next begins.

Now: close the two live agents

1. Apollo: Zapier URL is profile-scoped (done). The real filing test after the September 27 changes passed September 28 (a 25 message thread, read whole, filed, label swapped). Apollo's remaining items are in the tracker below
2. Cosmo: reply_draft built and the skill and zapier-cosmo prompt updated September 27. One live test to creative@trmg.io is pending
3. Done September 27: the default profile defines no MCP servers, every server follows agent-service-account naming (renamed the same evening), the Logan profile is deleted, and Monday keys moved into each agent's .env

4. Rotate exposed credentials: Monday tokens first (they were shown in full in chat and carry full write access), then the webhook secrets together with their Zapier updates, then the webui password

   Added September 28: the Monday signing secrets for Atlas, Cosmo, and Apollo (rerun scripts/monday_signing_setup.py per agent; never exposed, rotated as routine), and the monday-atlas, monday-cosmo, and monday-apollo route secrets (they sit in a local Claude Code session transcript on the Mac; only the bridge and Hermes use them, so no Zap needs updating).

   Added October 2: the gmail-filing webhook secret was printed again, this time in an Apollo session's output through a redaction mistake. Rotate it with the other webhook secrets and update its Zap.

Apollo: open items to go live (October 2)

Sixteen items stand between Apollo and fully live, in the order they unlock each other. As of October 14: two done, three in progress, three with Mission Control, seven waiting on Tristan, one on the team. Requests 14 to 19 are written out in briefs/mission-control.md.

Next: measurement and the recaps port

5. Eval sets: ten filing threads and ten creative requests with known-good outcomes. Outstanding since the planning sessions. Without it, every model or prompt decision is a debate rather than a measurement.
6. Port trmg-client-recaps into Hermes as an Apollo skill, delegating its Monday step to trmg-monday-updates and moving the Hi Tech standing CC list into a client memory file

Monday two-way: built for Atlas, Cosmo, and Apollo (September 28)

7. Anyone @mentions (or assigns) an agent in a Monday update and the agent answers in that same thread. A follow up needs a new mention, since Monday only calls on a mention or assignment. A small bridge on the Mac (scripts/monday_bridge.py) sits between Monday and Hermes: it checks Monday's signature (an HMAC over the timestamp and body), answers Monday at once, drops anything any agent posted so agents never answer each other, and forwards the question to the agent's own monday-<role> route. Proved September 28 with a real mention for each agent (update IDs in the Mission Control brief), plus refused unsigned calls, no loops, a repeated call running once, and the bridge restarting on its own.
8. Adding an agent: a row in scripts/monday_agents.json, the agent's own route, and one run of scripts/monday_signing_setup.py, which sets the callback URL through Monday's pre-release agents API (header API-Version: dev) with the agent's own key and saves the signing secret to its profile .env without showing it. No reconnecting. The role session writes what the agent does when mentioned. Every new role's launch checklist includes this (briefs/README.md), and the steps are in scripts/monday_bridge.md.
9. If the Mac is down, Monday's call fails, the person gets no reply, and nothing is queued: mention again once it is back. Whether Monday retries on its own is unverified. The Zapier routes behave the same way. After a reboot the Mac logs in automatically and the bridge, gateway, and tunnel all start by themselves.
10. Cosmo's and Apollo's mention instructions are starting points, to be tuned in their own sessions. Cosmo answers questions, takes new details, and redrafts the client reply; Apollo does what is asked, summarizes when nothing specific is asked, and since October 2 creates subitems only when a reply approves its proposal ("@Apollo create").
11. Monday's agents API is pre-release: if Monday changes it before it reaches a dated version, the setup script may need updating. The bridge itself does not use it.

Then: Celeste

12. Phase 1 only: monitor status, the one safe transition, deadline flagging. Cron-driven.
13. Phase 2 once phase 1 is trusted: document intake to Drive and Monday

Then: Atlas

14. Scope decision first: what questions it answers
15. Collect real VinSolutions reports and write the parser
16. Single-rooftop pilot before any multi-rooftop group

In parallel, as weekend items

• Google Chat channel setup (on the board, low priority)
• Fixing the Hermes git repository: the survey found committed backups containing secrets, large binaries, and runtime files; cleanup was completed September 27 with a filter that redacts webhook secrets on commit
• Deleting the safety copy of old history once the agents have run normally for a few days

Deferred deliberately

• Cosmo drafting templated creative work waits for the manifest-driven rendering pipeline, which waits for templatizing one Claude Design export to produce the first manifest schema
• Domain-wide Google Workspace delegation waits for a written scope and a disclosure to the team
• The Apple Business MDM enrollment of the Studio waits for Blueprints to exist; assigning it without policy caused a day-long lockout

Time estimates that were given: Apollo close-out is twenty minutes. Monday two-way is half a day for the first agent and under an hour for the second. The recaps port is half a day.

Open questions not yet decided

Team access

• Who approves what has not been decided and will be worked out scenario by scenario. Logan is not the standing approver. Propose-then-approve stands as a rule; the routing of approvals does not exist yet.
• Logan's access is a written scope and a trust conversation, not a permissions setting. The web interface is one shared workspace: everyone past Cloudflare Access sees everyone's sessions. Whether that stays acceptable as more people join is undecided.
• What Apollo should do when @mentioned, and whether it is always the same thing. "Summarize this thread" is a different design from "do whatever the mention asks."

Cosmo

• Decided in principle: the gap list is a pre-thought for the reviewing human, and Cosmo never carries the burden of resolving it. Still open: whether the draft text should also pose those gaps to the sender, or leave that wording to the person who sends it.
• Whether creative@ threads use #inbox/ or #all/ links. Filing uses #all/, which resolves regardless of where a thread has been filed. Settled September 27: the CR number never goes in the entry name. And reply_draft answers only the sender by default, not everyone the client copied; decide whether replies should keep the client's CC list.

Celeste

• Everything under "Open before building" in her section, above all: what identifies a document as belonging to a specific claim. If it is a Claim ID in the filename, intake is a parser. If it is inferred from context, it is a judgment call on every document and the design is different. Filing rules and process are not established; a human review step is wanted either way.

Atlas

• Atlas has not been contemplated beyond the name. Workshop first; everything in his section is input to that workshop, not a plan.

Architecture

• Whether to keep one shared memory store as the agents scale, or adopt an external memory provider with per-project scoping. The current position is to stay with plain Markdown files read on demand, because external providers inject recall as opaque model context rather than diffable text, which breaks the review gate. Revisit only when something actually strains.
• Whether profiles or skill bundles are the right unit for departmental separation. Current position: one shared memory, capability comes from skill bundles and tool surface, identity is presentation only. Profiles are for genuine confidentiality walls between competing dealer groups, if that ever arises.
• Whether Cosmo drafting templated work should post as Cosmo initially or whether a separate creative-production identity is needed. Six proper nouns (Mission Control, Apollo, Cosmo, Celeste, Atlas, Stratos) is already a lot for a five-person firm.

Credentials and safety

• The two Google OAuth client secrets and the dashboard password never left the Studio and sit behind Cloudflare Access. Whether to rotate them at all, given the disruption (Google rotation may force re-authenticating every Gmail wrapper), is undecided. Separately, Apollo's tools were decided October 1, 2026 (Tristan): trash_message and Monday execute_code are switched off (in effect at Mission Control's next restart), and create_items stays on for approved subitems. Cosmo created one board column (September 17, desktop session); whether to switch that tool off is undecided.
• Resolved: the fireflies-recap route was created late on September 23, 2026, is bound to Apollo, and runs the apollo-recap skill (see Apollo). The files do not record who created it.
• Service account keys (they start sk-ant-svc) work in Hermes since October 14, 2026: a local patch sends them as normal API keys, so their use is billed to the key (Rover is the first). Open: a profile with no Anthropic key does not stop; it quietly runs on the Claude Code sign-in on the Mac Studio. Whether to guard against that is Tristan's call (Mission Control brief).

Tooling

• hermes-webui stays for now because the Hermex iOS app depends on it, and that app is the piece Tristan wants to keep. There is no attachment beyond that. Open: whether a better way to manage Hermes exists that still serves the mobile need.