Support

How CellCog Uses CellCog

CellCog is built with CellCog. Every feature, every bug fix, every customer email, every document — all developed and managed with our own AI agents. This guide walks through the real setups we use every day, so you can see how to get the most out of the platform.


The Philosophy

All of CellCog's intelligence needs are handled by CellCog agents. We make very few exceptions. The only AI tool we use is the one we're building — which means we feel every rough edge, and we fix them because we need them fixed ourselves.

Every setup below describes real workflows we run daily, including the specific tools and connections we use.


The Core Strategy: One Repository, One Source of Truth

You'll notice something across all our setups: almost every one connects to our main repository via Cowork. This isn't accidental — it's the most important architectural decision we've made for working with AI agents.

We've been carefully developing our main repository to be a single source of truth for the entire company. It hosts:

  • All application code (frontend + backend)
  • Infrastructure and deployment configurations
  • Customer support documentation
  • Design documents and system architecture
  • Brand colors, assets, and style guidelines
  • Database connection instructions
  • Agent prompts and configurations

By keeping everything in one structured place, we only need to make one connection (Cowork → main repository) and the agent has access to virtually everything about the company. It can research our codebase, read our docs, check our brand guidelines, understand our infrastructure — all from a single working directory.

This is what makes the setups below surprisingly simple. The connections look minimal (often just "Cowork on our main repository"), but the real power is in what that repository contains. The more structured and comprehensive your repository is, the more capable your agents become.


Setup 1: The Coding Agent (Most Used)

Mode: Agent
Connections: Cowork on our main repository

This is our primary development workflow. Here's how it works:

  1. A developer clones the main repository to their local machine
  2. They start the backend and frontend servers locally, with all necessary secrets and environment variables configured
  3. They open CellCog, enable Cowork, and set the working directory to the repo root
  4. The agent explores the codebase, understands the project structure, and starts building

The developer acts as a co-pilot — providing feedback, testing changes in the browser, sharing screenshots, and guiding direction. The agent writes the code, the human validates it works.

Tools & Connections

  • Cowork pointed at the git repo
  • Local servers running (backend + frontend)
  • Developer reviews agent commands via the Cowork approval system

Roles Within a Single Session

A single coding session often spans multiple roles. The same agent naturally transitions through:

  • Product Manager — analyzing requirements, defining scope
  • Prompt Engineer — designing and refining agent prompts (we build AI agents, after all)
  • Software Engineer — writing the actual code
  • Security Engineer — reviewing for secrets, permissions, vulnerabilities
  • Infrastructure Engineer — handling deployment configs, startup scripts

We don't switch agents between these roles — the same session handles all of them because the agent has full context of everything that's happened.

The Marketing Bonus

Once development is done, the same agent also drafts the product update blog post. Since it has deep context of exactly what was built and why, it produces highly specific, accurate marketing content. This is one of the unexpected benefits of single-session multi-role work — the agent that built the feature is the best one to announce it.

Command Review: Our Evolution

In the early days, we reviewed every single command the agent wanted to run on our machines — including reads. This was invaluable for understanding how agents think and building trust.

Now we've relaxed: we auto-approve reads and writes inside the git-tracked repo. But we still review all terminal commands and anything outside the working directory.

Our recommendation: Start cautious. Review everything. As you build confidence in how the agent operates, gradually relax your auto-approve settings. If you're working outside a git repo, always review every command.


Setup 2: Multi-Session Development (Large Features)

Mode: Agent
Connections: Cowork on our main repository

Some features are too large for a single session. Our billing system took 8-9 sessions. When this happens, we manage a careful handover process:

The Handover Protocol

We develop on a feature branch (not the main branch). This is critical for the multi-session strategy because it gives each new session a clear way to understand what changed.

Ending a session:

  1. Identify a checkpoint — a natural stopping point where the feature is partially complete but stable
  2. Ask the agent to write two documents:
    • A system design doc of what's been built so far
    • A handover doc of what still needs to be done
  3. Ask the agent to "critically self-review" both documents before ending

Starting the next session:

  1. Give the new agent the system design doc and handover doc
  2. Ask it to review the git diff against the main branch — e.g., "What are all the changes that have been made in this repo compared to the main branch?" This is the most critical step. The agent reads the actual code changes from all previous sessions, not just the summary docs.
  3. Once the agent is comfortable with all three inputs (design doc + handover doc + git diff), development continues

These documents get continuously updated across sessions — each session appends its progress to the design doc and updates the handover doc with remaining work.

Why This Works

The three inputs give the new session a complete picture:

  • System design doc = the architecture and decisions made
  • Handover doc = what's left to do
  • Git diff = the actual code changes — this grounds the agent in reality, not just summaries

Session 5 doesn't need to rediscover what sessions 1-4 built — it reads the design doc, understands the remaining work from the handover, and sees exactly what code was written via git diff.

The Cost Trade-Off

Multi-session development is inherently more expensive. A significant portion of tokens in session 2+ is spent on the agent understanding previous work — reading docs, analyzing git diffs, building context. This is expected and intentional. We optimize for accuracy over cost, because the cost of bugs in production is always higher than the cost of thorough context-loading.

Tip: Ask the agent to "critically self-review" the design doc before ending a session. This catches inconsistencies and ensures the next session gets clean context.


Setup 3: Deep Research Coding Agent (Complex Work)

Mode: Agent Team or Agent Team Max
Connections: Cowork on our main repository

For our most complex engineering challenges, we combine Agent Team mode with Cowork. This gives us a deep research coding agent — multiple agents that research deeply, debate approaches, and then implement directly in our codebase.

We used this setup to improve our own deep research protocols. The agents analyzed our existing system, researched cutting-edge techniques, and then implemented improvements — essentially improving themselves.

This is a unique capability: a deep reasoning, multi-agent system that can simultaneously research state-of-the-art approaches AND write production code. To our knowledge, no other platform combines deep research with direct code execution in a single workflow.

When to Use This

  • Architecture decisions that need research (e.g., "what's the best approach for X?")
  • Performance optimization where you need to understand the problem deeply before coding
  • Any work where the cost of a wrong approach is high and you want multiple perspectives before committing

Setup 4: Customer Support Agent

Mode: Agent
Connections: Gmail + Cowork on our main repository

This is how we handle customer emails — including the one that inspired this entire documentation effort.

The Workflow

  1. Connect Gmail as a tool so the agent can read customer emails
  2. Connect Cowork on the main repository so the agent can research our codebase and support docs
  3. Ask the agent to read a specific email thread
  4. The agent researches the customer's questions — diving into the codebase, reading design docs, checking support guides
  5. It suggests a response (or in some cases, identifies product improvements needed first)

What Makes This Powerful

Customer questions often require deep understanding of how the product actually works — not just what the docs say. By giving the agent access to both the email and the codebase, it can trace a customer's confusion to the actual implementation and provide precise answers.

Some customer emails arrive in different languages. The agent reads them, researches in English, and drafts responses in both the customer's language and English.

For complex queries, the agent sometimes identifies that the best response isn't just an answer — it's a product improvement. In those cases, the agent makes foundational changes to the codebase first, then drafts the response referencing what was fixed.


Setup 5: Document Management & Legal

Mode: Agent
Connections: Cowork on a docs folder
Project: CellCog Docs Management
Agent Role: Global Sales Tax Expert

We use CellCog for managing legal and compliance documents — company incorporation filings, sales tax registrations, state-specific forms, and more.

How It Works

  • A dedicated project ("CellCog Docs Management") holds all our legal documents
  • A dedicated agent role ("Global Sales Tax Expert") has instructions for handling tax compliance across jurisdictions
  • Cowork is connected to a local directory where we store our documents
  • The agent guides us step-by-step: which forms to fill, what information goes where, what emails to send to which agencies

It works like having a legal assistant who knows your entire document history. The agent role's memory accumulates knowledge about our specific filings, deadlines, and jurisdiction requirements across sessions.

We still work with actual legal counsel for complex matters, but this agent handles the bulk of the operational work with high accuracy.


Setup 6: Data Analysis

Mode: Agent
Connections: Cowork on our main repository

When we need to analyze production data, we don't use a separate analytics platform — we use CellCog.

The Workflow

  1. Connect Cowork to the main repository (which contains database connection instructions and brand colors)
  2. Describe the analysis needed
  3. The agent writes read-only scripts to fetch data from our production database
  4. We carefully review each script before approving execution
  5. The agent analyzes the results and generates a PDF report — styled with our brand colors pulled from the repo

Important: We review database scripts very carefully. The agent writes the script, we verify it's read-only, then we approve it via Cowork. For any write operations (like migrations), we review line by line.


Setup 7: An Always-On AI Employee

Surface: AI Employees
Connections: Cowork on our main repository + Gmail

Beyond interactive chats, we hire AI employees for standing, recurring work that shouldn't wait for a human to start it. An AI employee runs on its own schedule, has its own inbox, and keeps a task board and memory across shifts.

How It Works

  1. Hire an employee and give it a role brief (e.g. ops/support monitoring)
  2. Schedule its shifts (e.g. each weekday morning) — or let it wake on events
  3. Set wake conditions so it also comes to work on a new email or a Slack message, not just on a timer
  4. Connect Cowork on our repo + Gmail so it can research the codebase and act on real email
  5. It works each shift autonomously, writes a handover for the next shift, and flags anything that needs a human decision back to us

Why This Is Different From a Scheduled Chat

A scheduled chat runs a prompt on a timer and forgets. An AI employee accumulates context across shifts, follows up on its own observations, maintains dashboards of what it's tracking, and can hand work to another employee — so recurring operational work actually compounds instead of restarting each time.


The "Critically Self-Review" Technique

One of our most-used prompts across all setups:

"Can you critically self-review your [plan / design / changes]?"

We use this at critical junctures — after creating a plan, after making significant code changes, after drafting a response. The agent re-examines its own work with a critical eye and often catches issues it missed on the first pass.

We strongly recommend this for any high-stakes work. It's a simple prompt that meaningfully improves accuracy. Use it after plans, after designs, after implementations — especially when the cost of getting it wrong is high.


Summary of Setups

table
SetupModeConnectionsUse Case
Coding AgentAgentCowork (repo)Feature development, bug fixes, product updates
Multi-Session DevAgentCowork (repo)Large features spanning 3-9 sessions
Deep Research CodingAgent Team / MaxCowork (repo)Complex architecture, self-improvement, cutting-edge work
Customer SupportAgentGmail + Cowork (repo)Reading & responding to customer emails with codebase research
Document ManagementAgentCowork (docs folder) + Project + Agent RoleLegal filings, tax compliance, document guidance
Data AnalysisAgentCowork (repo)Production database analysis, PDF report generation
AI EmployeeAI EmployeesCowork (repo) + GmailStanding, scheduled work with its own inbox, shifts, and memory

Key Takeaways

  1. Cowork is the foundation. Almost every setup starts with connecting your working directory. It gives agents intimate access to your real environment.

  2. One session, many roles. Don't switch agents for each phase of work. A single session can be your PM, engineer, security reviewer, and marketing writer — and it does better because it has full context.

  3. Multi-session handovers matter. For large projects, invest in proper design docs and handover documents. Each session should leave the next one better informed.

  4. "Critically self-review" is your best friend. Use it liberally. It's the single highest-impact prompting technique we've found.

  5. Start cautious with command review. Review everything at first. Relax as you build trust. Never auto-approve commands outside your git repo without understanding what they do.

  6. The agent that builds it should announce it. Post-development marketing from the same session produces remarkably specific, accurate content.


Related Guides