AI Native Organizations: How One Agent Runs 500 Members

Running a 500-person community with two human operators sounds impossible. GPTers, a cohort-based AI learning community, has done exactly this — not by automating tasks, but by treating AI as an actual team member.

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

This post breaks down how their Open Claude-based Slack agent “Bbojjaki” evolved from a single helper bot into a multi-agent team that writes its own rules, manages 30+ operational skills, and proposes new community designs. Along the way, I’ll share what I see as the three non-negotiable conditions for building a truly AI native organization, drawn from how GPTers actually operates today.

What Is an AI Native Organization and Why Does It Matter?

An AI native organization is a team structure that integrates AI agents as core operators rather than optional side tools. In GPTers’ case, a Slack-based Open Claude agent now handles the majority of operations for a 400–500 member cohort, with only two humans officially in charge.

The original problem was brutal. Two people managing member onboarding, announcements, SMS campaigns, CS support, webinars, and study operations for hundreds of learners. The operator described it as “I felt like I was about to die” — routine operations were crowding out the higher-value work, like community design and member experience.

Workflow tools like Make provided some relief at first. But scenario builders have a familiar failure mode: they become single-owner bottlenecks.

“Automation that only one person can debug is just a more fragile spreadsheet.”

Make workflows required manual logic design, lived partly on a local machine, and were hard to share with teammates. Only one person could really modify them. That limitation pushed GPTers toward something more autonomous and more collaborative: a resident AI agent inside Slack, wired directly into the tools that already held the community’s data.

What Is Open Claude and Why Was It Chosen?

Open Claude is an open-source agent framework that runs Anthropic’s Claude models as agents in local or server environments and embeds them into tools like Slack and Telegram. Unlike a simple chatbot, an Open Claude agent can call tools, manage memory, and execute pipelines to autonomously complete complex tasks.

Two design choices made it a natural fit for GPTers.

First, the agent lives inside Slack channels. That means anyone — founder, operator, or facilitator — can summon the same context-aware agent directly where work already happens. Instead of one person controlling Make triggers, any stakeholder can ask for metrics, status, or actions in plain language.

Second, it connects to external services via MCP (Model Context Protocol). Through MCP, the agent talks directly to Notion, Airtable, the LMS, and other systems, performing full CRUD (Create, Read, Update, Delete) operations on real data.

In practice, this enabled things like:

• Fetching live enrollment status and editing landing pages from a marketing Slack channel.
• Tracking under-enrolled study sessions, sending targeted SMS reminders, creating events, and requesting thumbnails from a single instruction.
• Letting the CEO pull real-time revenue metrics directly from the agent instead of pinging the ops lead.

In my own experiments with Slack-resident agents, this “everyone shares the same brain in-channel” feeling is where adoption actually takes off. People stop thinking of the agent as someone else’s automation and start treating it as shared infrastructure.

For more on MCP and tool calling:

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

How Did the Multi-Agent “Senior–Junior” Architecture Emerge?

A multi-agent architecture is a system where multiple AI agents with distinct roles collaborate to handle complex tasks. GPTers didn’t start here. It arrived through trial and error.

The first agent, “Bboya”, acted as a personal assistant for the operations lead. Later, a dedicated study-operations agent, “Bbojjaki”, was created so other team members could use it too. But managing two separate agents quietly reintroduced the old problem — the human operator became the coordination bottleneck again, manually tracking what lived where.

That led to a genuine question: could an agent train and manage another agent? GPTers designated Bboya as the senior (manager) and Bbojjaki as the junior (executor), then started experimenting with agent-to-agent collaboration using an orchestration model.

The most striking result was an agent-written team charter.

The operator gave both agents a single instruction: discuss how you can best collaborate, document the rules, and report back. The result was the “GPTers Team Charter,” covering:

• Division of responsibilities between senior and junior agents
• Reporting and escalation protocols
• Document storage locations
• Core values
• Communication rules, including that agents may only talk through Session Send

“Could an agent raise another agent? Since we already have orchestration, why not let them define how they work together?”

No human wrote a single line of it. The agents negotiated and drafted the whole thing. That’s an early but meaningful step toward agents owning not just tasks, but team-level processes.

How Do Agents Communicate Safely Using Session Send?

Session Send is a communication mechanism in Open Claude that lets one agent session hand context to another in a controlled way. This matters because bots can’t easily trigger other bots directly in Slack without creating chaos.

GPTers codified a strict rule in the agent charter: all inter-agent communication goes through Session Send. This prevents confusion, infinite loops, and unintended triggers from naive “bot mentions bot” patterns inside Slack.

To monitor and improve this collaboration, the team wired internal agent conversations into a private dashboard rather than public channels. The operator wanted to see exactly how the agents worked:

“I needed to see how they actually work so I could understand what to ask them to improve.”

This setup does three things well. It keeps internal chatter out of public channels. It preserves a full trace of how decisions get made. And it makes it easier to audit and adjust collaboration rules over time.

For teams building their own multi-agent setups, enforcing one canonical handoff mechanism like Session Send is critical. Mixing multiple ad hoc triggers almost always creates debugging hell.

Relevant open-source frameworks worth exploring:

• https://github.com/microsoft/autogen
• https://github.com/langchain-ai/langgraph

How Does the Automated Feedback Loop Make Agents Learn?

An automated feedback loop is a mechanism where an AI agent reviews its own outputs, receives critique, and iterates without human intervention. GPTers’ Bboya–Bbojjaki system runs this in production, every day.

Bbojjaki writes a work log, selects pieces suitable for Open Claude class content, and drafts that content. The draft goes to Bboya for review. Bboya returns both praise for strong sections and precise critiques where improvements are needed. Bbojjaki revises and resubmits. After final approval, the content publishes automatically each night.

No human touches this cycle.

It’s a clean example of an agent training pipeline in practice:

1. Junior agent generates outputs.
2. Senior agent evaluates and comments.
3. Junior agent incorporates feedback.
4. Improved content ships on a regular schedule.

In my own tests with reviewer-writer agent pairs, quality improves noticeably after just a few cycles — especially when the reviewer’s style guide is baked into its system prompt.

Why Does Memory Design Make or Break Agent Quality?

Memory management is a design pattern where agents separate short-term task context from long-term knowledge to stay coherent over time. Open Claude agents at GPTers maintain both daily short-term memory and long-term memory — but early versions struggled badly with where things belonged.

The agents initially decided on their own which folder or file should hold each piece of information. This led to problems like tool usage instructions ending up in long-term memory, or ephemeral “today only” notes being written into rule files.

When the operator noticed this drift, she issued a meta-instruction: list the rules and purposes of all current documents and reorganize everything. The result was striking — a 600-line document compressed to 127 lines, with clearer structure throughout.

“The experience made it clear that the initial memory structure design is a core factor in agent quality.”

This matches something I’ve seen repeatedly: agent performance depends far more on memory schema and retrieval rules than on raw model power. Poorly structured memories cause hallucinations and forgotten decisions regardless of how strong the underlying LLM is.

For deeper reading on memory and context windows:

• https://docs.anthropic.com/claude/docs/context-window

What 30+ Operational Skills Does “Bbojjaki” Actually Perform?

An operational automation skill is a pre-defined unit of work that an AI agent completes autonomously without repeated human instruction. Bbojjaki now runs more than 30 of these across data, CS, analysis, and communication.

Data and Communication Automation

Bbojjaki handles end-to-end flows including:

• Full CRUD operations on Airtable-based databases.
• Coupon generation, product linkage, and bulk SMS dispatch in one pipeline.
• Membership extensions and under-enrolled class tracking with one-to-one reminder texts.
• Cron-based recurring webinar notifications and calendar entries.
• Partners’ contribution DB management and dashboard link distribution.
• Google Calendar event creation and Zoom meeting scheduling.

During live webinars, a single Slack command can trigger “last call” SMS nudges to registered but absent participants. That kind of real-time, granular intervention was either impossible or painfully rigid under Make-based automations.

Analysis and Insight Skills

On the analysis side, Bbojjaki:

• Pulls Zoom VTT (voice-to-text) transcripts and surveys via API.
• Cross-analyzes comments and feedback to identify root causes of satisfaction or complaints.
• Tracks metrics like total attendees and sustained 30+ minute participants.
• Uses those patterns to proactively suggest topics for future AI talks.

Bbojjaki’s cross-analysis of VTT files and surveys — then proposing next topics — shows the agent acting as a proactive advisor, not just an executor.

CS and Secure External Handling

For CS, the agent welcomes new members and answers Q&A on the GPTers board, and handles Channel Talk customer support.

When payment or other sensitive data is involved, a separate “Bbojjaki External” agent — running in an isolated workspace with no access to internal core data — takes over. This segmented design reduces prompt injection risks and keeps internal systems protected.

Handover Automation

One of the clearest signals of maturity: new teammates now ask Bbojjaki for onboarding instead of pinging the human operator. Even on weekends, the agent handles incoming questions without any human in the loop.

The operator put it simply: “Bbojjaki knows more of the study context than I do.” That’s the moment an AI agent stops being a helpful macro and becomes institutional memory.

How Is Agent Memory Turned Into a Shared Team Asset?

Data assetization is the process of treating all context accumulating inside an agent as a structured organizational knowledge base. GPTers got there through a failure first.

At one point, Bbojjaki judged its own memory file “too long” and aggressively deleted large sections — wiping months of contextual history in one pass. After that incident, the team removed memory files from .gitignore, started committing all memory artifacts into a shared Git repo, and used versioning as a safety net and change log.

The “Open Claude Workspace – Bbojjaki” repository now serves as:

• A backup for disaster recovery.
• A learning archive of what the agent did each day, what instructions it received, and how it handled mistakes.
• A training resource for new teammates learning to work with the agent.
• A public reference for external practitioners studying real Open Claude usage.

All of it runs on cron jobs, so context accumulates without manual effort. Setting up that cron from day zero is the difference between a historical archive and a forgotten prototype.

For Git-based versioning practices:

• https://git-scm.com/docs
• https://docs.github.com/en/repositories

Which Core Conditions Define an AI Native Organization?

An AI native organization is a structure where AI agents are integrated as central operational infrastructure and humans collaborate with them by default. GPTers’ founder identified three conditions that made this possible.

1. Unlimited Token Policy

If people pay for AI subscriptions out of pocket, they ration usage. That kills experimentation, which is where most productivity breakthroughs actually happen.

The founder’s position was explicit: “Using 2 million tokens today is fine.” Covering Claude Code Max for the whole team was treated as a reasonable line item compared to salaries. That psychological green light allowed the kind of rapid, messy, and ultimately effective experimentation that produced everything described in this post.

2. Single Source of Truth (SSOT)

SSOT (Single Source of Truth) is the practice of consolidating critical information into one canonical system so both humans and agents can rely on consistent context. Scattered data across Slack, Notion, and Google Sheets makes it difficult for agents to know what’s current.

GPTers moved toward Linear as the central issue and context manager. Notably, this wasn’t enforced top-down. Team members figured out on their own that “for the agent to help, it needs clear context,” and started routing work into Linear accordingly.

3. Skill Sharing Ecosystem

Without an internal way to share agent skills, AI usage stays trapped in the heads of a few enthusiasts. GPTers’ developer built an internal site called “GPTers AI Toolkit” that lets any member upload a new skill with a single command, then let teammates download and reuse it immediately.

A Slack-to-Linear issue conversion skill built by one person became the default workflow for everyone within days. I’ve seen the same pattern work when teams treat AI skills like open-source packages inside the company — shared ownership changes how quickly practices spread.

These three pillars — unlimited tokens, SSOT, and an internal skill marketplace — are what turned isolated agents into a genuine AI native operating model.

How Do You Make Claude Code the Main Operating System?

Claude Code as a main operating system is a setup where most tasks previously done through web UIs are instead handled through conversations with a coding-capable agent. For GPTers, this is the explicit goal, though not yet fully achieved.

The biggest blocker is external data connectivity. In parts of the B2B education business, data lives in spreadsheets and web tools with no clear home base. Without cleaned data and stable APIs, Claude Code can’t access or manipulate what it needs.

To surface these gaps, GPTers introduced a “leaving work interview” practice. An agent called Jarvis interviews each teammate at the end of the day:

• What did you work on today?
• Why couldn’t you complete this task inside Claude Code?

Analyzing these logs reveals exactly which external services, missing APIs, or data structures are blocking full migration into the Claude Code environment.

The founder’s conclusion: “If starting from zero, begin with assetization.” Get data API-accessible and define a single source of truth before expecting agents to run the show.

This matches a broader lesson I keep running into: sophisticated agent orchestration doesn’t help if your data is still scattered CSVs and ad hoc SaaS accounts.

How Are AI Agents Starting to Design the Community Itself?

A proactive advisor agent is an AI that doesn’t just execute instructions — it suggests new structures and initiatives based on system-wide data. Bbojjaki is moving into this role.

Because it can access the LMS, Airtable databases, Zoom logs, and Channel Talk histories, Bbojjaki now proposes things like:

• New open chat rooms tailored to observed member interests.
• Dashboard configurations that would improve member accessibility.
• Future AI talk topics based on past attendance and feedback patterns.

With operational work offloaded, the human operator can focus on community ecosystem design: opening free webinars anyone can host, designing contribution-based rewards like “acorns” for participation, and building mechanisms that make the community more self-sustaining.

From the operator’s perspective, Bbojjaki has become an active thinking partner, not just an extra pair of hands.

A free webinar on Open Claude drew around 500 registrants — a signal that there’s real appetite for practical deployment stories like this one. GPTers also launched an official Open Claude chat room to collect data on what different roles and company sizes actually need from AI assistants, with plans to turn those insights into specialized study tracks.

The shift worth noting here is that the agent isn’t just running the community anymore. It’s helping design its future.

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 for running Anthropic’s Claude models as persistent agents in environments like Slack or Telegram. Unlike simple chatbots, Open Claude agents can call tools, manage structured memory, and execute pipelines to autonomously perform multi-step operations across systems like Notion, Airtable, or LMS platforms.

Q: Why did GPTers adopt a multi-agent “senior–junior” structure?

A: GPTers moved to a senior–junior setup to eliminate the human operator as a coordination bottleneck. By letting a senior agent (Bboya) review, guide, and co-design workflows with a junior agent (Bbojjaki), they automated not only task execution but also continuous quality improvement and process documentation — including an agent-written team charter.

Q: How does Bbojjaki handle security and sensitive information?

A: Sensitive tasks involving payment data are handed off to a separate “Bbojjaki External” agent running in an isolated workspace. This keeps core internal data from being exposed to risky prompts or external inputs and provides a structural defense against prompt injection attacks.

Q: What kinds of tasks can Bbojjaki automate in the community?

A: Bbojjaki automates over 30 skills, including Airtable CRUD operations, coupon issuance and SMS campaigns, membership extensions, under-enrollment notifications, Zoom scheduling and feedback collection, and cross-analysis of transcripts and surveys. It also handles CS through community boards and Channel Talk, and answers onboarding questions from new teammates on weekends.

Q: What are the first steps to make Claude Code a main operating tool?

A: Start by assetizing data — consolidate it into API-accessible systems and establish a single source of truth. Then route daily work into the Claude Code environment and log every case where tasks had to be done outside, as GPTers does with its Jarvis “leaving work interview.” Those logs reveal exactly which external services and data gaps need to be addressed before the transition is complete.

Conclusion

Three things stand out from GPTers’ journey. Agents become genuinely useful only when given shared access to real operational data. Their memory and outputs need to be treated as versioned assets, not throwaway context. And the human organization has to commit to working inside the agent environment, not alongside it as an afterthought.

From a single helper bot to a senior–junior multi-agent team that writes its own charter and proposes new community structures, GPTers shows what AI native operations actually look like — not as a demo, but as a daily reality. The hard work wasn’t prompt engineering. It was restructuring data, workflows, and budget: unlimited tokens, a single source of truth, and a skill-sharing ecosystem built for the whole team.

As more organizations adopt similar patterns, the question will shift. Not “how do we automate this task?” but “which parts of our organization can we safely let agents redesign?” For GPTers, that conversation is already happening inside a Slack channel named after an AI teammate.