A complete AI agent operating system for lead generation — built for the AI Architects Peer Learning Group using a ChatGPT → Claude Code → NotebookLM multi-model pipeline.
Most people deploy AI agents with a simple prompt and hope for the best. The result is inconsistent output, hallucinated facts, and agents that take unauthorized actions the moment they're given any real access. This project was built to solve that problem for the AI Architects Peer Learning Group — a structured, multi-session exercise in designing a proper operating system for OpenClaw, a self-hosted personal AI agent gateway.
The output is an enterprise-grade requirements framework that any group member can use to deploy OpenClaw safely for lead generation across four distinct scenarios: B2B Enterprise, B2B SMB, B2C consumer acquisition, and Job-Seeker networking. The framework treats OpenClaw like a new employee being onboarded into a lead-generation role — with a mission, scope, trust ramp, and explicit rules for what it can and cannot do at each stage of the working relationship.
Giving an AI agent access to your email, CRM, or LinkedIn account without a structured operating model creates real risks: spam sent to valuable contacts, hallucinated company details in outreach copy, leads approved without qualification, and permission creep that expands agent autonomy faster than trust has been earned. The peer learning group needed a replicable, community-ready framework that would make safe deployment the default path — not something that required advanced technical skills or extensive trial and error.
Three specific failure modes drove the design:
This project was built using a deliberate three-stage multi-model pipeline, with each AI tool applied to the task it does best.
Stage 1 — ChatGPT: Requirements architecture. The initial requirements prompt was designed in ChatGPT — a detailed, 638-line brief specifying exactly what sections the framework needed to include, what decisions each section had to support, and what failure modes it had to prevent. This prompt became the source document for the entire project and is preserved in the repository as original-requirements-prompt.md.
Stage 2 — Claude Code: Document creation. Claude Code built all six markdown documents from the requirements prompt — including the 20-section master requirements document, the onboarding guide, the best practices guide, the setup and installation guide for Fedora Linux, and the scenario customization guide. Claude Code also handled version control, file organization, and cross-document consistency across the full package.
Stage 3 — NotebookLM: Presentation packaging. Four of the six documents were converted into polished presentation decks using NotebookLM — each available as both PDF and PPTX. The decks cover requirements, deployment playbook, onboarding guide, and setup guide, making the framework accessible to group members who learn better from structured slides than from raw markdown.
The master requirements document spans 20 sections covering every dimension of a safe, effective AI lead-generation operation.
1. The "new employee" mental model. Framing OpenClaw as a new employee — not a tool — makes the entire system intuitive. New employees get oriented before doing real work, start with limited responsibilities, earn expanded access by demonstrating judgment, and get better as the working relationship develops. This framing made the permission ramp feel natural rather than bureaucratic.
2. Staged permission model (Stages 0–5). OpenClaw starts in Stage 0: read-only research only. It can research leads, qualify them, score them, and recommend next actions — but it cannot contact anyone, send anything, or take any external action. Each stage promotion requires explicit user approval after reviewing defined criteria. The trust log creates an auditable record of how the working relationship has developed.
3. Mandatory qualification before outreach. Raw leads are never approved leads. Every lead must pass through a documented qualification process — with source attribution, fit evidence, intent signals, authority assessment, and a plain-English explanation — before outreach is ever drafted. This single rule eliminates the most common failure mode: contacting people without knowing whether they're actually qualified.
4. Scenario-specific customization. The framework is generic enough to cover all four lead-gen scenarios but structured enough that customization is systematic, not open-ended. A separate customization guide walks each scenario through the specific fields to fill in, the scoring weights to adjust, and the common failure modes unique to that scenario.
5. Stress test section. Before deployment, operators review 12 identified failure modes — including spam behavior, hallucinated trigger events, weak personalization, permission creep, and compliance exposure — each with a specific mitigation built into the framework. The stress test is the last step before activation, not an afterthought.
The project produced ten artifacts across two formats: