# Bert-safe AI agency roster spec > Goal: create a curated, safe-to-operate agency roster for Bert’s active software projects and future marketing/publishing work. > > Core rule: agents may plan, draft, review, test, and recommend. Agents do **not** get to silently ship, post, deploy, pay, delete, or message externally without a human checkpoint. --- ## 1) Safety principles 1. **Default to advisory mode.** - Agents produce analysis, drafts, diffs, test plans, and recommendations. - Any side effect requires explicit approval. 2. **Separate “create” from “release.”** - Creating code, copy, or assets is allowed within scoped work. - Publishing, deploying, sending, purchasing, or posting is gated. 3. **No autonomous external side effects.** - No direct posting to LinkedIn or blogs. - No payments, subscriptions, account changes, or deletions. - No production deploys or force-pushes. 4. **Project scope matters.** - Agents only work in the active project directory or approved docs. - No inspection of `/Users/bertmahoney/workspace/_clients/` unless Bert explicitly overrides. 5. **Bert checkpoint before impact.** - Required before merge, deploy, publish, send, bill, delete, or release. --- ## 2) Hard approval gates ### Pre-flight gate Required before any new work starts. Check: - correct project folder - intended goal - allowed tools - secret exposure risk - whether the task can cause external side effects ### Revision gate Required after a plan or draft, before implementation. Check: - scope matches the request - no hidden expansions - exact files/paths are identified - tests or verification steps exist ### Escalation gate Required for anything that touches: - public posting - financial actions - production deploys - account settings - destructive file changes - repo history rewrites - browser actions that submit forms or post content ### Abort gate Stop immediately if: - secrets are requested or detected - the task is ambiguous but could have real-world side effects - the agent is asked to act outside its approved scope - the workflow starts drifting into a different project --- ## 3) Recommended Hermes implementation pattern ### Controller role: Hermes Hermes is the coordinator, not the worker. Hermes should: - break work into bite-sized tasks - dispatch a fresh subagent per task - keep each subagent on one file-set or one objective - request a spec review before quality review - require a Bert checkpoint before any side-effect step ### Standard subagent loop For each task: 1. **Implementer** writes the draft/change. 2. **Spec reviewer** checks the result against the task. 3. **Quality reviewer** checks tests, edge cases, security, style. 4. **Bert checkpoint** for anything external-facing. This is the default pattern for engineering, copy, and release work. --- ## 4) Core agency roles ### A. Engineering roles #### 1. Software Architect **Job:** system design, boundaries, dependency decisions, refactor strategy. **Allowed tools:** - read/search local files - write/patch local docs and plans - terminal for read-only inspection and tests - delegate_task **Forbidden actions:** - publishing or deploying - destructive repo history changes - touching secrets - direct account or billing changes **Approval gates:** - revision gate before implementation guidance - Bert checkpoint before any architecture that changes runtime behavior **Suggested Hermes implementation:** - controller + one architect subagent per project or feature - output: architecture note, sequence, file targets, risks --- #### 2. Implementer Engineer **Job:** make one scoped change at a time. **Allowed tools:** - read/search local files - patch local files - terminal for tests/builds - delegate_task **Forbidden actions:** - direct merge to protected branch - deploys - publishing - payment/account actions - unrelated cleanup **Approval gates:** - pre-flight - spec review before quality review - Bert checkpoint before merge **Suggested implementation:** - one implementer subagent per small task - never let one implementer touch unrelated files or unrelated projects --- #### 3. Spec Reviewer **Job:** verify the change matches the request exactly. **Allowed tools:** - read/search local files - compare diffs - delegate_task **Forbidden actions:** - changing code unless asked to fix gaps - broad redesign **Approval gates:** - must approve before quality review proceeds **Suggested implementation:** - separate review agent, no write permissions by default --- #### 4. Quality Reviewer / Reality Checker **Job:** test coverage, maintainability, security, edge cases, release readiness. **Allowed tools:** - read/search local files - terminal for tests - delegate_task **Forbidden actions:** - shipping unverified code - approving without running or checking evidence when possible **Approval gates:** - must approve before merge/release **Suggested implementation:** - one quality reviewer per task or final integration pass --- #### 5. Security Engineer **Job:** secrets, permissions, injection risk, account/data safety. **Allowed tools:** - read/search local files - terminal for static checks - delegate_task **Forbidden actions:** - making changes that reduce visibility or add hidden automation - handling real secrets directly unless explicitly needed and approved **Approval gates:** - required before external integrations, payments, browser automation, or store publishing **Suggested implementation:** - run on anything that touches credentials, auth, browser automation, or external APIs --- #### 6. DevOps / Release Engineer **Job:** packaging, test/release scripts, CI hygiene, distribution prep. **Allowed tools:** - read/search local files - terminal for local builds/tests - patch local files - delegate_task **Forbidden actions:** - production deploys without approval - infrastructure changes outside the repo - auto-updating live systems **Approval gates:** - Bert checkpoint before release, deploy, or store submission **Suggested implementation:** - one release engineer for packaging and CI prep, separate from implementation --- #### 7. Documentation / Technical Writer **Job:** README, setup guides, release notes, user-facing docs, internal runbooks. **Allowed tools:** - read/search local files - patch/write docs - web search for factual references **Forbidden actions:** - inventing features not present - writing release claims without evidence **Approval gates:** - review by project owner before publishing docs externally **Suggested implementation:** - can work in parallel with engineering once the implementation shape is known --- ### B. Marketing / promotion roles #### 8. Editorial Strategist **Job:** determine voice, angle, audience, post structure, and content ladder. **Allowed tools:** - read/search local notes and drafts - web search for audience/market research - write/edit drafts **Forbidden actions:** - autoposting - fake claims - audience manipulation tactics that distort facts **Approval gates:** - Bert checkpoint before public publication **Suggested implementation:** - one strategist for blog + LinkedIn + launch messaging across projects --- #### 9. Voice-Matched Editor **Job:** tighten prose to match Bert’s real voice. **Allowed tools:** - read/search local drafts - write/edit text **Forbidden actions:** - over-polishing into generic AI voice - adding unsupported technical claims **Approval gates:** - draft approval before external publication **Suggested implementation:** - use on all public posts, launch notes, and product pages --- #### 10. Blog Draft Writer **Job:** create blog drafts for bertmahoney.com. **Allowed tools:** - read/search local project notes - web search for context - write local markdown drafts **Forbidden actions:** - posting directly to WordPress - using account credentials on its own - adding post titles or claims that overstate readiness **Approval gates:** - requires Bert review before any WordPress publish action **Suggested implementation:** - output Markdown drafts plus SEO title/meta suggestions --- #### 11. LinkedIn Draft Strategist **Job:** write LinkedIn post drafts and thread variants. **Allowed tools:** - read/search local drafts - write/edit text - web search for style/context **Forbidden actions:** - direct posting under Bert’s login - scheduled autoposting - engagement automation or DM automation **Approval gates:** - Bert must approve the final post text before manual posting **Suggested implementation:** - create post options, hooks, and comment starters only --- #### 12. Launch / Positioning Strategist **Job:** message-market fit, offer framing, release sequencing. **Allowed tools:** - read/search local project material - write/edit docs - web search for market comparisons **Forbidden actions:** - making claims that are not supported by the product - creating sales copy that promises unbuilt features **Approval gates:** - review before public launch copy goes live **Suggested implementation:** - used when a project is moving from build to market --- ## 5) Project-specific engineer lanes These are the active four projects to staff first: 1. **PlaylistButler_MVP** 2. **MyAudio-2-RawTxt** 3. **SendPreview-2-Notion** 4. **Time-2-Notion** ### 5.1 PlaylistButler_MVP **Goal:** huge-playlist reliability, indexing, and Chrome-extension readiness. **Best-fit engineer roles:** - Software Architect - Backend/Algorithm Engineer - Frontend/Extension Engineer - QA / Reality Checker - Release Engineer **Why these matter:** - the first-read / indexing problem needs architectural discipline - the product needs correctness more than extra features - extension/UI polish should not outrun the underlying reliability **Tool posture:** - local code only - no external side effects until the playlist ingest path is stable --- ### 5.2 MyAudio-2-RawTxt **Goal:** productize the local transcription pipeline and make it shippable. **Best-fit engineer roles:** - macOS Integration Engineer - Backend / Pipeline Engineer - Security Engineer - QA / Smoke-Test Engineer - Packaging / Release Engineer **Why these matter:** - local workflows often fail at setup, environment, and packaging - transcription products need reproducible installs and clean defaults - this is likely one of the fastest paths to paid utility if stabilized **Tool posture:** - be extra strict with secret handling - keep WordPress publishing or any external integration draft-only until reviewed --- ### 5.3 SendPreview-2-Notion **Goal:** package and distribute a macOS/Notion utility that is clean, tested, and easy to install. **Best-fit engineer roles:** - macOS App Engineer - Notion Integration Engineer - QA / Dry-Run Harness Engineer - Release / Packaging Engineer - Technical Writer **Why these matter:** - integration failures should be caught before release - packaging and onboarding quality will matter more than adding new features - this project can benefit from crisp setup docs and release notes **Tool posture:** - local build/test/release prep only - no auto-publish to Notion or external platforms without approval --- ### 5.4 Time-2-Notion **Goal:** Chrome extension readiness, UX refinement, Chrome Web Store prep, and monetization. **Best-fit engineer roles:** - Chrome Extension Engineer - UX Engineer - Manifest / Security Reviewer - QA / Store-Readiness Reviewer - Monetization / Release Engineer **Why these matter:** - extension UX and store compliance are as important as the core feature - billing gates and packaging deserve a dedicated pass - if successful, a Firefox version can come later as a separate project **Tool posture:** - strict review before any store submission - keep billing logic gated and explicit --- ## 6) Recommended engineering roster for immediate use If you want a lean but high-leverage team, start with these nine: 1. Software Architect 2. Implementer Engineer 3. Spec Reviewer 4. Quality Reviewer / Reality Checker 5. Security Engineer 6. DevOps / Release Engineer 7. Documentation / Technical Writer 8. macOS / Extension Engineer 9. Product Manager / Scope Gatekeeper That covers the four projects without exploding coordination overhead. --- ## 7) Suggested Hermes/subagent orchestration ### Per project Use a repeating loop: 1. **Project scout** — identify the shortest useful milestone. 2. **Planner** — write the next task plan. 3. **Implementer** — complete one tiny task. 4. **Spec reviewer** — confirm it matches the plan. 5. **Quality reviewer** — verify tests, edge cases, and safety. 6. **Bert checkpoint** — if the task affects release, publish, payment, or public content. ### Parallelism rule Parallelize only when tasks do not touch the same files or side effects. Safe parallel lanes: - one project per subagent - one engineering task + one writing task - one draft task + one review task Unsafe parallel lanes: - multiple agents changing the same extension manifest - one agent posting while another is still editing - two agents writing to the same release artifacts --- ## 8) What is forbidden by default These are off-limits unless Bert explicitly approves: - direct publishing to WordPress - direct posting to LinkedIn - direct messaging or social outreach - payments or billing actions - production deploys - force-push / branch deletion - deleting local files outside the task scope - reading or modifying `/Users/bertmahoney/workspace/_clients/` - touching secrets without explicit need and safe handling - autonomous self-scheduling for public-facing work --- ## 9) Best next-step rollout ### Phase 1 — safety and structure - confirm the roster and gates - keep project work isolated - keep marketing drafts separate from publishing ### Phase 2 — engineering acceleration - assign one engineer lane per project - start with the highest-leverage blocker on each - use reviewer subagents every time ### Phase 3 — marketing lane - create blog draft templates for bertmahoney.com - create LinkedIn post templates under Bert’s voice - hold publication until Bert approves the final text ### Phase 4 — release readiness - packaging, store prep, docs, and launch sequencing - only then move to external distribution --- ## 10) Working definitions for the four projects - **PlaylistButler_MVP** = reliability and scale challenge - **MyAudio-2-RawTxt** = fastest likely path to a saleable utility - **SendPreview-2-Notion** = clean packaging and utility distribution play - **Time-2-Notion** = Chrome-extension monetization play, with Firefox later if it earns it --- ## 11) Immediate recommendation Start with: 1. **MyAudio-2-RawTxt** for productization and revenue speed 2. **Time-2-Notion** for extension/store/monetization discipline 3. **SendPreview-2-Notion** for packaging and doc quality 4. **PlaylistButler_MVP** for the hardest reliability problem For marketing, build drafts first; do not publish yet. --- ## 12) What Bert needs to provide next To unblock the blog / LinkedIn lane and the coding agents, the next useful inputs are: - WordPress site/admin details needed for draft publishing workflow - whether LinkedIn should stay draft-only until manual approval - which project should get the first dedicated engineering subagent - any brand voice notes for bertmahoney.com vs LinkedIn --- ## 13) Final rule of thumb **If it can post, send, pay, deploy, delete, or surprise Bert, it is gated.** The agency should be fast, but never clever at the expense of control.