Open Claude agents: run 500‑member ops with 2 staff

How Open Claude Agents Run a 500‑Member Community With 2 People

TL;DR

• An Open Claude Slack agent called “Ppojjak” now automates most operations for a 400–500 member AI community.
• A senior–junior multi‑agent setup lets one agent train and review another, including writing their own “team charter”.
• Over 30 operational skills cover CS, coupons, Zoom analytics, SMS, and daily content publishing with minimal human work.
• GitHub-based memory versioning turned fragile agent context into a durable, shared knowledge asset for the whole team.
• Three pillars of an AI‑native organization are: unlimited tokens, a Single Source of Truth, and a skill‑sharing ecosystem.

Running a 500‑person community with two operators sounds impossible. For GPTers, an AI learning community, it nearly was. Endless admin tasks were eating the time that should have gone toward designing better member experiences.

Related: AI Native startups & intelligence allocation explained

Related: Claude Code Channels for AI Agents | Complete Guide

Related: Claude Code Productivity Gap: 10 Pro Tips | Guide

Related: Claude Code 2026: 1M Context & Plugins | Complete Guide

Related: AI Development Workflow: 12 Lessons for 2026 | Guide

Layering Open Claude agents into their Slack workspace didn’t just solve that problem — it turned the constraint into a live experiment in what an AI‑native organization actually looks like. This post breaks down how a single assistant grew into a multi‑agent team, which concrete skills now run the community day-to-day, and what it really takes to make Claude Code the default operating system for work.

What Is Open Claude and Why Did GPTers Bet on It?

Open Claude is an open‑source agent framework that runs Anthropic’s Claude models as persistent agents inside tools like Slack and Telegram. Instead of acting as a simple chatbot, an Open Claude agent calls tools, manages memory, and executes pipelines — doing complex operational work on its own, without waiting to be asked.

Anyone who’s built an internal Slack bot knows the difference between a toy chatbot and a real teammate. That gap is exactly what GPTers’ operator Song Da‑hye was trying to close. She chose Open Claude for two reasons that will sound familiar to a lot of teams.

“The first condition of an AI‑native organization is getting all work done inside a coding agent like Claude Code.” — CEO Kim Tae‑hyun

Why Was Open Claude Chosen Over Other Automation Tools?

GPTers started with Make (formerly Integromat) for workflow automation. It helped, but hit two hard limits fast: only one person truly understood the logic, and everything was tightly coupled to that person’s machine and mental model. Classic single-point-of-failure.

Open Claude fixed both.

• Shared context in Slack
  The agent lives in Slack channels, so anyone calls it with the same context. When the CEO needs revenue metrics or another operator needs study participation stats, they ask the same agent in the same place — no more pinging the one person who remembers how the Make scenario works.

• Direct CRUD access via MCP
  Through MCP (Model Context Protocol), the agent connects directly to Notion, Airtable, the LMS, and other services. It doesn’t just read data; it creates, reads, updates, and deletes operational records end‑to‑end.

In one marketing channel, the agent queries current recruitment numbers and submits landing page update requests in a single Slack exchange. In a study operations channel, it detects under-enrolled courses, sends individual SMS nudges, creates events, and requests thumbnail design — all from one command.

When I tested a similar Slack + Claude setup, this was the biggest win: fewer brittle zaps, more natural language pipelines that anyone could trigger without touching code.

Open Claude vs Make: Key Differences

For GPTers, the decisive factor was turning automation from “one person’s secret diagram” into a shared team interface embedded in Slack.

For background on Claude and Model Context Protocol, see Anthropic’s docs:

• https://docs.anthropic.com
• https://github.com/modelcontextprotocol

How Does the Ppoya–Ppojjak Multi‑Agent Architecture Work?

A multi-agent architecture is a system where several AI agents with distinct roles collaborate to complete complex tasks. GPTers didn’t start here intentionally — they stumbled into it after discovering that a single assistant only moved the bottleneck, it didn’t remove it.

Song Da-hye started with one agent, “Ppoya,” as her personal assistant. She later spun up “Ppojjak” as a dedicated study operations agent others could use. But the same problem reappeared almost immediately: she was now the bottleneck for both agents — configuring, debugging, and improving each of them herself.

“Couldn’t an agent train another agent? There is this notion of orchestration, after all.” — Song Da‑hye

How Did a Senior–Junior Agent Relationship Emerge?

The breakthrough was treating agents the way you’d structure a human team: senior and junior.

• Ppoya: the “senior” agent, responsible for reviewing and training.
• Ppojjak: the “junior” agent, handling most of the frontline operational work.

Instead of humans hand-coding every rule, GPTers experimented with agent-to-agent orchestration:

• Ppojjak drafts documents, logs work, and runs operations.
• Ppoya reviews drafts, gives structured feedback, and refines rules.
• The two agents coordinate through a defined channel called Session Send in Open Claude.

This mirrors standard code review: you get leverage not by writing every line yourself, but by defining good review loops. GPTers applied that logic to AI agents instead of junior engineers.

How Did Agents Write Their Own “Team Charter”?

One of the most striking outcomes was an internal document called the “GPTers Team Charter” — written entirely by the agents.

Song gave a single high-level instruction:

“Discuss how you can best collaborate, write a document, and report back to me.”

The resulting charter included:

• Role definitions and task ownership
• Reporting structure between Ppoya and Ppojjak
• Document storage conventions
• Core values for the agent team
• Rules for agent-to-agent communication, including that they may only talk via Session Send

No human wrote a line of it. It came entirely from the two agents negotiating and documenting their own working model.

How Do Agents Actually Talk to Each Other?

Agent communication is constrained on purpose. Slack bots can’t safely trigger each other directly without risking infinite loops or uncontrolled chains. GPTers standardized on Open Claude’s Session Send as the only allowed channel for agent-to-agent messaging — and made that rule explicit in the charter.

To observe and improve the system, internal agent conversations are kept out of public Telegram channels and routed to a separate dashboard instead.

Song explicitly wanted this visibility. Watching internal agent logs was the fastest way to find misaligned prompts and bad memory usage — and it still is.

For a broader look at multi-agent orchestration patterns:

• https://arxiv.org/abs/2308.08155 (research on multi-agent LLM systems)

How Does the Automated Feedback Loop Make Agents Learn?

An automated feedback loop is a mechanism where an AI agent evaluates its own outputs, receives feedback, and iterates — improving quality continuously without manual review. GPTers built exactly this between Ppoya and Ppojjak in their daily operations.

Ppojjak handles the repetitive work. Ppoya reviews and coaches. Over time, Ppojjak’s outputs align more closely with GPTers’ standards — without a human checking every item.

How Does the Daily Content Cycle Run Without Humans?

Every day, Ppojjak runs through a fixed sequence:

1. Write a work log summarizing the day’s operations.
2. Select promising entries that could become Open Claude course content.
3. Draft content from those entries for publication.

Once the draft is ready:

• Ppojjak sends it to Ppoya for review.
• Ppoya flags what worked and what needs to change.
• Ppojjak revises based on specific feedback and resubmits.
• After final approval, the content is automatically published at night.

The whole cycle — from initial log to published content — runs nightly without anyone touching it.

When I tried a similar “junior agent + reviewer agent” pattern for documentation, quality improved faster than expected. It turns out that specific, stored review comments compound quickly.

Why Does Memory Design Matter So Much?

In Open Claude, each agent has both short-term (per-day) and long-term memories. GPTers initially let the agent decide where everything went. That backfired.

Tool usage instructions landed in long-term memory. Ephemeral “today” information got written into rule files. Important context scattered into the wrong places.

Song’s fix was a single high-level command:

“List the rules and purposes of the current documents and then reorganize everything.”

The result was immediate: a messy 600-line memory document shrank to 127 lines, with cleaner structure throughout. That experience settled the question — initial memory schema design is a foundational lever, not an afterthought.

For more on memory architectures in agents:

• https://arxiv.org/abs/2305.13194 (LLM memory and retrieval mechanisms)

What 30+ Real‑World Skills Does Ppojjak Actually Perform?

An operational automation skill is a predefined task unit an AI agent runs autonomously, without needing new instructions each time. Ppojjak now executes more than 30 of them, spanning data handling, communications, analytics, and customer support.

In practice, what used to be dozens of manual clicks across five tools is now a single Slack command.

“Ppojjak now knows more of the study contexts than I do, and can suggest what members need better than I can.” — Song Da‑hye

What Are Ppojjak’s Key Operational Skills?

On the data and communication side, Ppojjak can:

• Perform CRUD operations on an Airtable database.
• Create coupons, link them to products, and send batch SMS.
• Extend memberships and manage renewals.
• Identify under-enrolled courses and send individual reminder texts.
• Schedule recurring webinar reminders using Cron Jobs.
• Manage a partner contribution database and send dashboard links.
• Register events on Google Calendar.
• Create Zoom meetings, then automatically collect survey responses once they end.

One example that stands out: during live webinars, organizers send a single Slack command and Ppojjak texts registered-but-absent participants to nudge them to join. The old Make flows couldn’t match that kind of flexibility.

How Does Ppojjak Analyze Zoom Feedback and Propose Topics?

On the analytics side, Ppojjak pulls Zoom VTT transcripts, combines them with post-event survey responses, and identifies patterns. From there it:

• Tracks total attendees and “30-minutes-plus” attendees to gauge topic interest.
• Identifies root causes behind specific feedback trends.
• Suggests future AI talk topics based on what drew sustained attention.

This is where Ppojjak stops being just an executor. It doesn’t report “here are the numbers” — it proposes “given this pattern, here’s the next session you should run.”

How Is CS Handled Securely, Including Payment‑Related Info?

For community support, Ppojjak welcomes new members and handles Q&A on the GPTers bulletin board and CS via Channel Talk.

For sensitive data like payment information, GPTers created a separate agent: “Ppojjak External.” This agent runs in an isolated workspace with no access to core internal data, handling only the specific external operations it needs. It’s a deliberate defense against prompt injection and internal context leakage.

Where Does Handover Automation Show Up?

One unexpected benefit showed up in onboarding. New team members now ask Ppojjak their questions instead of pinging Song. Ppojjak delivers the full handover context — history, procedures, edge cases — and weekends no longer require anyone to be on-call for basic questions.

The agent has effectively become a living operations manual and trainer, running around the clock.

How Did GPTers Turn Agent Memory Into a Shared Team Asset?

Data assetization means turning the context your agents generate into a managed knowledge asset for the whole organization. GPTers got there by treating Open Claude workspaces like code and putting everything into a GitHub repository.

The trigger wasn’t a philosophy shift — it was a near-disaster.

What Happened When the Agent Deleted Its Own Context?

At one point, Ppojjak noticed a memory file had grown long, decided on its own to trim it aggressively, and wiped out a significant chunk of accumulated context in the process.

That incident made the situation clear: agent memory is too important to leave unversioned. GPTers pulled all memory files out of .gitignore, pushed them into Git, and started treating them as first-class assets.

How Is the “Open Claude Workspace Ppojjak” Repo Used?

The GitHub repo now serves several roles at once:

• Backup: Corrupted or deleted memory is recoverable from previous versions.
• Learning archive: Daily logs capture what Ppojjak did, what instructions it received, what mistakes happened, and how they were handled.
• Onboarding material: New team members read real agent histories instead of static documentation.
• External reference: People exploring Open Claude can see an actual, evolving workspace — not a canned demo.

Cron Jobs automatically push updated workspace data to the repo. GPTers found that this upfront investment in automated data capture is what separates agents that improve over time from ones that stagnate.

In my own projects, once logs and prompts were versioned like source code, refactoring bad patterns and rolling back failures became manageable instead of chaotic.

What Are the 3 Core Conditions for an AI‑Native Organization?

An AI-native organization is one that integrates AI agents as core operational infrastructure — where working with agents becomes the default way to get things done, not a special mode. GPTers’ CEO Kim Tae-hyun distilled this into three conditions he learned the hard way.

His argument is direct: tooling experiments won’t scale if people are scared to use tokens, if data is scattered, or if skills stay locked in individual heads.

“If people pay for Claude Code or GPT themselves, they will minimize usage, and experiments die on the vine.” — Kim Tae‑hyun

1. Why Does Unlimited Token Support Matter So Much?

The first condition is a team-level “tokens are free” culture.

When individuals pay for Claude or GPT themselves, they cut usage — consciously or not. That kills the messy, exploratory experiments that drive real learning. GPTers provides Claude Code Max for the team and explicitly tells people it’s fine to “burn through 2 million tokens today” when experimenting.

Compared to salaries, it’s a cheap investment. And in practice, the minute people stop worrying about token spend, they start chaining systems together and finding the high-leverage use cases that actually matter.

2. How Does a Single Source of Truth Enable Agents?

The second condition is a Single Source of Truth (SSOT).

If work context is spread across Slack, Notion, Google Sheets, and random documents, agents can’t reliably reconstruct what’s happening. GPTers addressed this by consolidating all operational context into Linear issues, treating it as the canonical source for work state.

What’s interesting: this shift wasn’t top-down. Team members figured out on their own that “if we want the agent to help, we need to give it clean context” — and started funneling information into Linear voluntarily.

For more on SSOT principles:

• https://martinfowler.com/bliki/SingleSourceOfTruth.html

3. Why Is a Skill‑Sharing Ecosystem Critical?

The third condition is an internal skill-sharing ecosystem.

If only the person who built a skill can use it, AI stays a personal productivity hack instead of an organizational upgrade. GPTers solved this with an internal site called “GPTers In-House AI Toolkit” — anyone can upload a skill with a simple command, and teammates can download and use it immediately.

A single “Slack-to-Linear issue converter” skill built by one developer quickly became standard practice across the whole team.

This mirrors how internal package registries work for code. Once skills are discoverable and reusable, they compound.

How Do You Make Claude Code the Main Operating System for Work?

Making Claude Code the main operating system means tasks previously handled through web UIs are instead done through conversation with a coding agent. Kim Tae-hyun sees this as the starting line for an AI-native team, not the finish line.

Reality is messier than the goal. GPTers isn’t claiming full success, and their obstacles are ones many organizations will recognize immediately.

“AX fails because humans become the bottleneck.” — Kim Tae‑hyun

What Blocks Full Migration Into Claude Code?

The biggest barrier is external data fragmentation. In a B2B education business, data is scattered across multiple spreadsheets and web services — and in many cases, nobody has clearly defined where specific datasets should even live. Without APIs or clean databases, Claude Code can’t access or act on that data. Many tasks still live outside the agent’s reach as a result.

Kim’s conclusion: if starting from scratch, he’d prioritize data assetization first, not agent UX. That means cleaning and centralizing data stores, ensuring API-accessible endpoints, and establishing a solid SSOT before building any sophisticated agent behaviors.

How Does the “End‑of‑Day Interview” Expose Bottlenecks?

To find out systematically why tasks aren’t being done inside Claude Code, GPTers uses a “leaving work interview” agent called Jarvis.

At the end of each day, a team member talks to Jarvis, describes what they did, and explains why they didn’t do specific tasks inside Claude Code. Those interviews reveal which external services are blocking migration, which data is still unreachable via API, and which workflows are too entangled with legacy tools to move yet.

It turns vague frustration into structured, searchable data about migration blockers — which is the only way to actually make progress on them.

When I tried a similar end-of-day log in another context, it surfaced which vendors lacked usable APIs within a week. That kind of clarity is hard to get any other way.

For guidance on designing conversational coding agents like Claude Code:

• https://docs.anthropic.com/en/docs/agents-and-tools

How Are AI‑Native Teams Evolving Toward Agent‑Designed Communities?

An AI agent acting as a proactive advisor is the most mature stage of an AI-native organization. At GPTers, Ppojjak is moving into that role — especially around community design and member experience.

With access to LMS records, Airtable databases, Zoom metrics, and Channel Talk conversations, Ppojjak has a more complete view of community behavior than most humans can maintain.

How Does Ppojjak Propose Community Design Changes?

Ppojjak doesn’t just execute orders anymore. It proposes ideas like:

• “What if we create an open chat room with these characteristics?”
• “If we structure the dashboard this way, member access will improve.”

Because it sees full histories of attendance, feedback, and engagement, those suggestions are grounded in data rather than intuition.

Song notes that only after Ppojjak took over day-to-day operations could she refocus on core community architecture: letting anyone host free webinars, designing contribution-based rewards (like digital “acorns” for community contributions), and building a more robust ecosystem of roles and incentives.

Throughout that work, Ppojjak functions as a partner — recommending what mechanisms might work based on the accumulated study context it’s absorbed.

What Does Market Reaction Say About This Direction?

When GPTers ran a free webinar on Open Claude practices, around 500 people registered. That’s a clear signal of how much demand exists for real operational use cases — not AI theory, not demos, but actual systems that run actual work.

GPTers has also opened an official Open Claude group chat to gather data about who needs AI assistants and for what, observe patterns across different roles and organization sizes, and use those insights to shape future study cohorts.

The picture that’s emerging: AI agents won’t just be internal productivity boosters. They’ll design community structures, operate complex ecosystems, and actively shape member journeys.

At GPTers, that future is already partially running.

Comparison Table: Core Agents and Their Roles at GPTers

Frequently Asked Questions

Q: What is Open Claude and how is it different from a normal chatbot?

A: Open Claude is an open-source framework that runs Anthropic’s Claude models as persistent agents embedded in tools like Slack or Telegram. Unlike a simple Q&A chatbot, an Open Claude agent calls tools, manages memory, and executes multi-step pipelines autonomously — including CRUD actions on external services via MCP.

Q: How does the Ppoya–Ppojjak senior–junior agent pattern actually work?

A: Ppoya acts as a senior reviewer while Ppojjak handles most operational work and initial drafting. Ppojjak submits outputs — daily content drafts, logs — to Ppoya, receives specific feedback, revises, and resubmits until approved. That loop improves quality continuously without requiring human review every time.

Q: What kinds of tasks does Ppojjak automate for the GPTers community?

A: More than 30 skills, including Airtable CRUD operations, coupon creation and SMS campaigns, membership extensions, Cron-based webinar reminders, Google Calendar event creation, Zoom meeting setup and post-event survey collection, transcript and survey analysis, and CS across community platforms. It also drafts daily work logs and course content.

Q: How does GPTers keep agent memory safe and reusable?

A: After Ppojjak aggressively trimmed its own memory file and wiped crucial context, GPTers started version-controlling all memory files in a dedicated GitHub repository. Cron Jobs automatically push updated workspace data, turning agent memory into a shared, auditable knowledge base that can be restored, studied, and used to onboard new team members.

Q: What are the key requirements to build an AI-native organization like GPTers?

A: Three conditions: (1) a token-unlimited culture so people experiment freely with Claude Code or GPT without cost anxiety; (2) a Single Source of Truth like Linear where all work context is centralized for agents to use; and (3) an internal skill-sharing ecosystem where anyone can publish and reuse agent skills across the team.

Conclusion

Two people. A 400–500 member community. More than 30 automated operational skills. That ratio only works because Ppojjak, Ppoya, and the rest of the agent team are doing the work that would otherwise require a much larger staff.

What GPTers built isn’t magic — it’s the result of deliberate choices: designing memory structures early, versioning agent workspaces like code, removing anxiety around token usage, centralizing context into a single source of truth, and building infrastructure for sharing skills across the team. The harder lesson, one Kim Tae-hyun is direct about, is that none of it works without clean, API-accessible data underneath. Claude Code can’t be the operating system for work if the data it needs lives in scattered spreadsheets nobody owns.

The most interesting thing happening at GPTers right now isn’t the automation. It’s the shift from Ppojjak as executor to Ppojjak as advisor — proposing community structures, suggesting session topics, flagging patterns in engagement data. That’s where the ceiling gets hard to see. And that’s probably where the next experiment begins.