Get Started with Trinity in 40 Minutes: A Practical Guide to Building 4 Collaborative AI Agents

Trinity: An Organizational Operating System for Agents

Now that "AI-native company" has become a buzzword, how to make multiple agents truly work together rather than each operating in isolation is a real challenge many teams face. A 40-minute workshop recording on Bilibili demonstrated the complete process of building four collaborative AI agents using the open-source orchestration tool Trinity. Rather than staying at the conceptual level, the demo walked step by step through instance deployment, template creation, permission configuration, and cross-framework migration to build a mini-organization called Keymaker.

Trinity is essentially a platform for orchestrating and running agents. Its goal is not to produce a pile of automation scripts, but to let agents coexist long-term and accumulate experience like company employees. Each agent corresponds to a GitHub repository, has its own independent sandbox environment in a Docker container, and is designed as a stateful, collaborative entity.

The demo instance showed a clear hierarchical architecture: at the top, a Chief of Staff orchestrates the other agents; a second-brain agent based on Cornelius technology provides a continuously updated decision-making perspective; and below that are functional roles such as sales, product manager, and illustrator. They collaborate through message passing and task execution rather than running in isolation. Interestingly, Trinity remains neutral about the underlying model framework — the current instance uses Claude Code throughout, but it also supports Codex, Gemini, and others, reducing the risk of a team being locked into a single tech stack.

From Library to Instance: Creating Agents in Three Steps

The core operations of the workshop centered on a brand-new instance called Keymaker. The path to creating an agent is very intuitive: go to the Library's agent template tab, select the Keymaker sales, delivery, or marketing template, click "Use Template," and give it a name. Because the templates are public, no GitHub personal access token needs to be configured initially, lowering the barrier to entry.

One practice worth borrowing: the presenter created a separate GitHub organization for Keymaker and generated a general access token for that organization. The benefit is a clear permission boundary — agents creating repositories and committing code within the organization won't overstep. Then, through the skills library, each agent is assigned standard operating procedures — for example, giving the sales agent the ability to create scripts, use an image generator, or manage projects. This "template + skills" combination keeps agents lightweight while making them extensible.

The difference between GitHub Personal Access Tokens (PAT) and organization-level tokens is worth explaining. A PAT is bound to a specific user account, and its scope typically covers all repositories that user can access, so a leak has a large blast radius. An organization-level token (such as a fine-grained PAT granted to an organization) can strictly limit permissions to repositories within a specific organization and can be refined down to specific operations like read, write, commit, and create. Creating a separate GitHub organization for Keymaker and generating a general access token is essentially drawing an isolation boundary between the agent and the human account: the agent can only act within the Keymaker organization, which avoids accidental operations affecting personal or other project repositories and also makes permission auditing traceable. For multi-agent systems, this "one organization, one token" approach is the lowest-cost permission-boundary practice.

Permission Configuration: Turning Islands into a Team

The three newly created agents didn't know the others existed. In the demo, when the delivery agent was asked about the product launch plan, it replied directly, "That's not in the lifecycle I'm responsible for." The solution is to check, in each agent's permission settings, the other agents it is allowed to communicate with. A few seconds later, the delivery agent could proactively call the marketing agent to get information when receiving a question and bring the result back into the conversation.

This design reveals a key idea: multi-agent collaboration does not rely on a central brain forcibly scheduling everything, but rather forms a network through peer-to-peer permission grants. The presenter later demonstrated the multi-agent conversation feature in the workspace — selecting the delivery and sales agents and @-mentioning them caused the two to collaboratively plan next quarter's capacity. For teams looking to introduce AI-native workflows, this gradual authorization is more controllable than one-shot full automation.

The distinction between peer-to-peer authorization and central scheduling is a key dividing line in multi-agent architecture. In the central scheduling model, a master control agent uniformly assigns tasks and all communication passes through the hub; the advantage is global controllability, but the downside is that the master control becomes a single-point bottleneck, and adding new roles requires modifying the master control logic. In the peer-to-peer model, each agent declares "who I can talk to" in its permission table, communication happens directly between members, and the network topology grows dynamically with authorization. Trinity adopts the latter: once the delivery agent is authorized to access the marketing agent, it can initiate requests on its own and integrate the results during a conversation without routing through the Chief of Staff. This is closer to how real organizations operate — adding new members only requires adding authorization relationships rather than restructuring the entire orchestration logic, at the cost of needing more careful permission-matrix design to avoid communication chaos.

Cross-Framework Migration: Bringing Existing Agents into Trinity

The most practically valuable part of the workshop was how to migrate agents that are not part of the Trinity system. The demonstrator opened an ordinary desktop Claude Code project containing three agents: meeting notes, invoice reminders, and lead scoring. By installing the "agent cluster analysis" and "agent cluster migration" plugins, the system automatically identified the purpose and structure of the three agents.

After running the migration command, the system created copies rather than destroying the original files and generated a Trinity-compatible format. The presenter emphasized that Claude-based agents usually require only minor modifications, mainly supplementing the agent definition and auxiliary skills. After migration, through the Trinity onboarding plugin, deployment to the instance happens directly from the GitHub repository, and the whole process is completed over an MCP connection without manually moving configuration. In the end, the originally isolated meeting-notes bot gained permission to access the sales, marketing, and delivery agents, becoming the fourth collaborating member.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024 to standardize how large language models connect to external tools and data sources. It defines a client-server architecture: the model acts as the client and calls packaged tool servers through a unified interface, thereby accessing resources such as file systems, databases, and code repositories. The core value of MCP is decoupling — tool developers only need to implement an MCP server once, and it can be called by any model or agent framework that supports the protocol. After migration, deployment directly to the instance over an MCP connection is precisely an application of this protocol: Trinity packages the GitHub repository, deployment process, and other elements as MCP tools, so agents can complete operations without knowing the underlying implementation details. This is also the technical foundation that enables cross-framework migration to achieve "no manual configuration moving."

The Boundary Between Open Source and Enterprise Editions

The Q&A session revealed the product's tiering logic: independent developers or small teams can use the open-source edition, whose core functionality is quite complete; enterprise licensing is needed only when a company requires compliance, multi-user role management, or collaboration among dozens of people. This division is relatively friendly to startup teams with limited budgets. In addition, the presenter mentioned that the canvas is currently positioned as a visual collaboration interface rather than a BI tool, but the Trinity hierarchy has begun storing business metrics and will integrate with tools such as Power BI in the future.

Practical Takeaways

The value of this workshop lies in breaking "AI-native company" down from a slogan into executable steps: first have an orchestration platform and sandbox environment, then use templates and skills to quickly build roles, then use permissions to make roles aware of one another, and finally migrate existing agents in to expand the team. Throughout the process, humans always retain approval gates and credential control — for example, centrally managing keys through a 1Password service account. For developers who want to try it hands-on, they can start with a local Docker deployment of Trinity, practice with public templates, and then gradually connect real CRM and marketing data sources. The barrier to multi-agent collaboration is shifting from architecture design to configuration operations.

One-line Summary

Use the open-source orchestration tool Trinity to build a mini-organization of four collaborative AI agents from scratch.

Paragraph Summary

Based on a 40-minute workshop recording, this article fully demonstrates the process of building a multi-agent collaboration system using the open-source orchestration platform Trinity. Trinity treats each agent as a stateful entity running in an independent Docker sandbox, corresponding to a GitHub repository, and organizes collaboration through a hierarchical architecture (Chief of Staff, second brain, functional roles). Using the Keymaker mini-organization as an example, the demo completes, in order, template-based agent creation, skills-library SOP assignment, peer-to-peer permission authorization to connect isolated agents, and conversion of existing Claude Code agents into Trinity-compatible format through cluster analysis and migration plugins for direct deployment. The article also explains the applicable boundaries of the open-source and enterprise editions and distills an executable path: orchestrate first, then build roles, then open permissions, and finally migrate and expand.