Skip to main content

Projects

Projects are the top-level organizational container for a BindAI solution. A Project groups applications, shared tools, workflows, scheduling, and project-level configuration. It also exposes placeholders for project-wide knowledge, memories, and secrets. Projects are provided by the bindai-project package.

What a Project Contains

A BindAI project currently provides these resources:
  • Applications
  • Shared tools
  • Workflows
  • Workflow scheduling
  • Project configuration
  • Project-level knowledge storage placeholder
  • Project-level memory storage placeholder
  • Project-level secrets storage placeholder
The project acts as a convenient root object for composing these resources. A project does not currently provide a complete database-backed resource-management system. Some project-level collections, such as knowledge, memories, and secrets, are currently generic dictionaries intended as extension points.

Project Configuration

Every Project is created with a ProjectConfiguration.
The configuration contains: ProjectConfiguration is a dataclass using slots. The project name is exposed through:
which returns project.configuration.name.

Applications

Applications are the main execution containers inside a project. A project stores applications by name:
Applications can then be retrieved by name:
Adding an application with an existing name replaces the previous entry. Example:
Applications remain responsible for their own agents and application-level execution behavior. The project provides the higher-level container and lookup mechanism.

Shared Tools

Projects contain a shared ToolRegistry. Tools can be registered at project level:
This allows tools to be shared by applications or workflows where the application configuration makes use of them. The project delegates registration to its internal ToolRegistry. The Project API does not define a separate tool implementation system; it provides a convenient project-level registry.

Workflows

Projects contain a WorkflowRegistry. Workflows can be registered with:
and retrieved by workflow ID:
The project also creates a WorkflowScheduler:
Schedules can be added through:
The workflow itself remains responsible for its execution logic. The project provides the registry and scheduling container.

Scheduling

Project scheduling is currently backed by WorkflowScheduler. A schedule can be registered through:
or accessed through:
Scheduling should be understood separately from the bindai-automation worker system. The Project package provides workflow scheduling primitives, while the Automation package provides automation definitions, triggers, background execution, state, and run history.

Knowledge

Projects expose a project-level knowledge collection:
The current implementation initializes this as:
It is therefore currently a generic project-level storage container rather than a complete knowledge-management subsystem. For production retrieval, embeddings, vector databases, document ingestion, and RAG behavior, use BindAI’s knowledge and retrieval components rather than assuming that Project.knowledge provides those capabilities automatically.

Memories

Projects also expose:
The current implementation initializes this as:
This is a project-level extension point. It should not be confused with the framework’s agent memory capabilities. Agent memory is part of agent execution and context management, while Project.memories is currently only a generic project-owned collection.

Secrets

Projects expose:
which is currently initialized as:
This provides a project-level place for application-specific secret references or configuration data. For actual deployments, avoid placing plaintext credentials directly into source code or committed project files. Use environment variables or an appropriate secret-management system for sensitive credentials.

Project Execution

A project provides convenience methods for executing an agent through a named application.

Run

The project:
  1. Looks up the application by name.
  2. Calls the application’s run() method.
  3. Returns the application’s result.

Stream

Streaming is available through:
The project delegates to the selected application’s stream() method. The exact streaming behavior therefore depends on the application’s implementation.

Python Helpers

Project provides several convenience methods for working with its applications.

Membership

This checks whether an application with the given name exists.

Length

returns the number of registered applications.

Iteration

iterates over the project’s registered application objects.

Typical Project Structure

A project can be composed like this:
The project then provides a single root object through which these resources can be accessed.

Projects and Applications

Projects and applications have different responsibilities.

Project

The project provides:
  • project identity
  • application registration
  • shared tool registry
  • workflow registry
  • workflow scheduler
  • project-level configuration
  • project-level extension collections
  • application execution helpers

Application

An application provides the actual application runtime and its configured agents and execution behavior. This separation allows a project to contain multiple applications:

Multiple Applications

A project can contain multiple applications:
They are stored by their application names. Execution can then target a specific application:
This makes the project useful as a top-level container for related applications.

Workflows and Applications

Projects can contain both applications and workflows. They serve different purposes:
Applications are execution containers for configured agents. Workflows provide structured multi-step execution. The project groups both under one project-level configuration.

Connections

External service integrations are provided by the bindai-connections package rather than being implemented directly by Project. Current BindAI connection types include:
  • Webhook
  • GitHub
  • Slack
  • Notion
  • Jira
  • Discord
  • Resend
  • Vercel
  • Netlify
  • Google Sheets
  • Google Docs
  • Gmail
  • Google Drive
Connections can be managed independently and then used by applications, tools, workflows, or other application-level components as appropriate. The project itself does not currently maintain a dedicated connection registry.

Project-Level Resource Sharing

The project provides a natural scope for resources that should be shared across applications. For example:
Shared tools are explicitly represented by the project’s ToolRegistry. Applications retain their own application-level configuration and runtime state.

Isolation

Applications are stored independently by name:
A project does not automatically merge the internal agent registries, memories, or other runtime state of its applications. Resource sharing should therefore be explicit. For example, registering a tool at the project level does not by itself imply that every application automatically uses that tool.

Project API

The current public Project API includes:

Properties

Application methods

Tool methods

Workflow methods

Scheduling

Execution

Python helpers


Project Package

Projects are provided by the bindai-project package. The package currently contains the core project components:
The Project package depends on BindAI’s application, core tool, and workflow components.

Projects in the REST API

The BindAI REST API exposes configured projects through:
Projects must first be configured in the API application:
The API does not automatically discover every Project object in the Python process. The REST API therefore acts as an interface to explicitly configured projects.

Docker and Deployment

Projects can be used in normal Python deployments as well as through the BindAI API Docker image. For API deployment, see: The current API deployment model uses an in-process application and worker model. Distributed project execution, durable queues, and Kubernetes deployment are future infrastructure concerns and are not required for the current v0.1 project model.
Use Project when you need a clear top-level container for related BindAI applications and shared resources. A typical composition is:
Keep application-specific behavior inside the application. Use project-level resources for genuinely shared concerns.

Current Scope

The current Project implementation is intentionally lightweight. It provides:
  • project configuration
  • application registration
  • shared tools
  • workflow registration
  • workflow scheduling
  • project-level extension collections
  • application execution helpers
It does not currently provide:
  • a persistent project database
  • a project-level ORM
  • automatic resource discovery
  • a built-in secret manager
  • a built-in knowledge database
  • a built-in project memory database
  • automatic connection management
  • distributed execution
  • queue-backed project workers
  • multi-tenant project isolation
  • project-level authentication or authorization
These capabilities can be layered around the project model as the BindAI ecosystem evolves.

Current v0.1 Role

For BindAI v0.1, Project should be viewed as the top-level Python composition container for related applications and shared workflow resources. The project model is useful for:
  • organizing multiple applications
  • registering shared tools
  • grouping workflows
  • managing workflow schedules
  • providing project identity and configuration
  • exposing a clean root object for application execution
  • integrating projects with the BindAI REST API
More advanced project management capabilities can be added later without changing the basic role of the project as the root container.