Stephen G. Pope's open-source framework for building secure, autonomous AI agents that run 24/7 on GitHub's free infrastructure, modify their own code, and self-improve from their own logs.
The core concept deconstructed from the video
The PopeBot flips the typical AI agent paradigm. Instead of running a bot on a server that stores state in a database, the entire agent — its code, personality, scheduled jobs, logs, and work product — lives inside a GitHub repository. Every action is a git commit. Every modification goes through a pull request. The repo is the single source of truth.
This means you get version control, audit trails, collaboration features, and rollback capabilities for free — because you're using Git's existing infrastructure rather than building custom monitoring systems.
Pope explicitly calls out that existing cloud-hosted bots like "Cloudbot" have proven unsafe for data, leading to thousands of data leaks. The PopeBot addresses this by:
Because all agent logs are stored back in GitHub, the system enables a powerful feedback loop:
This is essentially the "Agent Expert" paradigm and "Ralph Loop" concept applied at the infrastructure level. The persistent memory is Git, the fresh execution context is an ephemeral Docker container, and the self-improvement mechanism is log analysis + automated PRs. This architecture solves the context window limitation by making the entire repo available to each fresh agent session.
Pope demonstrates by building a financial adviser that generates daily pre-market research reports. The agent:
How the system flows from input to execution to output
Jobs can be triggered two ways:
The actual execution environment:
The repo contains an operating-system/ folder that acts as the agent's brain. Inside it:
popebot/
├── operating-system/
│ ├── financial-adviser/
│ │ ├── financial-adviser.md # Instructions for the adviser
│ │ ├── report-template.md # Template for daily reports
│ │ └── reports/
│ │ └── 2025-02-10-report.md # Generated daily reports
│ ├── cron-jobs.md # Scheduled tasks config
│ └── [other-agent-configs].md # Other agent personality/skill files
├── jobs/
│ └── [job-id]/
│ ├── job.md # Job definition
│ └── log.md # Full agent reasoning log
├── .github/
│ └── workflows/ # GitHub Actions definitions
└── src/ # Core bot code
The MD files describe how the agent should function. The bot reads these to understand its tasks and personality. You can edit them manually in GitHub or let the bot modify them via PRs.
The "repo IS the agent" approach means cloning your agent is as simple as forking a repo. All code, personality, scheduled jobs, and full history travel with the fork. This is dramatically simpler than exporting/importing database configurations from traditional bot platforms.
The multi-layer credential isolation model
The AI literally cannot access your secrets, even if it tries. Secrets are filtered at the process level before the agent's shell even starts. This is fundamentally different from other frameworks that hand credentials to the LLM and hope for the best.
All credentials stored in GitHub's encrypted secrets vault. Even repo admins cannot view secret values after creation. Secrets are never in code, never in commits, never in job definitions.
Each job runs in a fresh, ephemeral Docker container. Starts with zero credentials. GitHub injects secrets at runtime only. Container is destroyed after job completes — no persistent state to leak.
Two categories of secrets: Secrets (container needs, LLM can't see) and LLM Secrets (LLM has access to). GitHub token and Anthropic API key stay in Secrets. Only Brave Search key goes to LLM Secrets.
┌─────────────────────────────────────────────────┐
│ GITHUB SECRETS (Encrypted) │
├───────────────────┬─────────────────────────────┤
│ SECRETS │ LLM SECRETS │
│ (Bot needs, │ (LLM has access to) │
│ LLM can't see) │ │
│ │ │
│ • GitHub Token │ • Brave Search API Key │
│ • Anthropic Key │ • [User-added service keys] │
│ • Webhook Secret │ │
│ • Bot API Key │ │
└───────────────────┴─────────────────────────────┘
The LLM makes its own decisions about how to use LLM Secrets.
It cannot access or expose the container-level Secrets.
By default, every change the bot makes goes through a pull request that requires manual approval before merging to the main branch. This means:
Everything you need to get the PopeBot running
# 1. Fork the repo (make it PRIVATE)
# Go to github.com/stephengpope/thepopebot → Fork
# 2. Clone your fork
git clone https://github.com/YOUR_USERNAME/thepopebot.git
# 3. Navigate into the directory
cd thepopebot
# 4. Run the automated setup
npm run setup
# Setup will walk you through:
# → GitHub Personal Access Token (repo-scoped)
# Permissions: actions (read), contents (read/write),
# metadata (auto), pull requests (read/write)
# → Anthropic API Key
# → OpenAI API Key (optional, enables voice on Telegram)
# → Grok API Key (optional)
# → Brave Search API Key (free tier available)
# → Telegram Bot setup via @BotFather
# 5. Start the event handler
npm run start:events
# 6. In another terminal, start ngrok for local testing
ngrok http 3000
# 7. Paste the ngrok URL when prompted
# 8. Verify via Telegram with the verification code
# 9. You're live! Send "Hey" to test
When running locally, Telegram can't reach your computer through your firewall. ngrok creates a secure tunnel from the cloud to your local machine. When deployed to production (instructions coming from Pope), you won't need this — the bot will be cloud-accessible directly.
# Send a job via API (alternative to Telegram)
curl -X POST https://your-bot-url.com/api/job \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_BOT_API_KEY" \
-d '{
"command": "Read the file at operating-system/financial-adviser/financial-adviser.md and complete the tasks described there."
}'
Ready-to-use prompts extracted from the video methodology
Create a [SKILL_NAME] agent. Put all related files in the operating-system/[SKILL_FOLDER]/ directory so we stay organized.
Create the following files:
1. **[SKILL_NAME].md** — The main instruction file describing:
- What the agent should do
- What data sources to use
- Decision-making criteria
- Error handling instructions
- Output format requirements
2. **[TEMPLATE_NAME]-template.md** — A template for the output this agent produces, including:
- Section headers and structure
- Required data points to include
- Formatting guidelines
- Example placeholder content
3. **Add a scheduled task** to cron-jobs.md:
- Schedule: [CRON_EXPRESSION] (e.g., "0 6 * * *" for daily at 6AM)
- Command: "Read the file at operating-system/[SKILL_FOLDER]/[SKILL_NAME].md and complete the tasks described there."
- Set enabled: true
After creating these files, produce the first output using the template as a proof-of-concept.
Create a financial adviser. Put all the related files in operating-system/financial-adviser/ so we can keep organized.
Create one file that stores what the financial adviser should do — it should:
- Perform daily pre-market research before market opens
- Analyze major indices (S&P 500, NASDAQ, DOW)
- Review overnight global market movements
- Identify key earnings reports for the day
- Flag any significant economic data releases
- Summarize analyst sentiment and market outlook
Create a template for what the daily report should look like — including:
- Market Overview section
- Key Movers section (top gainers/losers)
- Earnings Calendar
- Economic Events
- Risk Factors & Watch Items
- Trading Thesis / Opportunity Highlights
Then produce today's report as a proof of concept.
Add a repeating daily task to the cron jobs scheduled for 6:00 AM EST.
Analyze all job logs in the jobs/ directory from the past 7 days.
For each completed job:
1. Review the agent's reasoning chain and decision points
2. Identify where the agent struggled, made errors, or took inefficient paths
3. Note which tools/searches were most and least effective
4. Track time spent on each phase of execution
Then produce:
- A summary report at operating-system/self-improvement/weekly-review.md
- Specific recommendations for improving agent instructions
- Updated versions of any agent skill files that would benefit from optimization
- A list of new skills or capabilities the agent should develop based on observed needs
If any improvements are high-confidence and low-risk, implement them directly in the relevant .md files. For larger changes, describe them in the review and flag for human approval.
Create a local SEO research agent. Put all files in operating-system/local-seo-researcher/.
This agent should:
1. Accept a [BUSINESS_TYPE] and [CITY] as input parameters
2. Research the top 10 ranking competitors for "[BUSINESS_TYPE] in [CITY]"
3. Analyze their:
- Content depth and word count
- Keyword patterns and semantic clusters
- Local reference integration (landmarks, neighborhoods, events)
- Schema markup usage
- Google Business Profile optimization signals
4. Generate a competitive intelligence report including:
- Content gaps and opportunities
- Recommended keywords (high-intent, emergency, and long-tail)
- Suggested SILO architecture for multi-city targeting
- Estimated difficulty score for ranking in top 3
5. Create a content brief template that can be used to generate location pages
Add this as a manual-trigger job (not cron) since it's on-demand research.
For the proof of concept, run this for "emergency plumber" in "Austin TX".
Create an agent-builder agent at operating-system/agent-builder/.
This meta-agent should:
1. Accept a natural language description of a desired capability
2. Analyze existing agents in the operating-system/ directory
3. Determine if the capability already exists (or partially exists)
4. If new:
- Design the agent instruction file (.md)
- Create an appropriate output template
- Determine if it should be cron-scheduled or manual-trigger
- Add the cron entry if applicable
- Produce a test run as validation
5. If exists:
- Suggest modifications to enhance existing capability
- Create a PR with the proposed changes
6. Maintain a registry at operating-system/agent-builder/registry.md
listing all active agents, their schedules, and last run status
This agent should be scheduled weekly (Sundays at midnight) to:
- Review the registry
- Check for stale or failing agents
- Suggest consolidations or improvements
- Report its findings
How to leverage this architecture for your business
The exact demo from the video. Pre-market research, competitor tracking, trend analysis — all automated and delivered to your Telegram before you wake up.
Automated rank tracking, competitor content analysis, GBP audit reports, and citation monitoring for all your client locations. Fits your multi-city SILO approach perfectly.
Agent reviews video transcripts, extracts key insights, generates blog drafts, social posts, and newsletter content — all committed to a content calendar repo.
Schedule regular checks across AI models (ChatGPT, Claude, Gemini, Perplexity) to monitor how they recommend your brand vs. competitors. Track changes over time.
Automated weekly/monthly reports for SEO clients — pulling from Search Console, Analytics, and rank trackers. Formatted, summarized, and ready to send.
The agent reviews its own logs, identifies failures, and submits PRs to fix its own code. This is the self-evolution loop that makes the system increasingly powerful over time.
This maps directly to your "boring business" thesis. Most local service businesses have zero automation, let alone AI agents. A PopeBot configured for local SEO monitoring, review management, and content generation gives you a massive competitive moat. The free GitHub compute means you can run agents for every client at essentially zero infrastructure cost — the only costs are API calls to Claude and Brave Search.