Building an Identity System for AI Agents: AgentCard and Work Records

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. 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. 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. 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. 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. 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. 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.