How We Work With the Agent

1 · The Core Principle — Guide, Don't Instruct

The most important thing to understand about working with this agent is that it is not a command-line tool. It has judgment, context, memory, and the ability to apply professional-level reasoning across dozens of disciplines simultaneously. The moment you start treating it like a machine that needs step-by-step instructions, you lose most of its value.

The right mental model is a highly capable collaborator who already knows the project, the clients, the tools, and the constraints — and who is waiting for you to tell them the goal, not the method. Your job is to describe what success looks like. The agent figures out how to get there.

Every stat above came from conversational requests — no scripts, no technical instructions, no step-by-step commands. Just clear goals stated in plain English, with approval gates at the right moments.

2 · Why Less Is More — The Case Against Over-Explanation

This is counterintuitive, but more detail in a request often produces worse results. Here's why: when you prescribe the method, you remove the agent's ability to apply judgment. It will follow your instructions exactly — even if your instructions miss something important, or if a better approach exists.

When you state the goal, the agent applies everything it knows to find the best path — including things you didn't know to ask for.

The One Exception

Be specific about constraints and rules, not methods. The distinction: a rule is "never post to account 54565" — that's a boundary the agent must respect. A method is "first check the account ID, then compare it to 54565, then if they match, don't post" — that's telling the agent how to think, which it already knows how to do. State the rule once, clearly. The agent applies it across the entire session.

3 · Speech Patterns That Work

These are the actual phrasing patterns that produce the best results — pulled from real sessions. They share a common structure: goal + constraint + approval gate. Never method.

3.1 · The Audit Trigger

Use this to initiate a full check before any committed action. The word "audit" signals: do not proceed, just report.

3.2 · The Conditional Continuation

Approval with a built-in quality gate. You grant permission to proceed, but only if the agent's own verification passes. This is a trust-but-verify unlock.

3.3 · Reference-by-Example

Pointing to an existing example is always more powerful than describing what you want. A URL replaces hundreds of words and eliminates ambiguity.

3.4 · The Standing Rule

State a constraint once, clearly, in plain language. It becomes a permanent rule for the session — and if saved to memory, carries across all future sessions. You never need to repeat it.

3.5 · The Goal Statement

Describe the business outcome, not the technical method. The agent knows how to achieve outcomes. It needs to know what the outcome is.

3.6 · The Simple Unlock

After a review, the shortest phrase fully unlocks a large block of autonomous work.

4 · Real Requests, Real Results

These are word-for-word requests from actual sessions — exactly as typed, with annotations showing what made each effective.

4.1 · The Mimi's Campaign Build

4.2 · The Report Style Correction

4.3 · The Thumbnail Problem

4.4 · The Security Constraint

5 · The Review Gate Pattern

The review gate is the most important structural pattern in how Joe works. It's a two-step where nothing irreversible happens until you've explicitly seen it and said yes. This is where the "trust the process" part lives — you're not trusting blindly, you're trusting after a verified checkpoint.

5.1 · What Triggers a Review Gate

5.2 · The Gate Is In the Language

You don't need to explicitly say "stop and wait for approval." Certain phrases signal the gate automatically:

• "show me" → present without committing
• "if good" → conditional — implies review first
• "verify [X] then" → check before proceeding
• "as long as" → built-in condition that must pass
• "don't [commit/schedule/post/deploy] until I review" → explicit hold
• "open the url for me when done" → success criterion — agent knows the task isn't done until you've seen it

5.3 · Standing Gate for All Sessions

This was stated once by Joe early in the Mimi's campaign work. The agent treats it as a standing rule across all Vivere client sessions — no post is scheduled, no file is deployed, no irreversible action is taken without a presented preview and explicit approval. This is not re-stated each session; it lives in memory.

6 · The Safeguards System

The safeguards are what make it safe to say "go ahead" and mean it. They are layered: memory-level rules that persist forever, session-level constraints stated at the start, and task-level review gates at decision points.

6.1 · The Three Layers

6.2 · Known Permanent Rules (Memory-Level)

6.3 · The Security Constraint Pattern

Security constraints follow a simple pattern. State them in plain English. The agent maps them to technical identifiers internally. You don't need to know the account ID to set the rule:

7 · Parameters, Memory & Directories

These are the actual technical underpinnings — the persistent infrastructure that carries context between sessions and makes the conversational model work without restarting from zero each time.

7.1 · The Memory System

C:\Users\sutli\.claude\projects\C--Users-sutli\memory\
├── MEMORY.md               ← index of all memory files (read first every session)
├── project_mimis-deploy.md ← Mimi's deploy state, nameserver status
├── project_mimis-social-pipeline.md ← Mimi's accounts, CDN, Blotato IDs
├── project_the-yard.md     ← The Yard site build state
├── project_allbizco.md     ← AllBiz Co site state
├── project_sol-codebase-structure.md ← SOL site canonical structure
├── feedback_model-usage.md ← how Joe prefers to use Claude models
└── [more per project]

Memory files use four types: user (who you are, how to work with you), feedback (corrections and confirmations), project (current state of each client build), reference (where to find things in external systems). The agent saves to memory when something is worth carrying to future sessions — standing rules, account IDs, deploy methods, project state.

7.2 · The Session Startup Block

For any campaign or client session, saying this at the start loads all relevant context without re-explaining anything:

7.3 · Directory Structure

C:\Users\sutli\Desktop\Developer\
├── Media Channels\
│   └── Mimis Sweet Treats\
│       ├── 4th of July Campaign\
│       │   └── static-cards\      ← all campaign assets + thumbs\
│       └── campaign-report\       ← report HTML + deploy.ps1
├── Vivere Clients\
│   ├── Proof of concept\
│   │   ├── 02_scripts\            ← Python pipeline scripts
│   │   ├── 06_pipeline\           ← explainer engine queue (MT01–08)
│   │   ├── playbook-deploy\       ← vivere-playbook.pages.dev
│   │   └── agent-playbook\        ← this document
│   ├── [Client Name]\             ← one folder per client site
│   │   └── [site files]
│   └── allbizco\                  ← allbizco.com build
└── .claude\
    └── worktrees\                 ← isolated build environments

7.4 · The Tools That Power This

7.5 · Cloudflare Pages Deploy Pattern

Every Vivere site follows the same deploy pattern. You never need to run the command yourself — say "deploy it" and the agent runs:

npx wrangler pages deploy . --project-name [project-name] --branch main --commit-dirty=true

# Examples:
#   mimis-campaign-report → mimis-campaign-report.pages.dev
#   vivere-playbook       → vivere-playbook.pages.dev
#   vivere-agent-playbook → vivere-agent-playbook.pages.dev
#   allbizco              → allbizco.pages.dev / allbizco.com

8 · The Trust Framework — How the Whole System Holds Together

The reason you can say "go ahead" to 46 posts scheduling without anxiety is that trust is earned incrementally through a consistent process. Here's how that process works:

8.1 · The Four-Stage Flow

8.2 · The Agent Surfaces Decision Points

The agent doesn't hide problems — it surfaces them as they appear. When it finds something wrong during the Build phase, it stops and tells you before proceeding. You don't need to anticipate everything; the agent catches what you didn't know to ask about.

8.3 · The Learning Loop

Every correction you make becomes a lesson that improves future sessions. When something goes wrong and you tell the agent plainly, it saves the fix to memory so the same error doesn't happen again.

9 · How to Correct Without Breaking Flow

When something isn't right, the way you correct it matters. A clear plain-English redirect keeps momentum. Over-correcting with technical instructions creates confusion and can lock the agent into a wrong approach.

9.1 · The Right Way to Redirect

9.2 · Correction Language That Works

9.3 · What Not to Do When Something Is Wrong

• Don't write a paragraph explaining what's wrong. One clear sentence is better. "Wrong style — here's the example" beats three paragraphs of style description.
• Don't try to diagnose the technical cause yourself. Describe the symptom. The agent diagnoses. Joe's "blank black screen" led to a complete explanation of embedded poster art vs. platform frame decoding — no technical diagnosis from Joe required.
• Don't list every fix needed. If the whole approach is wrong, say it's wrong and provide the correct reference. The agent rebuilds correctly; you don't patch it.
• Don't abandon the session. If you're getting something wrong, redirect in plain English. The context built up in the session is valuable — keep going.

10 · For Mike — Consistency Guide

If you're joining Vivere's workflow, this section is your starting point. The goal is for any session you run to feel like a continuation of Joe's sessions — same outcomes, same quality, same standards. Here's what to know before you start.

10.1 · The Most Important Things

10.2 · How to Start a Session

10.3 · The Quick Reference — What to Say

10.4 · Account IDs — Use These, Don't Guess

10.5 · The One-Page Summary