Project API Reference

A Project is a high-level organizational concept in BindAI for grouping the components that make up an AI solution. A project can conceptually bring together applications, agents, workflows, tools, Knowledge, Memory, Connections, configuration, and deployment resources. The current BindAI architecture does not require all of these resources to be owned by a single Project runtime object. This page therefore documents the Project concept and clearly separates it from subsystem-specific APIs.

Overview

A BindAI solution can be organized conceptually as:

Project
   |
   +---- Applications
   |       |
   |       +---- Agents
   |       +---- Workflows
   |
   +---- Tools
   +---- Knowledge
   +---- Memory
   +---- Connections
   +---- Configuration
   |
   v
Deployment Environment

The project provides an architectural boundary rather than necessarily acting as a single runtime manager for every component.

Project Responsibilities

At the architectural level, a project can be used to organize:

Applications
Agents
Workflows
Tools
Knowledge resources
Memory
Connections
Provider configuration
Environment configuration
Deployment configuration

The appropriate runtime APIs remain owned by their respective subsystems. For example:

Agents are managed through the Agent API.
Tools are managed through the Tool and ToolRegistry APIs.
Memory is managed through Memory providers.
Knowledge is managed through Knowledge and retrieval APIs.
Connections are managed through ConnectionManager and ConnectionRegistry.
Workflows are managed through the workflow subsystem.

Project Structure

A typical application architecture can be organized as:

Project
   |
   +---- Application
   |       |
   |       +---- Agent
   |       +---- Workflow
   |       +---- Tools
   |
   +---- Knowledge
   |
   +---- Memory
   |
   +---- Connections
   |
   +---- Providers

This organization helps keep application boundaries clear.

Applications

Applications represent logical AI solutions or business capabilities. A project may contain multiple applications conceptually. For example:

Project
   |
   +---- Customer Support
   |
   +---- Research Assistant
   |
   +---- Internal Automation

Each application can use the BindAI components appropriate to its responsibilities. The current Project architecture does not require a specific Project.application() runtime method.

Agents

Agents provide the primary AI execution capability. A project can organize multiple agents according to application requirements.

Project
   |
   +---- Support Agent
   +---- Research Agent
   +---- Analysis Agent

Agents are configured through the Agent API. For example:

from bindai_core import Agent

agent = (
    Agent.builder()
    .name("assistant")
    .instructions("You are a helpful assistant.")
    .provider("openai:gpt-4.1-mini")
    .build()
)

Project organization does not change the Agent API.

Workflows

Workflows provide orchestration between multiple operations. A project can contain workflows conceptually:

Project
   |
   +---- Workflow A
   +---- Workflow B
   +---- Workflow C

Workflows can coordinate:

Agents
Tools
Conditions
Loops
Parallel execution
Retries
Timeouts
Knowledge
Memory
External integrations

The workflow subsystem owns the actual workflow execution behavior.

Tools

Tools provide reusable operations that agents and workflows can invoke. A project can organize tools at an application or shared architectural level. For example:

Project
   |
   +---- Search Tool
   +---- Database Tool
   +---- Notification Tool

BindAI’s actual tool registry is responsible for registering and resolving tools. A shared tool can be supplied to multiple agents:

agent = Agent.builder().provider("openai:gpt-4.1-mini").tool(search_tool).build()

A project should not be assumed to expose a separate add_tool() API.

Knowledge

Knowledge provides application data that can be retrieved and used to ground agent responses. Conceptually:

Project
   |
   v
Knowledge
   |
   v
Retriever
   |
   v
Agent

Knowledge can include:

Documents
Parsed content
Chunks
Metadata
Embeddings
Vector indexes
BM25 indexes
Hybrid retrieval
Reranking

The Knowledge subsystem provides the corresponding ingestion and retrieval APIs.

Memory

Memory provides storage and retrieval for application information. Conceptually:

Project
   |
   v
Memory
   |
   v
Agent / Application

Current BindAI memory capabilities include:

In-memory storage
SQLite
PostgreSQL
Vector memory
Pinecone
Chroma

Memory should be configured according to application requirements rather than assumed to be automatically managed by a Project object.

Connections

Connections integrate applications with external services. Current integrations include:

Webhooks
GitHub
Slack
Notion
Jira
Discord
Resend
Vercel
Netlify

The Connections package provides:

Connection
ConnectionRegistry
ConnectionManager

For example:

from bindai_connections import ConnectionManager

manager = ConnectionManager()

Connections can then be managed independently of the broader project architecture.

Providers

Projects can use different model providers depending on application requirements. Current provider integrations include:

OpenAI
Anthropic
Google Gemini
Groq
Ollama
OpenRouter

An agent can select a provider and model through its configuration. For example:

agent = Agent.builder().provider("openai:gpt-4.1-mini").build()

Provider configuration can be changed between environments without changing the overall project architecture.

Configuration

Project-level configuration is an architectural concern. Typical project configuration may include:

Environment settings
Provider configuration
Database configuration
Storage configuration
External-service configuration
Feature settings
Deployment configuration

The current Project documentation does not assume a specific ProjectConfiguration runtime class unless implemented by the installed version.

Environment Separation

A project can be deployed across multiple environments.

Project
   |
   +---- Development
   |
   +---- Staging
   |
   +---- Production

Each environment can use different:

Model providers
Credentials
Databases
Knowledge indexes
Memory providers
Connections
Logging configuration

Application logic should remain as environment-independent as practical.

Project Boundaries

A useful project boundary groups components that belong to the same solution. For example:

Customer Support Project
   |
   +---- Support Application
   +---- Support Agents
   +---- Support Workflows
   +---- Support Tools
   +---- Support Knowledge
   +---- Support Memory
   +---- Support Connections

Project boundaries can help with:

Organization
Configuration
Security
Testing
Deployment
Ownership
Resource isolation

Shared Resources

Some resources can be shared across applications. Conceptually:

             Project
                |
       +--------+--------+
       |        |        |
       v        v        v
    App A    App B    App C
       \        |       /
        \       |      /
         +------v-----+
             Shared
          Resource

Examples can include:

Tools
Knowledge
Memory
Connections

However, sharing should be deliberate. Shared resources can introduce:

Permission concerns
Data isolation issues
Configuration conflicts
Concurrent access
Operational coupling

Project and Agent

Projects organize agents. Agents perform AI execution.

Project
   |
   v
Agent
   |
   v
Model Provider

The Project concept should not replace the Agent API. Agents remain independently configurable and executable.

Project and Workflow

Projects organize workflows. Workflows perform orchestration.

Project
   |
   v
Workflow
   |
   +---- Agent
   +---- Tool
   +---- Condition
   +---- Loop

The Workflow subsystem remains responsible for workflow execution.

Project and Tools

Projects can provide an organizational boundary for reusable tools. Tools remain independently registered and executed through the tool system. This separation allows:

Project
   |
   +---- Shared Tool
   |
   +---- Application A
   |        |
   |        v
   |      Agent
   |
   +---- Application B
            |
            v
          Agent

A shared tool should only be exposed to applications and agents that require it.

Project and Knowledge

Knowledge can be organized around project or application boundaries. For example:

Project
   |
   +---- Product Knowledge
   +---- Support Knowledge
   +---- Internal Documentation

Knowledge isolation is particularly important when multiple applications operate over different data domains.

Project and Memory

Memory should be scoped according to application requirements. Possible boundaries include:

Application-level memory
User-level memory
Conversation-level memory
Shared operational memory

The appropriate scope depends on the data and privacy requirements of the application.

Project and Connections

Connections can be organized around the services required by a project. For example:

Project
   |
   +---- GitHub
   +---- Slack
   +---- Jira
   +---- Resend

Connection credentials should remain isolated and securely managed.

Project and Deployment

The project architecture should remain separate from deployment infrastructure. Conceptually:

Project
   |
   +---- Agents
   +---- Workflows
   +---- Tools
   +---- Knowledge
   +---- Memory
   +---- Connections
   |
   v
Deployment Environment

The deployment environment is responsible for concerns such as:

Process management
Networking
Secrets
Persistent infrastructure
Hosting
Scaling
Monitoring

The Project concept does not imply a built-in deployment platform.

Project Lifecycle

A project can be managed through a general application lifecycle:

Design
  |
  v
Implement
  |
  v
Test
  |
  v
Configure
  |
  v
Deploy
  |
  v
Operate

The individual BindAI subsystems participate in different stages of this lifecycle.

Testing

Project-level testing should verify that its components work together. Useful tests include:

Agent execution
Tool execution
Workflow execution
Knowledge retrieval
Memory persistence
Connection behavior
Provider configuration
End-to-end application flows

Subsystems should also maintain their own focused unit and integration tests.

Security

Project boundaries should be reflected in security design. Consider:

Application isolation
Tool permissions
Knowledge access
Memory access
Connection credentials
Provider credentials
External-service permissions
User authorization
Sensitive logging

A project should not be treated as an automatic security boundary unless the deployment architecture explicitly enforces one.

Best Practices

Keep each project focused on a coherent solution.
Define clear application boundaries.
Keep agents responsible for AI reasoning.
Keep workflows responsible for orchestration.
Keep tools responsible for deterministic operations.
Keep Knowledge responsible for retrieval and grounding.
Keep Memory responsible for persistent application information.
Keep Connections responsible for external-service communication.
Keep deployment infrastructure separate from application logic.
Avoid unnecessary shared state.
Apply explicit security boundaries to shared resources.

API Accuracy

The current BindAI architecture does not establish a single Project runtime API that automatically manages every subsystem. This documentation therefore intentionally avoids assuming methods or properties such as:

Project(...)
ProjectBuilder(...)

project.configuration
project.applications
project.tools
project.workflows
project.scheduler

project.add_application(...)
project.application(...)
project.add_tool(...)
project.add_workflow(...)
project.workflow(...)
project.add_schedule(...)

project.run(...)
project.stream(...)

unless these APIs are explicitly implemented by the installed BindAI version. The Project concept should not be confused with the independently implemented Agent, Tool, Memory, Knowledge, Workflow, and Connections APIs.

Current Scope

The current BindAI architecture provides the underlying components that can be organized into projects, including:

Agents
Model providers
Tools
Tool registries
Memory providers
Knowledge and retrieval
Workflows
Connections
Multi-agent execution
MCP integration

The Project layer primarily provides architectural organization at the current stage. Higher-level project management, application registries, deployment management, and hosted project execution remain separate capabilities unless explicitly implemented.

Summary

A Project represents the broader organization of a BindAI solution. Conceptually:

Project
   |
   +---- Applications
   |       |
   |       +---- Agents
   |       +---- Workflows
   |       +---- Tools
   |
   +---- Knowledge
   +---- Memory
   +---- Connections
   +---- Providers
   |
   v
Deployment Environment

The Project concept provides a useful architectural boundary without requiring every component to be controlled by a single runtime object. BindAI’s individual subsystems remain independently responsible for agent execution, tool registration, Knowledge retrieval, Memory storage, workflow orchestration, model providers, and external Connections.

​Project API Reference

​Overview

​Project Responsibilities

​Project Structure

​Applications

​Agents

​Workflows

​Tools

​Knowledge

​Memory

​Connections

​Providers

​Configuration

​Environment Separation

​Project Boundaries

​Shared Resources

​Project and Agent

​Project and Workflow

​Project and Tools

​Project and Knowledge

​Project and Memory

​Project and Connections

​Project and Deployment

​Project Lifecycle

​Testing

​Security

​Best Practices

​API Accuracy

​Current Scope

​Summary