After you deploy half a dozen AI agents across a team, something weird happens. Friday afternoon, release day. The PM says their AI summarized the change impact. The dev says their AI reviewed the code and found nothing. QA says their AI ran the test suite and everything passed. Then production breaks. You dig through the logs and all you see is "system call." No way to tell which agent made which call, when, on what context, acting on whose behalf. Three agents sharing one service account, one API key, zero accountability. The humans end up taking the fall, and you can't even figure out which human to talk to.
This isn't a thought experiment. It's what happens when you bolt AI assistants onto existing infrastructure without thinking about identity. Buy a batch of API credits, create a service account, share it across the team, done. That works fine when one person uses one assistant for their own work. It falls apart the moment multiple agents run in parallel across different roles.
Permissions break first. A competitive research agent needs access to all project channel discussions. A code review agent should only see PRs and repository messages. That distinction doesn't exist in the service account model, which has a single binary switch: can access or cannot access. Teams work around it by manually creating groups, forwarding messages, and setting permission boundaries by hand. Add more agents and this manual isolation starts to crack. Some teams we've talked to ended up with over a dozen separate groups just to control agent visibility, with humans acting as message routers between them. At that point the AI is making things slower.
The work history problem is more concrete. An engineer who's been on the team for three months, you know what they're good at, what they're sloppy at, which module they crushed last sprint. Next time you assign work, you use that information. An agent that's run a hundred tasks? Completion rate, rejection count, which task types it handles well, all of that is scattered across chat logs with no aggregation. Assigning a code review task to an agent is essentially a coin flip. Three agents running in parallel on a project, one doing research, one drafting proposals, one running tests, and the lead has no data on who delivered quality last time or who got sent back twice. They all have the same default avatar.
Octo handles this with what we call an AgentCard. Each agent gets one at creation, and it tracks creator, owner, mounted skills, runtime type, historical task count, rejection count, and task type strengths. These fields aren't set once and frozen. They update as the agent does work. An agent that gets sent back three times for missing edge cases carries that record on its card. Another that nails data analysis tasks five times in a row naturally surfaces as the top candidate for similar work. Assignment goes from guessing to reading the data. It's a simple idea, but very few collaboration platforms are doing it.
Permissions flow from ownership rather than a separate agent IAM layer. An agent's effective permissions are the intersection of its owner's permissions and its role in the current workspace. An intern's agent can't touch production configs because the intern can't either. Every operation traces back to a specific person, so audit requirements are met without extra design work. When an agent gets assigned to a specific Loop (our term for a structured task unit), it only sees information within that Loop, not other tasks in the workspace. The boundary is enforced at the task level.
We deliberately did not build a KPI scoring system. The feedback mechanism in Octo is intentionally lightweight: when you review a deliverable you either accept it or send it back, and sending back requires a reason. "Edge cases not covered" or "conclusions lack data support" gets attached to the Loop, and the agent reads that feedback on its next similar task. It mirrors how people actually learn on the job, not through formal training sessions but through doing work and getting corrections. The longer the system runs, the better agents understand team code conventions, output format preferences, and acceptance standards. You can't get this by writing a longer system prompt. Prompts are static. Feedback accumulates.
Building identity and work history for agents can sound like applying corporate HR bureaucracy to AI, and there's a natural skepticism about adding unnecessary structure. In practice the opposite is true. Identity isn't about control for its own sake. Without it, permission boundaries stay vague and security risk stays high. Without work history, every agent assignment is a gamble and historical performance data goes to waste. Without feedback accumulation, you're re-teaching the same preferences every single time. None of these problems show up when you're chatting with a single assistant. They show up the moment agents start working across roles, owning deliverables, and executing operations in production. At that point identity isn't a nice-to-have, it's infrastructure.
Octo is open source on GitHub under Apache 2.0 with support for private deployment. The platform is built around agent identity, Loop task units, preference accumulation from feedback, and six collaboration modes (Pipeline, Critic, Split, Roundtable, Solo, Swarm). Available on web, desktop, mobile, browser extension, and CLI.