A Swarms Improvement Proposal (SIP) is a design document that describes a new feature, enhancement, or change to the Swarms framework. SIPs serve as the primary mechanism for proposing significant changes, collecting community feedback, and documenting design decisions. The SIP author is responsible for building consensus within the community and documenting the proposal clearly and concisely.Documentation Index
Fetch the complete documentation index at: https://docs.swarms.world/llms.txt
Use this file to discover all available pages before exploring further.
When to Submit a SIP
Consider submitting a SIP for:- New Agent Types or Behaviors: Adding new agent architectures, swarm patterns, or coordination mechanisms
- Core Framework Changes: Modifications to the Swarms API, core classes, or fundamental behaviors
- New Integrations: Adding support for new LLM providers, tools, or external services
- Breaking Changes: Any change that affects backward compatibility
- Complex Features: Multi-component features that require community discussion and design review
SIP Types
| Type | Description |
|---|---|
| Standard SIP | Describes a new feature or change to the Swarms framework |
| Process SIP | Describes changes to development processes, governance, or community guidelines |
| Informational SIP | Provides information or guidelines to the community without proposing changes |
Submitting a SIP
- Discuss First: Post your idea in GitHub Discussions to gauge community interest
- Create Issue: Submit your SIP as a GitHub Issue with the
SIPandproposallabels - Follow Format: Use the SIP template format below
- Engage Community: Respond to feedback and iterate on your proposal
SIP Format
Required Sections
SIP Header- What problem does this solve?
- Why can’t the current framework handle this?
- What are the benefits to the Swarms ecosystem?
- Detailed technical description
- API changes or new interfaces
- Code examples showing usage
- Integration points with existing framework
- High-level implementation approach
- Breaking changes (if any)
- Migration path for existing users
- Testing strategy
- Other approaches you evaluated
- Why you chose this solution
- Trade-offs and limitations
Optional Sections
- Reference Implementation: Link to prototype code or proof-of-concept (can be added later)
- Security Considerations: Any security implications or requirements
SIP Workflow
- Proposal: Initial submission as GitHub Issue
- Draft: Maintainer assigns SIP number and
draftlabel - Review: Community and maintainer review period
- Decision: Accepted, rejected, or needs revision
- Final: Implementation completed and merged
SIP Status
| Status | Meaning |
|---|---|
| Proposal | Newly submitted, awaiting initial review |
| Draft | Under active discussion and refinement |
| Review | Formal review by maintainers |
| Accepted | Approved for implementation |
| Rejected | Not accepted (with reasons) |
| Final | Implementation completed and merged |
| Withdrawn | Author withdrew the proposal |
Review Process
- SIPs are reviewed during regular maintainer meetings
- Community feedback is collected via GitHub comments
- Acceptance requires:
- Clear benefit to the Swarms ecosystem
- Technical feasibility
- Community support
- Working prototype (for complex features)
Getting Help
- Discussions: Use GitHub Discussions for questions
- Documentation: Check docs.swarms.world for framework details
- Examples: Look at existing SIPs for reference
SIP Template
When creating your SIP, copy this template:This process is designed to be lightweight while ensuring important changes get proper community review. For questions about whether your idea needs a SIP, start a discussion in the GitHub Discussions forum.