Quick answer (TL;DR): An ops team’s AI “second brain” is a small set of living documents in a shared folder that gives the assistant persistent memory of your GTM stack. The core structure is a standing handoff (current state, read first every session), a master index, a stack map (every system, what it owns, which is the system of record), a stakeholder file, a glossary of definitions and field names, and an internal notes file. Beneath those sit one folder per recurring unit of ops work (workflows, integrations, tickets, reports) with one file per item. The assistant reads these at the start of every session and writes back at the end. Three disciplines keep it working: one source of truth per thing, version-stamped updates, and no silent duplicates.
This is the practical, copy-this-structure companion to using AI like a colleague, not a vending machine. If you accept that shared memory is what makes AI useful, this post is the blueprint.
Why files, not chat history
Chat history is a poor long-term memory for a team. It’s linear, hard to search, scattered across people and devices, and invisible to a fresh conversation. A teammate’s new chat can’t see the lead-routing discussion you had yesterday in a different thread.
The fix is to move the memory into documents. Files are durable, structured, searchable, editable and readable by every session and every teammate. As a bonus, the same files are the documentation most inherited portals don’t have.
The shape that works is a mesh: a few top-level files that describe your world, with folders beneath them for recurring work. You don’t need our exact files. You need the shape.
The top-level files
These describe your stack and change slowly once written. Create them first.
1. The standing handoff (the most important file)
This is the team’s single source of truth for current state and the first thing the assistant reads every session. It holds:
- Current state: what’s in flight across the stack right now.
- What shipped recently: the workflow that went live, the field that was retired.
- What’s pending, blocked or waiting on others: “waiting on sales ops to confirm the territory change.”
- The protocol: how sessions work (read this first, write back at the end, what needs approval).
- A change ledger: a dated list of what each session did, so parallel work can be reconciled.
If someone could only open one file, this is the one. Put a version number and timestamp in the header every time it’s updated, so the newest copy is always obvious.
2. The master index
A simple map of everything else, so a fresh session or a new teammate can get oriented in seconds. One line per file, with a note on what it’s for.
3. The stack map
This is the ops-specific file most teams are missing:
- Every system in the GTM stack: CRM, marketing automation, enrichment, routing, attribution, BI.
- Which system is the system of record for each object (contacts, accounts, opportunities, campaigns).
- How data moves between them: sync direction, field mappings, known exclusions, sync frequency.
- Who owns each integration and where its credentials and settings live.
4. Team preferences and hard rules
How the team works:
- Working conventions (“every workflow gets a named owner and a description”).
- Communication preferences for stakeholder updates.
- Hard rules that apply to everything: “never activate a workflow that edits lifecycle stage without a backup export”, “no bulk updates on Fridays”.
5. Stakeholders
The people who depend on the stack:
- Who consumes which report or number: the CRO’s pipeline view, finance’s bookings reconciliation.
- Who approves what: routing changes, new fields, scoring changes.
- Who needs a heads-up, and why.
Be honest about the real dynamics. A good ops lead knows the politics; the memory should too.
6. Glossary
Your shared language:
- Lifecycle stage and lead status definitions, as actually configured.
- Field API names, and the ones that look alike but aren’t.
- Campaign and UTM naming conventions.
- Dashboard and report links.
This file alone prevents a large amount of “wait, which MQL are we talking about?” friction.
7. Internal notes
The honest internal layer:
- Known data quality problems that haven’t been fixed yet.
- Workarounds currently in place.
- Sensitive context that’s worth remembering but not worth putting in a deck.
The folders: one per recurring unit of ops work
Beneath the top-level files, create a folder for each type of recurring work. For most marketing-ops and RevOps teams that means:
- Workflows and automations: one file per HubSpot workflow, Marketo program or Salesforce flow that matters.
- Integrations: one file per connector or sync.
- Requests and tickets: one file per meaningful piece of work.
- Reports and definitions: one file per board-level metric and how it’s calculated.
Each item file holds:
- Scope: what this thing does and why it exists.
- IDs and links: workflow IDs, object names, the ticket number, the dashboard URL.
- A dated log: append-only, newest on top.
- An internal notes section: item-specific caveats.
The item file is the source of truth for that item. Status might also live in your ticketing tool, but the context and decisions live here.
The rituals that bring it to life
Opening ritual. At the start of every session, the assistant reads the standing handoff and the relevant files before doing anything.
Closing ritual. Before the session ends, the assistant writes back what changed (the handoff, the item files, the change ledger) and updates the timestamps.
The reconcile (periodic). Every so often, the assistant sweeps every place requests arrive (Slack, email, the ticket queue, the sales team’s shared sheet) and cross-checks them against your tracker to surface anything dropped. It gets its own post later in the series.
The rules that prevent chaos
- One source of truth per thing. No duplicate files for the same workflow. No “routing_v2_FINAL”.
- Version-stamp updates. Mark each new version with a number and timestamp so stale copies are obvious.
- Append-only logs. Add to history rather than rewriting it. The audit trail is valuable when someone asks why a field changed.
- Separate internal from external. Honest caveats go in internal notes; only what serves the audience goes in stakeholder deliverables.
- Capture the principle, not just the instance. “Why we exclude records with open opportunities from merges” is more useful next quarter than “merged 400 contacts”.
A realistic note on tool limits
Every storage tool and assistant has sharp edges. Some assistants can create and read files but not edit them in place, so an “update” is really a recreate, which is why version-stamping matters. Some have file-size limits. Some integrations are unreliable.
Run a capability audit early (it gets its own post) and design your conventions around the real constraints, not the ideal ones.
A minimal starter version
If the full structure feels like a lot, start with three files and add the rest when you feel the need:
- Standing handoff: current state and how the team works.
- Stack map: systems, systems of record, how data moves.
- One folder for workflows, one file per workflow that matters.
Add the stakeholder file, glossary and internal notes when you notice people re-explaining the same things.
What you get
Once the structure is in place and the rituals are running, a session opens with the assistant already aware of the state of the stack. Nobody pays the re-explanation tax. And you have something most teams lack: written documentation of how your GTM systems actually work, which survives any one person moving on.
Frequently asked questions
What files does an ops team’s AI second brain need? At minimum: a standing handoff, a stack map showing systems of record and data flows, and one folder per type of ops work with one file per item. Add a master index, stakeholder file, glossary and internal notes as needs grow.
Where should we store it? In a shared folder the whole team and the AI assistant can reach, so the assistant can read context at the start of a session and write updates at the end. The files need to be durable, editable by the team and readable by every session.
Is this the same as our runbook? In practice it becomes one. The stack map, glossary and workflow files are exactly what a new ops hire, an agency or an auditor needs. You get documentation as a side effect of working with AI.
How do we stop it becoming a mess? One source of truth per item, a version stamp on every update, append-only logs, internal notes kept apart from stakeholder deliverables, and reusable principles recorded rather than one-off specifics.
Do we need technical skills to build this? No. It’s a folder of plain documents and two habits. Knowing your stack matters far more than any technical skill.
This is Part 2 of The Ops Operating System. Next: what happens when several teammates run AI sessions against the same files, and the protocol that stops them overwriting each other.
Can’t fill in the stack map with confidence? Our GTM Systems Audit documents your systems of record, syncs and workflows so your team, and its AI, start from the truth.