Restructure Repo to Support Community Contributions (SDKs, Clients, Apps, Frameworks, Languages)

[NathanTarbert]

Discussed in #246

^{Originally posted by NathanTarbert July 29, 2025}
As we expand the ecosystem around AG‑UI, we need a clearer repo structure that separates core code from community contributions, without creating ambiguity around what's officially maintained.

Goals

• Make space for growing community interest (SDKs, integrations, apps)
• Prevent clutter/confusion in core folders
• Encourage contributions with a discoverable and well-scoped layout

Proposed Folder Structure with some example contributions and where they will live

.
├── docs/
├── sdks/
│   ├── python/
│   ├── typescript/
│   └── community/
│       ├── nim/
│       ├── rust/
│       └── c-sharp/
├── integrations/
│   ├── agno/
│   ├── langgraph/
│   ├── crew-ai/
│   └── community/
│       └── dify/
├── apps/
│   ├── dojo/
│   ├── cli-client-tutorial/
│   └── community/
├── package.json
└── pnpm-workspace.yaml

Benefits

• Core SDKs and integrations stay clearly scoped
• Community packages get first-class visibility without affecting stability
• Contributors get a clear place to plug in

Next Steps

• Get feedback on structure
• Migrate current SDKs and apps accordingly
• Update contributing guide to reflect layout and naming expectations

Open to feedback or alternatives, especially around naming conventions (community, contrib, etc).

Let's finalize a structure that scales with us.

[NiuBlibing]

Great! It is more clear!

[NathanTarbert]

@NiuBlibing, great to hear.

We are working hard to get a bunch of the pending PR's reviewed and merged to avoid rebase, then we'll restructure the repo into something very similar to this proposal.

[mattsp1290]

SDKs get differentiated but I don't see the same for integrations and apps from the AG-UI team or community. iiuc all integrations today are python and all apps are typescript.

I could see it being frustrating for users down the line when there are dozens of integrations, a handful of supported languages and nothing about the repo structure tells you which of those integrations are actually relevant to your backend without reading the README.md for each integration