Skip to main content

​
BindAI Roadmap

BindAI is being built as a complete open-source platform for developing, deploying, automating, and operating AI applications. The roadmap below describes the major capabilities of BindAI and the progression from its core AI application framework toward a broader AI automation and enterprise platform.
The roadmap represents our direction and priorities. Features and priorities may evolve as the framework develops and as we learn from the community.

​
Status markers

  • [x] Completed
  • [~] Partially implemented
  • [ ] Planned / remaining

​
Current — v0.1 Foundation

​
AI Application Foundation

The core application foundation of BindAI is implemented and forms the base of the public framework.

​
Completed

  • AI agents
  • Tools and tool calling
  • Memory and context
  • Knowledge and RAG integration
  • Workflow orchestration
  • Conditional execution
  • Loops
  • Parallel execution
  • Retries and timeouts
  • Human approval and tasks
  • Scheduling
  • Projects
  • CLI tooling
  • Modular package architecture
  • Workflow templates
  • Agent delegation
  • Team delegation
  • Specialist role chains
  • Agent hooks, callbacks, and middleware
  • Agent execution configuration
  • Conversation management
  • Tool registry and execution
  • Structured execution context
  • Runtime and application configuration
  • Package-based framework architecture
  • Documentation and automated testing
The foundation provides a modular Python architecture that developers can extend without being locked into a single AI provider or execution model.

​
Current — Provider Ecosystem

​
AI Providers

BindAI provides a provider abstraction and registry for working with multiple AI model providers.

​
Completed

  • OpenAI
  • Anthropic
  • Google Gemini
  • Ollama
  • OpenRouter
  • Groq
  • Provider registry
  • Provider bootstrap architecture
  • Consistent provider interfaces
  • CLI provider initialization

​
Remaining

  • Azure OpenAI
  • Mistral
  • Additional compatible providers
Applications should be able to switch providers and models without changing their core application architecture.

​
Current — Memory & Knowledge

​
Memory, Storage & Retrieval

BindAI provides abstractions for memory, storage, embeddings, and retrieval.

​
Completed

  • SQLite
  • PostgreSQL
  • Pinecone
  • Chroma
  • In-memory memory provider
  • Vector memory provider
  • Memory provider abstractions
  • BM25 retrieval
  • Vector retrieval
  • Hybrid retrieval
  • Embedding provider abstraction
  • Random/local embedding provider
  • OpenAI embeddings
  • Retrieval configuration
  • Search options

​
Remaining

  • Redis
  • Qdrant
  • pgvector
  • Additional vector and storage providers
  • Unified metadata filtering improvements across providers
The goal is to provide common BindAI interfaces while allowing applications to choose the storage technology that best fits their requirements.

​
Advanced Knowledge & RAG

BindAI provides a knowledge and retrieval pipeline for knowledge-driven applications and agents.

​
Completed

  • Document ingestion
  • Document loaders
  • Document parsing
  • Chunking strategies
  • Embeddings
  • Metadata
  • Semantic search
  • Hybrid search
  • Metadata filtering
  • Reranking
  • Lexical reranking
  • Conversational retrieval
  • Knowledge pipelines
  • Knowledge retrieval integration with agents
  • Retrieval configuration
  • Search options

​
Remaining

  • Citations
  • Advanced document parsing
  • Advanced chunking strategies
  • Additional reranking strategies
  • Advanced hybrid retrieval
  • Advanced filtering
  • Production-scale knowledge pipelines

​
Current — Connections & Integrations

​
Connections

BindAI provides a unified connections architecture for integrating applications with external services.

​
Completed

​
Architecture

  • Connection abstraction
  • Connection registry
  • Connection manager
  • Connection lifecycle
  • Configurable base URLs
  • Authentication configuration
  • HTTP-based integration patterns
  • Integration testing
  • Project-scoped provider connections
  • Connection manifest metadata
  • Secure OS-backed provider credentials
  • CLI connection management
  • Connection-aware provider resolution
  • Connection validation in bindai doctor

​
Integrations

  • Webhook
  • GitHub
  • Slack
  • Notion
  • Jira
  • Discord
  • Resend
  • Vercel
  • Netlify
  • Google Sheets
  • Google Docs
  • Gmail
  • Google Drive

​
Remaining

Additional integrations will be added based on developer and business use cases.
  • Telegram
  • Twilio
  • Microsoft Outlook
  • Microsoft Teams
  • GitLab
  • Linear
  • Trello
  • Asana
  • Airtable
  • HubSpot
  • Salesforce
  • Stripe
  • Additional integrations
The goal is to make integrations modular and easy to create, configure, authenticate, and reuse.

​
Current — MCP

​
Model Context Protocol Integration

BindAI currently includes a lightweight HTTP-based MCP integration bridge. This implementation should not be confused with a complete MCP protocol implementation. It provides a practical foundation for connecting BindAI tools to an external HTTP tool service while leaving full MCP protocol support for a later phase.

​
Completed

  • MCP client package
  • Tool discovery through GET /tools
  • Tool calling through POST /call
  • MCP tools represented as BindAI tools
  • Tool metadata and parameter schema handling
  • BindAI execution context variables forwarded as tool arguments
  • HTTP error propagation
  • MCP integration tests
  • Basic HTTP connection bridge

​
Remaining

  • Full MCP protocol implementation
  • MCP server implementation
  • MCP resource discovery
  • MCP prompts
  • MCP authentication
  • MCP sessions and lifecycle management
  • MCP events and negotiation
  • MCP resources as agent context
  • Expanded MCP protocol support
  • MCP SDK compatibility where appropriate
The current bridge is sufficient for the initial v0.1 integration scope. Full MCP support remains a post-v0.1 capability.

​
Current — Agents & Multi-Agent Systems

​
Advanced Agents & Multi-Agent Systems

The agent runtime already supports a substantial multi-agent foundation.

​
Completed

  • Structured agent configuration
  • Context management
  • Agent memory
  • Delegation
  • Agent handoff
  • Specialist agents
  • Team delegation
  • Role-based agent chains
  • RAG-enabled agents
  • Agent groups
  • Parallel agents
  • Advanced tool execution

​
Remaining

  • Planning
  • Supervisor agents
  • Hierarchical multi-agent systems
  • More advanced coordination strategies
  • More robust multi-agent state management
The objective is to make complex AI systems composable from multiple specialized agents.

​
Current — Automation

​
AI Automation Platform

BindAI provides an automation layer that combines agents, workflows, integrations, triggers, state, history, and background execution.

​
Completed

  • Webhooks
  • Scheduled execution
  • Conditional routing
  • Loops
  • Parallel execution
  • Retry policies
  • Timeouts
  • Human approval
  • Agent execution
  • External service integrations
  • Event trigger framework
  • Unified trigger management
  • Automation definitions
  • Persistent automation state abstraction
  • Automation run history
  • Background automation workers
  • In-process thread-pool execution
  • Automation run lifecycle tracking

​
Remaining

  • Advanced event routing
  • Distributed automation workers
  • Durable distributed execution
  • Queue-backed automation execution
  • Advanced scheduling and recovery
The current automation layer provides the foundation for defining, executing, tracking, and running automations in the background. The v0.1 worker model is intentionally process-local. Distributed workers and queue-backed execution remain future infrastructure work.

​
Current — Public API & Deployment

​
REST API

BindAI now includes a public REST API package for exposing applications and runtime capabilities as services.

​
Completed

  • Public API package
  • REST API
  • API authentication
  • API key authentication
  • Agent listing API
  • Agent execution API
  • Agent streaming API
  • Workflow listing API
  • Workflow execution API
  • Project API
  • Background automation run API
  • Run status API
  • Health endpoint
  • API tests
  • FastAPI integration

​
Current limitations

  • Authentication is based on the configured BINDAI_API_KEY
  • API state is currently process-local
  • Background execution uses the in-process automation worker
  • Streaming currently uses HTTP StreamingResponse
  • Distributed API state
  • Distributed execution
  • Queue-backed background jobs

​
Deployment

​
Completed

  • Docker deployment
  • Dockerfile
  • Docker Compose
  • API container execution
  • Environment-based configuration
  • Container health endpoint
  • Local container validation
  • Compose validation
  • Worker process foundation

​
Remaining

  • Production worker orchestration
  • Queue-based execution
  • Distributed workers
  • Kubernetes deployment
  • Horizontal execution scaling
  • Durable distributed state
Queue-backed execution and Kubernetes are intentionally post-v0.1 infrastructure capabilities and should not block the initial public release.

​
Current — Observability

​
Runtime Observability

BindAI now has a structured event foundation for observing execution.

​
Completed

  • Structured event model
  • Event IDs
  • Event timestamps
  • Event payloads
  • Event bus
  • Event subscriptions
  • Wildcard event subscriptions
  • Application lifecycle events
  • Agent execution events
  • Workflow execution events
  • Node execution events
  • Human task events
  • Model request events
  • Model response events
  • Tool execution events
  • Memory events
  • MCP event definitions
  • In-memory event recorder
  • Execution-level event lookup
  • Event recorder lifecycle management
  • Runtime observability integration

​
Partially implemented

  • [~] Execution history
  • [~] Error visibility
  • [~] Timing information
  • [~] State transition visibility
The current observability layer provides structured runtime events and in-memory recording. It is intentionally lightweight and forms the foundation for future tracing, metrics, and external observability integrations.

​
Remaining

  • Distributed tracing
  • Metrics
  • Persistent execution history
  • Token usage tracking
  • Provider statistics
  • Cost tracking
  • Advanced latency analytics
  • Advanced error tracking
  • OpenTelemetry integration
  • Monitoring integrations
  • External observability backends
  • Production dashboards

​
Current — v0.1 Public Release

​
Public Release Preparation

The initial public release is focused on making the core framework, API, deployment foundation, integrations, MCP bridge, automation, and observability capabilities usable by developers.

​
Completed

  • Core framework foundation
  • Multi-agent foundation
  • Workflow engine
  • Automation foundation
  • Public REST API
  • API authentication
  • Streaming API
  • Background execution API
  • Docker deployment
  • Docker Compose
  • Core integrations
  • Google integrations
  • MCP HTTP bridge
  • Runtime event observability
  • Documentation pass
  • API documentation
  • Deployment documentation
  • Automated tests
  • Ruff validation
  • Ruff formatting
  • MyPy validation
  • Package builds
  • PyPI artifact validation
  • GitHub release-preparation checkpoint

​
Release status

  • Package version reconciliation for the published release line
  • Dependency graph validation
  • Release workflow preparation
  • Final package builds
  • Final clean-install validation
  • PyPI publication of updated package versions
  • bindai 0.1.9 PyPI publication
  • Fresh public PyPI installation verification for bindai==0.1.9
  • Fresh public PyPI installation verification for bindai-cli==0.2.2
  • Published PyPI README synchronization
  • Documentation homepage Quick Start correction
  • Final GitHub release/tag
  • Final release announcement
The v0.1 release does not depend on Kubernetes, distributed queues, full MCP protocol support, advanced tracing, or enterprise infrastructure.

​
Planned — Advanced Infrastructure

​
Distributed Execution

After v0.1, BindAI can evolve from process-local execution toward distributed infrastructure.

​
Planned

  • Queue-based execution
  • Durable job queues
  • Distributed workers
  • Worker pools
  • Retry and recovery across workers
  • Distributed state management
  • Horizontal scaling
  • Kubernetes deployment
  • Durable scheduling
  • Distributed automation execution

​
Future — Enterprise Platform

​
Enterprise Platform

As the platform matures, BindAI will introduce capabilities required by larger organizations.

​
Planned

  • Role-based access control
  • Organizations and workspaces
  • Multi-tenancy
  • Permission management
  • Audit logs
  • Secret management
  • Credential management
  • Security controls
  • Remote workers
  • Distributed execution
  • Worker pools
  • Enterprise monitoring
  • Governance capabilities
  • Enterprise deployment controls
These features will provide the foundation for operating BindAI across larger teams and organizations.

​
Future — Visual Workflow Platform

​
Visual Workflow Platform

The long-term vision is to make BindAI workflows visually composable while preserving the underlying Python framework.

​
Planned

  • Drag-and-drop workflow design
  • Agent nodes
  • Tool nodes
  • Condition nodes
  • Loop nodes
  • Parallel branches
  • Human approval nodes
  • Integration nodes
  • Trigger nodes
  • Scheduling
  • Execution visualization
  • Workflow debugging
  • Agent visualization
  • Workflow run history
  • Visual execution inspection
Developers will be able to move between code-based and visual workflow development while using the same underlying execution engine.

​
Future — Voice AI

​
Voice AI

BindAI will eventually expand into voice-based AI applications.

​
Planned

  • Speech-to-text
  • Text-to-speech
  • Streaming audio
  • Voice agents
  • Conversational voice workflows
  • Real-time interactions
  • Phone integrations
  • Voice memory and context
This will enable applications such as voice assistants, customer service systems, appointment assistants, and industry-specific voice agents.

​
Future — Templates & Business Solutions

​
Templates & Business Solutions

BindAI will provide complete templates demonstrating how the platform can be used to solve real-world problems.

​
Planned examples

  • AI Business Consultant
  • Internal Knowledge Assistant
  • Customer Support Agent
  • HR Leave Automation
  • Invoice Approval
  • Document Processing
  • Research Agent
  • Sales Assistant
  • Finance Assistant
  • Dentist Voice Assistant
  • Additional industry-specific solutions
These solutions will be developed as reusable examples, documentation tutorials, GitHub projects, and educational content.

​
Long-Term Vision

BindAI is evolving toward a complete platform for building AI software. The long-term architecture can be summarized as:
The goal is not simply to provide another AI agent library. The goal is to provide developers with the building blocks required to: Build → Automate → Deploy → Observe → Scale AI applications.

​
Build With Us

BindAI is open source and evolves through real-world usage, experimentation, and community feedback. As new capabilities are introduced, the roadmap will continue to evolve while maintaining the same core principles:
  • Python-first
  • Modular
  • Provider-agnostic
  • Extensible
  • Developer-friendly
  • Production-oriented
  • Open source
Build AI Software. Scale Everywhere.