How to Build Open Source for AI Agents

Hugo Santana Aug 31, 2026 Some of the fastest-growing products today have one thing in common, they’re open source. Tools like PostHog, Supabase, n8n, Postiz, or Resend have supercharged their growth by being extremely transparent. The secret is that the growth is coming from agents like Claude, ChatGPT, and Hermes, as they can discover these products, understand how they work, use them, and even contribute back. In this article, I’ll show 5 best practices followed by these companies to make your open source agentic ready. Some are existing standards that became even more important, and others are specific for AI agents. I just launched a YouTube channel for Agent-led Growth. If you prefer video format, this one is for you… 1. Keep It Simple Naming with intent All the naming in your repo should have an intent. From organization name, descriptions, to repos folders, packages, functions, services, and even APIs names, should say exactly what they do. Use the words people and agents are likely to search for. If you built an recipe generator for cooking say “recipe generator”. Don’t hide it behind an internal product name nobody knows yet. Monorepos Guillermo Rauch@rauchg Your software factory should be a monorepo. All your company context (design, marketing, sales, engineering, support…) in one place for agents to build upon Turborepo @turborepo Turborepo is the build system for agentic coding. https://t.co/C3NLzzs2P8 8:00 PM · Aug 18, 2026 · 338K Views 159 Replies · 150 Reposts · 3.24K Likes The first pattern across these repos is simplicity. One effective approach is using a monorepo. That’s the case for PostHog, n8n and Postiz. A monorepo brings your context together. The product, packages, documentation, design, sales, marketing, and support can all live there, so agents don’t need to jump across multiple sources. For newer products, this is almost a no-brainer. Monorepos are growing in adoption because they are an effective way to handle agent’s context. The challenge is for existing products, where multiple repos or services are in place. Although you should aim to condense information, monorepos are not a must. Supabase is more modular, and Resend uses separate repositories for SDKs, React Email, examples, MCP, and other tools. 2. Write Docs for Agents This is probably the biggest mental change, and those not following are blocking all agents from reaching your repo. README Designed to be the first thing developers read, that still holds, but these days that means agents. So, a good README explains your project cleanly, how to start and should point to the other intro files. Agents.md, Claude.md and Agent skills Then give agents explicit instructions with AGENTS.md (PostHog and n8n) or CLAUDE.md (Postiz, for Claude specific instructions). Supabase uses agent skills and agent-specific instructions across its repositories. These files should explain: how the project is structured where important code lives how to make changes how to test them which conventions to follow what constraints to respect A few tips: Critical information should come first. If you maintain both AGENTS.md and CLAUDE.md, they should never contradict each other. Today, Claude Code looks for CLAUDE.md, not AGENTS.md, which is a good reason to support both… But Claude refusing to support Agents.md is annoying. tobi lutke@tobi I’m thinking about banning Claude code at Shopify until they change their mind and read AGENTS.md and .agents/skills etc. Insisting on only reading CLAUDE.md sometimes leads to split brain problems when different team members use different tools. Just unnecessary. 2:34 PM · Aug 25, 2026 · 725K Views 671 Replies · 523 Reposts · 11.9K Likes That can change over time, and eventually one standard file might be enough. Remember: Conflicting instructions create errors, waste tokens, and make the codebase harder for agents to trust. Robots.txt robots.txt tells crawlers which parts of a site they are allowed to access. Incorrect or non existent robots could block crawlers from indexing and showing your product on ChatGPT, Claude and other AI assistants answers. llms.txt llms.txt is an emerging convention for pointing language models toward the structure, or map of a site. 3. Give Agents a Way to Use the Product The ideal scenario is to give agents interfaces they can use after reaching your repo or docs. That can be: APIs: Let agents call your product’s functionality directly through structured requests. MCP: Let agents discover and use your product’s tools through a standard agent interface. CLIs: Let agents control your product through terminal commands. SDKs: Give agents ready-made code libraries for integrating your product into applications. Examples & templates The 5 tools are especially strong here. Agents can use the product programmatically instead of reproducing the functionality themselves. In some cases, rebuilding your product or parts of your product for self hosting are valid, but today, the single best way is to provide APIs, MCPs, or CLIs. MCPs connect services and tools to agents, and by doing so, transform them into infrastructure. Instead of your product being something an agent can replace, it becomes infrastructure the agent depends on. MCPs have been shining because most people just want to talk to their agent, which is the one interacting with different services and products. Examples and templates show agents the intended way to use the product and make integrations easier to find, copy, and adapt. They also serve as discovery real estate that agents will get trained on and boost your positioning in AI assistants. 4. Make It Easy to Run There should be one obvious path to use the product through one of the previous interfaces. It gets a bit trickier when you also want users to self-host. For self-hosting setups Self-hosting means the user runs the software on their own infrastructure. Hosted service means a company runs it for them. A simple example: with n8n, you can either run n8n yourself on your own server, or pay n8n to host and manage it for you. That means: clear installation instructions an .env.example simple development commands clear build and test commands clear instructions for any API keys the user needs to provide But “runnable” also needs to be realistic. If the product depends on ten services and only three are core, don’t force all ten into the basic setup. Keep non-core services optional. Remember, the goal is that agents reach a useful working state with the minimum required stack. When you provide self-hosting as an option, your service becomes running your product with high quality. Bring your own Keys (BYOK) This matters even more when users provide their own API keys. If users are expected to provide their own OpenAI, Anthropic, Resend, or other credentials, that flow needs to feel complete. List every key, explain what it unlocks, show where it goes, and make optional integrations truly optional. Coming back to n8n, they take this further with an agent:setup command. One command prepares the project, builds it, runs checks, and returns structured results. The fewer decisions required during setup, the easier the product is to run. Make the Boundaries Clear Simplicity is the goal, but bigger products naturally become more complex. PostHog separates open-source and enterprise code. n8n uses licensing boundaries. Supabase splits its platform across multiple open-source services. Postiz exposes the core self-hostable product. Resend keeps its hosted product private while open sourcing much of the ecosystem around it. Different ways to handle complexity in open source projects. The code can be open, while the business is running it reliably at scale, handling infrastructure, support, security, upgrades, and everything around it. Use configuration to turn hosted or paid capabilities on and off where needed, while keeping the open product complete enough to be genuinely useful. Licensing State clearly what license applies, what users are allowed to do, and where the boundaries are. A useful approach is to separate the code license from the brand. You can allow people to use the code without giving them unlimited rights to your name, logo, or trademarks. You don’t need to open source everything, just make the boundary impossible to misunderstand. 🔐 Note: Security If you are open-sourcing an existing private repository, check the Git history before you publish it. Old commits can contain deleted API keys, internal URLs, customer information, or files you never intended to release. Scrubbing Git history before going public is part of the open-source process, not an afterthought. 5. Make Contributing Easy Explain pull request guides, how to run the tests, and what a valid change should look like. Once a project has a meaningful number of contributors, the process needs more structure. That can include: CONTRIBUTING.md testing requirements security policies coding conventions review rules clear ownership of different parts of the codebase Coding agents make contributing easier, but only when the rules are clear. A well-defined contribution process helps both humans and agents produce changes that actually fit the project. These guidelines can also be encoded as skills, so agents can automatically review PRs or keep them in mind while making changes. All the tools we evaluated have explicit instructions on how to use coding agents. Agent-friendly does not mean accepting every agent-generated PR. PostHog and n8n explicitly accommodate AI-assisted contributions, while Postiz currently rejects PRs primarily generated by AI. The common principle is make the rules machine-readable and impossible to misunderstand. 📊 I put together the full comparison table showing how PostHog, Supabase, n8n, Postiz, and Resend handle each of these best practices. Closing Takeaways Monorepo is the most optimal configuration Agentic docs (Agents.md, Claude.md, llms.txt, robots.txt, skills) should be part of the repo A setup designed for machines removes friction Interfaces (APIs, MCPs, CLI, SDKs) turn every product actionable quickly and into infrastructure. You don’t need to Open-source everything, just define the boundaries perfectly Examples and templates are distribution not only on boarding In conclusion, the winning agentic open-source projects are easy to find, easy to understand, easy to run and easy to contribute to. Sources Posthog repo: https://github.com/PostHog Resend repo: https://github.com/resend Postiz repo: https://github.com/gitroomhq/postiz-app Supabase repo: https://github.com/supabase n8n repo: https://github.com/n8n-io n8n Sustainable Use License: https://docs.n8n.io/privacy-and-security/sustainable-use-license