Easier AI Operating Model

Source Signals

Inputs:

• Anthony's guidance in this thread.
• Easier Notion department/SOP structure.
• The attached org chart showing decentralised autonomous delivery functions and centralised control functions.
• 8 Figure Agency Hermes field notes.
• Hermes official SOUL/profile/context model.

Interpretation of the Org Chart

The image is best treated as a map of capability areas that AI can support, not as a literal one-agent-per-box implementation.

Top-level capability areas:

• Strategic Leadership.
• Strategic Finance.
• Marketing.
• Sales.
• Client Services.
• Operations.
• Company Strategy.
• Admin.

Operational subfunctions include:

• content strategy, execution and distribution;
• lead generation strategy, execution, backend strategy and backend execution;
• new business development;
• inbound sales;
• coordination, media buying, visual creation, copywriting and funnel support;
• resource allocation and client services systems;
• tools/platform integration, analytics and reporting;
• leadership, project support, hiring, training and development;
• legal, bookkeeping and strategic partnerships.

AI Implementation Principle

Start with one COO / AI Ops Manager profile rather than a Founder EA.

Reason:

• Anthony does not primarily need an assistant persona.
• The first job is to design the operating system, context, roles, gates and agent creation process.
• Specialist agents can then be built from a shared soul and governed by the COO / AI Ops Manager.
• ContentOS, outbound and social are better as second-wave department agents after memory hygiene, approval gates and daily/weekly loops are working.

Proposed First Profile

Name: coo-ai-ops-manager

Purpose:

• Maintain the agency AI operating system.
• Convert Notion/SOP/business context into safe agent roles.
• Design and evaluate specialist agents.
• Become the primary development partner for the Hermes instance, gradually taking over the role Codex is currently playing in designing, improving and operating Hermes.
• Produce daily and weekly operating reviews across departments.
• Manage the agent backlog and context hygiene.
• Propose, not execute, connector changes.
• Enforce the memory filter so raw artifacts become useful digests, not bloated context.

Does:

• Read the vault.
• Draft role files.
• Draft SOPs.
• Draft Slack internal updates.
• Analyse approved Fathom digests or transcript extracts.
• Propose next agents.
• Maintain evaluation questions and scorecards.
• Produce daily and weekly reviews.
• Propose memory promotion and decay.

Does not:

• Send client messages.
• Write in external Slack channels.
• Change n8n workflows.
• Edit Airtable/Notion/Easier Now live records.
• Create credentials.
• Delete data.
• Spend money or alter contracts.

Daily and Weekly Loops

Anthony prefers daily plus weekly across different needs.

Daily loop:

• strategic priorities;
• cash/client risk;
• open loops;
• Slack/team signal summary later;
• Fathom meeting notes later;
• stuck systems;
• proposed next actions.

Weekly loop:

• department scorecard;
• SOP gaps;
• agent performance;
• client relationship risks;
• marketing/sales/fulfilment learning;
• decisions made and decisions avoided;
• next build priorities.

Slack Direction

Slack is the right messaging surface for Easier because it already maps to:

• internal team chats;
• external client chats;
• routine AI-generated updates/reports;
• future agent teammates.

Initial Slack policy:

• create int-agentops as the first internal agent operations channel;
• read internal public/private channels only after explicit installation scope;
• read client channels only after client/privacy policy is decided;
• do not read DMs initially;
• write only internal channels;
• use int-agentops first;
• all client-visible output is draft-only.

Later:

• daily COO updates in int-agentops after review;
• weekly AI Ops updates;
• ContentOS status updates;
• outbound/social production reports;
• client service reminders.

Fathom Direction

Fathom should be the meeting memory source.

Initial:

• manual approved meeting digest import.
• summaries marked confidential.
• COO / AI Ops Manager extracts decisions, commitments, risks and SOP updates from approved digests or transcript extracts.
• Full raw transcripts stay in Fathom by default; Hermes stores receipts, digests and links unless a specific transcript is approved for local storage.

Later:

• read-only Fathom receipts and digests.
• draft relationship and sales notes.
• Slack internal summaries for approval.

Obsidian Vault Placement and Portability

Markdown is small. A serious agency brain is still likely portable if it is mostly Markdown.

Rough sizing:

• plain Markdown notes: usually MBs to low hundreds of MBs;
• meeting transcripts: can grow to hundreds of MBs or a few GB over time;
• screenshots/assets/PDFs/video: can dominate storage quickly;
• retrieval indexes, embeddings and local models: commonly 1-10+ GB depending on tooling.

Recommendation:

• Keep the live vault on the server for Hermes access once activated.
• Keep it out of ordinary GitHub by default.
• Use Git only for public/internal-safe templates and maybe a separate sanitized vault.
• Add encrypted backups or encrypted git later if versioned portability is required.
• Store large attachments outside the vault and keep only receipts, digests and source links in Hermes.

The current n8n VM can hold a Markdown-first vault. It should not casually hold large indexes, model caches and attachments without disk monitoring.

Data Boundary Thinking

The point is not to keep useful data away from Hermes forever. Anthony wants agents involved throughout Easier over time. The safety model should therefore be based on maturity and action gates, not permanent departmental exclusion.

The early point is to avoid irreversible or high-trust mistakes while the system is immature.

Default allowed early:

• read notes;
• summarise;
• draft;
• classify;
• propose;
• create local Markdown drafts.

Danger zones:

• delete/bulk modify;
• send externally;
• change access;
• alter financial/legal records;
• modify ads/spend;
• overwrite client records;
• write to client-facing Slack.

Context Programming

Context should be systematic, not improvised.

Seed sources:

• Notion department pages.
• SOP Wiki.
• Our Tech.
• KPI/Goals.
• Our People/org chart.
• Market-message and ICP pages.
• ContentOS/outbound/social briefing docs once found.
• Easier Now product docs.
• Evernote only as Anthony-approved personal note source while Easier Now is still catching up.

Output:

• raw source captures;
• source receipts;
• working digests;
• compiled department pages;
• role pages;
• SOPs;
• eval examples;
• scorecards.

Immediate Next Build

Build deployment/vault-template/SOUL.md and the coo-ai-ops-manager role template first. Do not activate Hermes until those are reviewed.

Easier Now Direction

Easier Now is intended to become the source of truth for note-taking. Airtable is already becoming obsolete and should not be treated as a strategic memory destination unless a specific base is still useful.

In a few months, Easier Now should receive a second-brain structure that works in harmony with Hermes. The likely shape is:

• Easier Now as the user-facing capture and productivity surface;
• Hermes as the agent operating layer;
• the Markdown vault as the auditable working memory and migration bridge;
• receipts/digests/links rather than raw artifact hoarding.