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

A developer building the open-source Octo project has created an identity system for AI agents called AgentCard and Work Records. The system gives each AI agent a persistent identity, work history, and structured collaboration modes to enable sustained workflows and iterative quality improvement. Octo introduces concepts like Bots, Matters, and Preference Cards to treat AI agents as accountable team members with formal handoffs and feedback loops.

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 https://github.com/Mininglamp-OSS/octo-server 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: 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: 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: 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: 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 octo-web octo-matter octo-ios octo-android octo-admin octo-adapters octo-lib 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.