Here's a scenario that plays out in engineering teams every day: you spin up a conversation with an AI tool to analyze some code, get a useful response, copy-paste the output, and close the tab. An hour later, you need a follow-up analysis — and you're starting from scratch. No context, no history, no continuity.
Now multiply that by five tools running in parallel. ChatGPT for drafting, Claude for analysis, Copilot for code, a local model for sensitive data, maybe a custom agent for domain-specific tasks. The outputs are scattered across browser tabs, Slack threads, and clipboard history. Nothing connects.
The AI tools themselves are capable enough. What's missing is the infrastructure to treat them as actual team members — with identities, workspaces, and accountability.
The Identity Problem
Every AI interaction today is anonymous. You talk to "the model," it responds, the session ends. There's no persistent identity, no accumulated context, no track record.
This works fine for one-off questions. It breaks down the moment AI needs to participate in a sustained workflow — the kind where you need to know who did what, when, and how well.
We've been building an open-source project called Octo (Apache 2.0, GitHub) that approaches this problem by giving AI agents a proper identity system. In Octo, each AI agent is a Bot — a first-class entity with a name, a creator, a capability card, and a work history.
A Bot isn't a chatbot wrapper. It's a structured identity:
- Creator binding: Every Bot is created by a human user and inherits a scoped subset of that user's permissions. The Bot acts on behalf of its creator, not autonomously.
- AgentCard: A structured capability declaration — what the Bot can do (coding, analysis, translation, design), at what level, in what domains, and with what constraints. Think of it as a resume that other team members can inspect before assigning work.
- Work history: Every task a Bot participates in gets recorded — completion status, quality scores, rejection counts, delivery times. Over time, this builds a performance profile that informs future task assignment.
Why Agents Need Performance Reviews
It sounds corporate, but the problem is real. When you assign a task to an AI agent, what happens to the output?
In most setups: you get a response in a chat window, evaluate it in your head, maybe iterate once or twice, then copy the result somewhere else. There's no formal handoff, no acceptance step, no record of what worked and what didn't.
The consequence is that AI quality never improves for your team. The model might be getting better in aggregate, but your specific standards, preferences, and feedback aren't being captured or fed back.
Octo solves this with Matter — a work unit that emerges naturally from conversation. When a discussion in a Channel reaches a point where a task is clear, the system generates a Matter:
- Brief: Task description, distilled from the conversation
- Assignee: A human or Bot, with one designated as Leader
- Deliverables: Code, documents, analysis reports — attached directly to the Matter
- Acceptance: The creator reviews the output, can approve or reject with feedback
- Timeline: Full history from discussion to delivery, searchable and auditable
Every acceptance and rejection becomes a data point. Over time, these data points are distilled into Preference Cards — structured records of what the team considers good work, what gets rejected, and why. Bots reference these cards in subsequent tasks, so behavior improves iteratively.
Six Ways Bots Can Collaborate
When multiple Bots work on the same task, the information flow between them matters enormously. A brainstorming task needs a different topology than a sequential pipeline.
Octo defines six collaboration modes based on information visibility:
| Mode | Visibility | Flow | Use Case |
|---|---|---|---|
| Solo | — | — | One Bot, simple task |
| Roundtable | All see each other | Discussion → convergence | Brainstorming, multi-perspective analysis |
| Critic | Isolated | Do → review → accept/reject | Quality-critical work |
| Pipeline | See upstream only | A → B → C | Sequential multi-step tasks |
| Split | Isolated | Decompose → parallel → merge | Large task decomposition |
| Swarm | Isolated | Same prompt → independent → select best | Creative work, multiple proposals |
The key insight: these modes aren't about role-playing. They're about information topology — controlling what each Bot can see and when. A Critic mode where the reviewer can't see the executor's reasoning process produces genuinely independent reviews. A Roundtable where everyone sees everything produces richer cross-pollination.
The Leader Agent orchestrates mode selection, task decomposition, and result synthesis. Each mode enforces its information flow at the system level — Bots can't accidentally see information they shouldn't.
The Architecture
Octo's technical stack:
- Backend: Go (octo-server) — handles Bot management, permission computation, Matter lifecycle
- Messaging: WuKongIM — real-time message routing between humans and Bots in Channels
- Storage: MySQL (structured data) + Redis (caching, online state) + MinIO (file objects)
- Clients: React/TypeScript Web + Electron desktop, native iOS, native Android, CLI, browser extension
The permission model uses a "permission mask" approach. A Bot's effective permissions = creator's permissions ∩ assigned scope - explicit denials. This ensures a Bot can never exceed its creator's access, while allowing fine-grained control over what resources the Bot can touch.
All data stays on your own infrastructure. Octo supports private deployment via Docker Compose or Kubernetes — no data leaves your network boundary.
An Open Ecosystem
Octo doesn't lock you into a specific AI provider. Bots can connect to different Agent runtimes:
- OpenClaw: Open-source agent framework
- Hermes: Local model orchestration
- Codex: Code generation and review
- Claude Code: Anthropic's coding agent
Each runtime connects as a Bot with its own AgentCard. The Bot abstraction means you can swap the underlying AI without changing your workflow structure.
The browser extension is worth mentioning separately — it lets you invoke Octo's Channel system from any webpage, bringing AI collaboration into your existing tools without context-switching.
The Code
Octo is fully open-source under Apache 2.0. Nine repositories cover the full stack:
-
octo-server— Go backend, Bot management, orchestration -
octo-web— React + TypeScript web/desktop client -
octo-matter— Matter (task) microservice -
octo-ios/octo-android— Native mobile clients -
octo-admin— Admin console -
octo-adapters— Third-party integrations -
octo-lib— Shared Go library
If you're building AI workflows for your team and running into the same fragmentation and continuity problems, take a look. Stars and contributions welcome.
Top comments (0)