PagesThe ideaPossible forms of the systemTechnical base optionsOpen design questionsLimits and securityPersonalities and profilesUse scenariosScenario 1: Local use: me and my agentsScenario 2: Me, my agents and guestsScenario 3: Company: one departmentScenario 4: The whole companyScenario 5: GamesScenario 6: Customers and suppliersPossibilities for companiesPossibilities for gamesThe INEMA case (for discussion)Sources

The INEMA case (for discussion)

Pieces that already exist and would go into the system: - Telegram bots: openpcbot v2/v3, inemaytbot, inemaccbot; - several Claude Code and Codex sessions running in parallel on spark-922b, which is always on; - queues and timers that publish on their own (Spanish queue, finviral, advviral, Aventuras production); - INEMA groups on Telegram that receive posts; - council agents (optimist, devil's advocate, neutral) already created.

Possible readings: - Reading 1: the problem is visibility, and form A (control room) is enough for a good while. - Reading 2: the problem is coordination between agents, and form B/C is what makes the difference. - Reading 3: the value is in a product, offering this to companies or as a game, and internal use becomes the pilot.

Questions for the next conversation

  1. Which of the readings above is closest to what you want?
  2. Form A, B, C or D?
  3. Is it worth testing Buzz [1] before thinking about building something of our own?
  4. Which of the six scenarios in scenarios comes first? Climb step by step, or aim straight at a target scenario?
  5. Who else would join: only you, the team, or students and subscribers?