autobyteus 1.2.1__tar.gz → 1.3.0__tar.gz

autobyteus-1.3.0/PKG-INFO

@@ -0,0 +1,293 @@
+Metadata-Version: 2.4
+Name: autobyteus
+Version: 1.3.0
+Summary: Multi-Agent framework
+Author-email: Ryan Zheng <ryan.zheng.work@gmail.com>
+License: MIT License with Additional Terms for Commercial Use
+        
+        Permission is hereby granted, free of charge, to any person or organization obtaining a copy of this software and associated documentation files (the "Software"), to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, subject to the following conditions:
+        
+        1. Commercial Use: The use of the Software for commercial purposes requires the payment of a licensing fee. For details regarding licensing and fees, please contact ryan.zheng at ryan.zheng.work@gmail.com.
+        
+        2. Redistributions: Redistributions of the Software in source code or other forms must include the above copyright notice, this list of conditions, and the following disclaimer.
+        
+        3. Patent Grant: The provisions of the Apache 2.0 License regarding patent grants apply to this License.
+        
+        4. No Warranty/Liability: The Software is provided "as is," without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and non-infringement. In no event shall the authors or copyright holders be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Software or the use or other dealings in the Software.
+        
+        AutoByteus
+        17.07.2023
+        
+Project-URL: Homepage, https://github.com/AutoByteus/autobyteus
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3.11
+Requires-Python: <3.12,>=3.11
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: aiohttp
+Requires-Dist: anthropic
+Requires-Dist: beautifulsoup4
+Requires-Dist: boto3
+Requires-Dist: botocore
+Requires-Dist: certifi==2025.4.26
+Requires-Dist: cryptography
+Requires-Dist: google-api-python-client
+Requires-Dist: google-genai
+Requires-Dist: httpx
+Requires-Dist: Jinja2
+Requires-Dist: mcp[cli]
+Requires-Dist: mistral_common
+Requires-Dist: mistralai==1.9.9
+Requires-Dist: numpy
+Requires-Dist: ollama
+Requires-Dist: openai
+Requires-Dist: requests
+Requires-Dist: websockets>=12.0
+Requires-Dist: rich
+Requires-Dist: textual
+Requires-Dist: tiktoken
+Requires-Dist: tokenizers
+Provides-Extra: dev
+Requires-Dist: build; extra == "dev"
+Requires-Dist: coverage; extra == "dev"
+Requires-Dist: flake8; extra == "dev"
+Requires-Dist: numpy; extra == "dev"
+Requires-Dist: pre-commit; extra == "dev"
+Requires-Dist: black; extra == "dev"
+Requires-Dist: isort; extra == "dev"
+Requires-Dist: gitpython==3.1.31; extra == "dev"
+Requires-Dist: auto-gpt-plugin-template; extra == "dev"
+Requires-Dist: mkdocs; extra == "dev"
+Requires-Dist: pytest; extra == "dev"
+Requires-Dist: asynctest; extra == "dev"
+Requires-Dist: pytest-asyncio; extra == "dev"
+Requires-Dist: pytest-benchmark; extra == "dev"
+Requires-Dist: pytest-cov; extra == "dev"
+Requires-Dist: pytest-integration; extra == "dev"
+Requires-Dist: pytest-mock; extra == "dev"
+Requires-Dist: vcrpy; extra == "dev"
+Requires-Dist: pytest-vcr; extra == "dev"
+Requires-Dist: load_dotenv; extra == "dev"
+Dynamic: license-file
+
+# Autobyteus
+
+Autobyteus is an open-source, application-first agentic framework for Python. It is designed to help developers build, test, and deploy complex, stateful, and extensible AI agents by providing a robust architecture and a powerful set of tools.
+
+![Autobyteus TUI Dashboard](docs/images/image_1.png)
+
+## Architecture
+
+Autobyteus is built with a modular, event-driven architecture designed for extensibility and clear separation of concerns. The key components are:
+
+- **Agent Core**: The heart of the system. Each agent is a stateful, autonomous entity that runs as a background process in its own thread, managed by a dedicated `AgentWorker`. This design makes every agent a truly independent entity capable of handling long-running tasks.
+- **Agent Teams**: ([Design Doc](docs/agent_team_design.md)) The framework provides powerful constructs for building hierarchical multi-agent systems. The `AgentTeam` module allows you to compose teams of individual agents and even nest teams within other teams, enabling sophisticated, real-world organizational structures and delegation patterns.
+- **Context & Configuration**: Agent behavior is defined through a static configuration (`AgentConfig`) and its dynamic state is managed in `AgentRuntimeState`. These are bundled into a comprehensive `AgentContext` that is passed to all components, providing a single source of truth.
+- **Event-Driven System**: ([Design Doc](docs/event_driven_core_design.md)) Agents operate on an internal `asyncio` event loop. User messages, tool results, and internal signals are handled as events, which are processed by dedicated `EventHandlers`. This decouples logic and makes the system highly extensible.
+- **Pluggable Processors & Hooks**: The framework provides a chain of extension points to inject custom logic at every major step of an agent's reasoning loop. This architecture powers features like flexible tool format parsing. You can customize behavior by implementing:
+  - **`InputProcessors`**: To modify or enrich user messages _before_ they are sent to the LLM.
+  - **`LLMResponseProcessors`**: To parse the LLM's raw output and extract structured actions, such as tool calls.
+  - **`ToolExecutionResultProcessors` (Tool Result Processors)**: To modify the result from a tool _before_ it is sent back to the LLM for the next step of reasoning (e.g., formatting, summarization, artifact extraction).
+  - **Lifecycle Event Processors**: To run custom code on specific lifecycle events (e.g., `BEFORE_LLM_CALL`, `AFTER_TOOL_EXECUTE`).
+- **Context-Aware Tooling**: Tools are first-class citizens that receive the agent's full `AgentContext` during execution. This allows tools to be deeply integrated with the agent's state, configuration, and workspace, enabling more intelligent and powerful actions.
+- **Tool Approval Flow**: The framework has native support for human-in-the-loop workflows. By setting `auto_execute_tools=False` in the agent's configuration, the agent will pause before executing a tool, emit an event requesting permission, and wait for external approval before proceeding.
+- **MCP Integration**: The framework has native support for the Model Context Protocol (MCP). This allows agents to discover and use tools from external, language-agnostic tool servers, making the ecosystem extremely flexible and ready for enterprise integration.
+- **Agent Skills**: ([Design Doc](docs/skills_design.md)) A powerful mechanism for extending agent capabilities using modular, file-based skills. Each skill is a directory containing a map (`SKILL.md`) and arbitrary assets (code, docs, templates). Skills can be preloaded or dynamically fetched via the `load_skill` tool, enabling human-like, just-in-time retrieval without bloating the context window.
+
+## Key Features
+
+#### Interactive TUI Dashboard
+
+Launch and monitor your agent teams with our built-in Textual-based TUI.
+
+- **Hierarchical View**: See the structure of your team, including sub-teams and their agents.
+- **Real-Time Status**: Agent and team statuses are updated live, showing you who is idle, thinking, or executing a tool.
+- **Detailed Logs**: Select any agent to view a detailed, streaming log of their thoughts, actions, and tool interactions.
+- **Live Task Plan**: Watch your team's `TaskPlan` update in real-time as the coordinator publishes a plan and agents complete their tasks.
+
+|             TUI - Detailed Agent Log             |       TUI - Task Plan with Completed Task        |
+| :----------------------------------------------: | :----------------------------------------------: |
+| ![Autobyteus Agent Log](docs/images/image_4.png) | ![Autobyteus Task Plan](docs/images/image_3.png) |
+
+#### Fluent Team Building
+
+Define complex agent and team structures with an intuitive, fluent API. The `AgentTeamBuilder` makes composing your team simple and readable.
+
+```python
+# --- From the Multi-Researcher Team Example ---
+research_team = (
+    AgentTeamBuilder(
+        name="MultiSpecialistResearchTeam",
+        description="A team for delegating to multiple specialists."
+    )
+    .set_coordinator(coordinator_config)
+    .add_agent_node(researcher_web_config)
+    .add_agent_node(researcher_db_config)
+    .build()
+)
+```
+
+#### Flexible Tool Formatting (JSON & XML)
+
+Autobyteus intelligently handles tool communication with LLMs while giving you full control.
+
+- **Provider-Aware by Default**: The framework automatically generates tool manifests in the optimal format for the selected LLM provider (e.g., JSON for OpenAI/Gemini, XML for Anthropic).
+- **Format Override via Env**: Set `AUTOBYTEUS_STREAM_PARSER=xml` (or `json`) to force tool-call formatting to that format regardless of provider. This can be useful for consistency or for large, complex schemas.
+
+#### Flexible Communication Protocols
+
+Choose the collaboration pattern that best fits your use case with configurable `TaskNotificationMode`s.
+
+- **Env Override**: Set `AUTOBYTEUS_TASK_NOTIFICATION_MODE=system_event_driven` (or `agent_manual_notification`) to pick the default for all teams.
+- **`AGENT_MANUAL_NOTIFICATION` (Default)**: A traditional approach where a coordinator agent is responsible for creating a plan and then explicitly notifying other agents to begin their work via messages.
+- **`SYSTEM_EVENT_DRIVEN`**: A more automated approach where the coordinator's only job is to publish a plan to the `TaskPlan`. The framework then monitors the board and automatically notifies agents when their tasks become unblocked, enabling parallel execution and reducing coordinator overhead.
+
+## Requirements
+
+- **Python Version**: Python 3.11.x is the supported version for this project (>=3.11,<3.12). Using other versions may cause dependency conflicts.
+- **Platform Support**:
+  - **Linux/macOS**: Full support for all tools.
+  - **Windows**: Supported via **WSL (Windows Subsystem for Linux)**.
+    - **WSL Required**: Terminal tools (`run_bash`, etc.) require WSL installed (`wsl --install`) and an active Linux distribution.
+    - **Default Distro**: If you have multiple WSL distros, set Ubuntu as the default to avoid Docker's minimal distro:
+      - `wsl -l -v`
+      - `wsl --set-default Ubuntu`
+    - **Dependency**: `tmux` is required inside WSL for terminal integration on Windows.
+    - For detailed Windows setup, see the **[Terminal Tools Documentation](docs/terminal_tools.md#platform-support)**.
+
+## Getting Started
+
+### Installation
+
+1.  **Clone the repository:**
+
+    ```bash
+    git clone https://github.com/your-username/autobyteus.git
+    cd autobyteus
+    ```
+
+2.  **Create a local `uv` environment (recommended):**
+
+    ```bash
+    uv venv .venv --python 3.11
+    ```
+
+3.  **Install dependencies:**
+
+    - **For users:**
+      ```bash
+      uv sync
+      ```
+    - **For developers:**
+      ```bash
+      uv sync --extra dev
+      ```
+
+4.  **Set up Environment Variables:**
+    Create a `.env` file in the root of the project and add your LLM provider API keys:
+    ```
+    # .env
+    OPENAI_API_KEY="sk-..."
+    KIMI_API_KEY="your-kimi-api-key"
+    # etc.
+    ```
+
+### Running the Examples
+
+The best way to experience Autobyteus is to run one of the included examples. The event-driven software engineering team is a great showcase of the framework's capabilities.
+
+```bash
+# Run the event-driven software engineering team example
+python autobyteus/examples/agent_team/event_driven/run_software_engineering_team.py --llm-model gpt-4o
+
+# Run the hierarchical debate team example
+python autobyteus/examples/agent_team/manual_notification/run_debate_team.py --llm-model gpt-4-turbo
+
+# Run the hierarchical skills example (modular, file-based capabilities)
+python examples/run_agent_with_skill.py --llm-model gpt-4o
+```
+
+You can see all available models and their identifiers by running an example with the `--help-models` flag.
+
+## Testing
+
+### Streamable HTTP MCP integration
+
+Some integration tests rely on the toy streamable MCP server that lives in
+`autobyteus_mcps/streamable_http_mcp_toy`. Start it in a separate terminal
+before running the test, for example:
+
+```bash
+cd autobyteus_mcps/streamable_http_mcp_toy
+python src/streamable_http_mcp_toy/server.py --host 127.0.0.1 --port 8764
+```
+
+With the server running, execute the HTTP transport test:
+
+```bash
+uv run python -m pytest tests/integration_tests/tools/mcp/test_http_managed_server_integration.py
+```
+
+If you bind the server elsewhere, set `STREAMABLE_HTTP_MCP_URL` to the full
+`http://` or `https://` endpoint before running pytest so the test can find it.
+
+### Secure WebSocket (WSS) MCP integration
+
+The toy WebSocket MCP server lives in `autobyteus_mcps/wss_mcp_toy`. It exposes
+the same diagnostic tools as the HTTP toy server but requires TLS and an Origin
+header. To exercise the WebSocket transport:
+
+1. In a separate terminal start the toy server:
+
+   ```bash
+   cd autobyteus_mcps/wss_mcp_toy
+   python3 -m venv .venv
+   source .venv/bin/activate
+   pip install -e .
+   ./scripts/generate-dev-cert.sh  # creates certs/dev-cert.pem + certs/dev-key.pem
+   wss-mcp-toy --cert certs/dev-cert.pem --key certs/dev-key.pem --host 127.0.0.1 --port 8765 --allowed-origin https://localhost
+   ```
+
+2. Run the WebSocket transport test (defaults assume the process above is
+   listening on `wss://127.0.0.1:8765/mcp`):
+
+   ```bash
+   uv run python -m pytest tests/integration_tests/tools/mcp/test_websocket_managed_server_integration.py
+   ```
+
+Customize the target URL or TLS behavior via environment variables when
+running pytest:
+
+- `WSS_MCP_URL` – full `ws://` or `wss://` endpoint (default `wss://127.0.0.1:8765/mcp`).
+- `WSS_MCP_ORIGIN` – Origin header value (default `https://localhost`).
+- `WSS_MCP_VERIFY_TLS` – set to `true`/`1` to enforce TLS verification
+  (default `false` for the self-signed dev cert).
+- `WSS_MCP_CA_FILE`, `WSS_MCP_CLIENT_CERT`, `WSS_MCP_CLIENT_KEY` – optional
+  paths if you want to trust a custom CA or present a client certificate.
+
+### Building the Library
+
+To build Autobyteus as a distributable package, follow these steps:
+
+1.  Ensure dev dependencies are installed:
+
+    ```bash
+    uv sync --extra dev
+    ```
+
+2.  Build the distribution packages defined in `pyproject.toml`:
+    ```
+    uv run python -m build
+    ```
+
+This will create a `dist` directory containing the `sdist` and `wheel` artifacts.
+
+## Contributing
+
+(Add guidelines for contributing to the project)
+
+## License
+
+This project is licensed under the MIT License.

autobyteus-1.3.0/README.md

@@ -0,0 +1,219 @@
+# Autobyteus
+
+Autobyteus is an open-source, application-first agentic framework for Python. It is designed to help developers build, test, and deploy complex, stateful, and extensible AI agents by providing a robust architecture and a powerful set of tools.
+
+![Autobyteus TUI Dashboard](docs/images/image_1.png)
+
+## Architecture
+
+Autobyteus is built with a modular, event-driven architecture designed for extensibility and clear separation of concerns. The key components are:
+
+- **Agent Core**: The heart of the system. Each agent is a stateful, autonomous entity that runs as a background process in its own thread, managed by a dedicated `AgentWorker`. This design makes every agent a truly independent entity capable of handling long-running tasks.
+- **Agent Teams**: ([Design Doc](docs/agent_team_design.md)) The framework provides powerful constructs for building hierarchical multi-agent systems. The `AgentTeam` module allows you to compose teams of individual agents and even nest teams within other teams, enabling sophisticated, real-world organizational structures and delegation patterns.
+- **Context & Configuration**: Agent behavior is defined through a static configuration (`AgentConfig`) and its dynamic state is managed in `AgentRuntimeState`. These are bundled into a comprehensive `AgentContext` that is passed to all components, providing a single source of truth.
+- **Event-Driven System**: ([Design Doc](docs/event_driven_core_design.md)) Agents operate on an internal `asyncio` event loop. User messages, tool results, and internal signals are handled as events, which are processed by dedicated `EventHandlers`. This decouples logic and makes the system highly extensible.
+- **Pluggable Processors & Hooks**: The framework provides a chain of extension points to inject custom logic at every major step of an agent's reasoning loop. This architecture powers features like flexible tool format parsing. You can customize behavior by implementing:
+  - **`InputProcessors`**: To modify or enrich user messages _before_ they are sent to the LLM.
+  - **`LLMResponseProcessors`**: To parse the LLM's raw output and extract structured actions, such as tool calls.
+  - **`ToolExecutionResultProcessors` (Tool Result Processors)**: To modify the result from a tool _before_ it is sent back to the LLM for the next step of reasoning (e.g., formatting, summarization, artifact extraction).
+  - **Lifecycle Event Processors**: To run custom code on specific lifecycle events (e.g., `BEFORE_LLM_CALL`, `AFTER_TOOL_EXECUTE`).
+- **Context-Aware Tooling**: Tools are first-class citizens that receive the agent's full `AgentContext` during execution. This allows tools to be deeply integrated with the agent's state, configuration, and workspace, enabling more intelligent and powerful actions.
+- **Tool Approval Flow**: The framework has native support for human-in-the-loop workflows. By setting `auto_execute_tools=False` in the agent's configuration, the agent will pause before executing a tool, emit an event requesting permission, and wait for external approval before proceeding.
+- **MCP Integration**: The framework has native support for the Model Context Protocol (MCP). This allows agents to discover and use tools from external, language-agnostic tool servers, making the ecosystem extremely flexible and ready for enterprise integration.
+- **Agent Skills**: ([Design Doc](docs/skills_design.md)) A powerful mechanism for extending agent capabilities using modular, file-based skills. Each skill is a directory containing a map (`SKILL.md`) and arbitrary assets (code, docs, templates). Skills can be preloaded or dynamically fetched via the `load_skill` tool, enabling human-like, just-in-time retrieval without bloating the context window.
+
+## Key Features
+
+#### Interactive TUI Dashboard
+
+Launch and monitor your agent teams with our built-in Textual-based TUI.
+
+- **Hierarchical View**: See the structure of your team, including sub-teams and their agents.
+- **Real-Time Status**: Agent and team statuses are updated live, showing you who is idle, thinking, or executing a tool.
+- **Detailed Logs**: Select any agent to view a detailed, streaming log of their thoughts, actions, and tool interactions.
+- **Live Task Plan**: Watch your team's `TaskPlan` update in real-time as the coordinator publishes a plan and agents complete their tasks.
+
+|             TUI - Detailed Agent Log             |       TUI - Task Plan with Completed Task        |
+| :----------------------------------------------: | :----------------------------------------------: |
+| ![Autobyteus Agent Log](docs/images/image_4.png) | ![Autobyteus Task Plan](docs/images/image_3.png) |
+
+#### Fluent Team Building
+
+Define complex agent and team structures with an intuitive, fluent API. The `AgentTeamBuilder` makes composing your team simple and readable.
+
+```python
+# --- From the Multi-Researcher Team Example ---
+research_team = (
+    AgentTeamBuilder(
+        name="MultiSpecialistResearchTeam",
+        description="A team for delegating to multiple specialists."
+    )
+    .set_coordinator(coordinator_config)
+    .add_agent_node(researcher_web_config)
+    .add_agent_node(researcher_db_config)
+    .build()
+)
+```
+
+#### Flexible Tool Formatting (JSON & XML)
+
+Autobyteus intelligently handles tool communication with LLMs while giving you full control.
+
+- **Provider-Aware by Default**: The framework automatically generates tool manifests in the optimal format for the selected LLM provider (e.g., JSON for OpenAI/Gemini, XML for Anthropic).
+- **Format Override via Env**: Set `AUTOBYTEUS_STREAM_PARSER=xml` (or `json`) to force tool-call formatting to that format regardless of provider. This can be useful for consistency or for large, complex schemas.
+
+#### Flexible Communication Protocols
+
+Choose the collaboration pattern that best fits your use case with configurable `TaskNotificationMode`s.
+
+- **Env Override**: Set `AUTOBYTEUS_TASK_NOTIFICATION_MODE=system_event_driven` (or `agent_manual_notification`) to pick the default for all teams.
+- **`AGENT_MANUAL_NOTIFICATION` (Default)**: A traditional approach where a coordinator agent is responsible for creating a plan and then explicitly notifying other agents to begin their work via messages.
+- **`SYSTEM_EVENT_DRIVEN`**: A more automated approach where the coordinator's only job is to publish a plan to the `TaskPlan`. The framework then monitors the board and automatically notifies agents when their tasks become unblocked, enabling parallel execution and reducing coordinator overhead.
+
+## Requirements
+
+- **Python Version**: Python 3.11.x is the supported version for this project (>=3.11,<3.12). Using other versions may cause dependency conflicts.
+- **Platform Support**:
+  - **Linux/macOS**: Full support for all tools.
+  - **Windows**: Supported via **WSL (Windows Subsystem for Linux)**.
+    - **WSL Required**: Terminal tools (`run_bash`, etc.) require WSL installed (`wsl --install`) and an active Linux distribution.
+    - **Default Distro**: If you have multiple WSL distros, set Ubuntu as the default to avoid Docker's minimal distro:
+      - `wsl -l -v`
+      - `wsl --set-default Ubuntu`
+    - **Dependency**: `tmux` is required inside WSL for terminal integration on Windows.
+    - For detailed Windows setup, see the **[Terminal Tools Documentation](docs/terminal_tools.md#platform-support)**.
+
+## Getting Started
+
+### Installation
+
+1.  **Clone the repository:**
+
+    ```bash
+    git clone https://github.com/your-username/autobyteus.git
+    cd autobyteus
+    ```
+
+2.  **Create a local `uv` environment (recommended):**
+
+    ```bash
+    uv venv .venv --python 3.11
+    ```
+
+3.  **Install dependencies:**
+
+    - **For users:**
+      ```bash
+      uv sync
+      ```
+    - **For developers:**
+      ```bash
+      uv sync --extra dev
+      ```
+
+4.  **Set up Environment Variables:**
+    Create a `.env` file in the root of the project and add your LLM provider API keys:
+    ```
+    # .env
+    OPENAI_API_KEY="sk-..."
+    KIMI_API_KEY="your-kimi-api-key"
+    # etc.
+    ```
+
+### Running the Examples
+
+The best way to experience Autobyteus is to run one of the included examples. The event-driven software engineering team is a great showcase of the framework's capabilities.
+
+```bash
+# Run the event-driven software engineering team example
+python autobyteus/examples/agent_team/event_driven/run_software_engineering_team.py --llm-model gpt-4o
+
+# Run the hierarchical debate team example
+python autobyteus/examples/agent_team/manual_notification/run_debate_team.py --llm-model gpt-4-turbo
+
+# Run the hierarchical skills example (modular, file-based capabilities)
+python examples/run_agent_with_skill.py --llm-model gpt-4o
+```
+
+You can see all available models and their identifiers by running an example with the `--help-models` flag.
+
+## Testing
+
+### Streamable HTTP MCP integration
+
+Some integration tests rely on the toy streamable MCP server that lives in
+`autobyteus_mcps/streamable_http_mcp_toy`. Start it in a separate terminal
+before running the test, for example:
+
+```bash
+cd autobyteus_mcps/streamable_http_mcp_toy
+python src/streamable_http_mcp_toy/server.py --host 127.0.0.1 --port 8764
+```
+
+With the server running, execute the HTTP transport test:
+
+```bash
+uv run python -m pytest tests/integration_tests/tools/mcp/test_http_managed_server_integration.py
+```
+
+If you bind the server elsewhere, set `STREAMABLE_HTTP_MCP_URL` to the full
+`http://` or `https://` endpoint before running pytest so the test can find it.
+
+### Secure WebSocket (WSS) MCP integration
+
+The toy WebSocket MCP server lives in `autobyteus_mcps/wss_mcp_toy`. It exposes
+the same diagnostic tools as the HTTP toy server but requires TLS and an Origin
+header. To exercise the WebSocket transport:
+
+1. In a separate terminal start the toy server:
+
+   ```bash
+   cd autobyteus_mcps/wss_mcp_toy
+   python3 -m venv .venv
+   source .venv/bin/activate
+   pip install -e .
+   ./scripts/generate-dev-cert.sh  # creates certs/dev-cert.pem + certs/dev-key.pem
+   wss-mcp-toy --cert certs/dev-cert.pem --key certs/dev-key.pem --host 127.0.0.1 --port 8765 --allowed-origin https://localhost
+   ```
+
+2. Run the WebSocket transport test (defaults assume the process above is
+   listening on `wss://127.0.0.1:8765/mcp`):
+
+   ```bash
+   uv run python -m pytest tests/integration_tests/tools/mcp/test_websocket_managed_server_integration.py
+   ```
+
+Customize the target URL or TLS behavior via environment variables when
+running pytest:
+
+- `WSS_MCP_URL` – full `ws://` or `wss://` endpoint (default `wss://127.0.0.1:8765/mcp`).
+- `WSS_MCP_ORIGIN` – Origin header value (default `https://localhost`).
+- `WSS_MCP_VERIFY_TLS` – set to `true`/`1` to enforce TLS verification
+  (default `false` for the self-signed dev cert).
+- `WSS_MCP_CA_FILE`, `WSS_MCP_CLIENT_CERT`, `WSS_MCP_CLIENT_KEY` – optional
+  paths if you want to trust a custom CA or present a client certificate.
+
+### Building the Library
+
+To build Autobyteus as a distributable package, follow these steps:
+
+1.  Ensure dev dependencies are installed:
+
+    ```bash
+    uv sync --extra dev
+    ```
+
+2.  Build the distribution packages defined in `pyproject.toml`:
+    ```
+    uv run python -m build
+    ```
+
+This will create a `dist` directory containing the `sdist` and `wheel` artifacts.
+
+## Contributing
+
+(Add guidelines for contributing to the project)
+
+## License
+
+This project is licensed under the MIT License.

autobyteus-1.3.0/autobyteus/agent/agent.py

@@ -0,0 +1,116 @@
+# file: autobyteus/autobyteus/agent/agent.py
+import asyncio
+import logging
+from typing import AsyncIterator, Optional, List, Any, Dict, TYPE_CHECKING 
+
+from autobyteus.agent.runtime.agent_runtime import AgentRuntime
+from autobyteus.agent.status.status_enum import AgentStatus 
+from autobyteus.agent.message.agent_input_user_message import AgentInputUserMessage
+from autobyteus.agent.message.inter_agent_message import InterAgentMessage
+from autobyteus.agent.events import UserMessageReceivedEvent, InterAgentMessageReceivedEvent, ToolExecutionApprovalEvent, BaseEvent 
+
+if TYPE_CHECKING:
+    from autobyteus.agent.context import AgentContext 
+
+logger = logging.getLogger(__name__)
+
+class Agent:
+    """
+    User-facing API for interacting with an agent's runtime.
+    It manages an underlying AgentRuntime instance and translates user actions
+    into events for the agent's event processing loop by submitting them
+    to AgentRuntime. Output is consumed via AgentEventStream which listens
+    to AgentExternalEventNotifier.
+    """
+
+    def __init__(self, runtime: AgentRuntime):
+        if not isinstance(runtime, AgentRuntime): # pragma: no cover
+            raise TypeError(f"Agent requires an AgentRuntime instance, got {type(runtime).__name__}")
+        
+        self._runtime: AgentRuntime = runtime
+        self.agent_id: str = self._runtime.context.agent_id 
+        
+        logger.info(f"Agent facade initialized for agent_id '{self.agent_id}'.")
+
+    @property
+    def context(self) -> 'AgentContext': 
+        return self._runtime.context
+
+    async def _submit_event_to_runtime(self, event: BaseEvent) -> None:
+        """Internal helper to submit an event to the runtime and handle startup."""
+        if not self._runtime.is_running: # pragma: no cover
+            logger.info(f"Agent '{self.agent_id}' runtime is not running. Calling start() before submitting event.")
+            self.start() 
+            await asyncio.sleep(0.05) 
+        
+        logger.debug(f"Agent '{self.agent_id}': Submitting {type(event).__name__} to runtime.")
+        await self._runtime.submit_event(event)
+
+    async def post_user_message(self, agent_input_user_message: AgentInputUserMessage) -> None:
+        if not isinstance(agent_input_user_message, AgentInputUserMessage): # pragma: no cover
+            raise TypeError(f"Agent for '{self.agent_id}' received invalid type for user_message. Expected AgentInputUserMessage, got {type(agent_input_user_message)}.")
+        
+        event = UserMessageReceivedEvent(agent_input_user_message=agent_input_user_message)
+        await self._submit_event_to_runtime(event)
+
+
+    async def post_inter_agent_message(self, inter_agent_message: InterAgentMessage) -> None:
+        if not isinstance(inter_agent_message, InterAgentMessage): # pragma: no cover
+            raise TypeError(
+                f"Agent for '{self.agent_id}' received invalid type for inter_agent_message. "
+                f"Expected InterAgentMessage, got {type(inter_agent_message).__name__}."
+            )
+        
+        event = InterAgentMessageReceivedEvent(inter_agent_message=inter_agent_message)
+        await self._submit_event_to_runtime(event)
+
+
+    async def post_tool_execution_approval(self,
+                                         tool_invocation_id: str,
+                                         is_approved: bool,
+                                         reason: Optional[str] = None) -> None:
+        if not isinstance(tool_invocation_id, str) or not tool_invocation_id: # pragma: no cover
+             raise ValueError("tool_invocation_id must be a non-empty string.")
+        if not isinstance(is_approved, bool): # pragma: no cover
+            raise TypeError("is_approved must be a boolean.")
+
+        approval_event = ToolExecutionApprovalEvent(
+            tool_invocation_id=tool_invocation_id,
+            is_approved=is_approved,
+            reason=reason
+        )
+        await self._submit_event_to_runtime(approval_event)
+
+    def get_current_status(self) -> AgentStatus:
+        """
+        Returns the current status of the agent.
+
+        Returns:
+            AgentStatus: The current status of the agent.
+        """
+        # If the runtime hasn't started yet, we are uninitialized.
+        if not self._runtime:
+            return AgentStatus.UNINITIALIZED
+        
+        return self._runtime.current_status_property
+    
+    @property
+    def is_running(self) -> bool:
+        return self._runtime.is_running
+
+    def start(self) -> None: 
+        if self._runtime.is_running: # pragma: no cover
+            logger.info(f"Agent '{self.agent_id}' runtime is already running. Ignoring start command.")
+            return
+            
+        logger.info(f"Agent '{self.agent_id}' requesting runtime to start.")
+        self._runtime.start() 
+
+    async def stop(self, timeout: float = 10.0) -> None: # pragma: no cover
+        logger.info(f"Agent '{self.agent_id}' requesting runtime to stop (timeout: {timeout}s).")
+        await self._runtime.stop(timeout=timeout) 
+
+
+    def __repr__(self) -> str:
+        status_val = self._runtime.current_status_property.value 
+        return f"<Agent agent_id='{self.agent_id}', current_status='{status_val}'>"

autobyteus-1.3.0/autobyteus/agent/bootstrap_steps/__init__.py

@@ -0,0 +1,21 @@
+# file: autobyteus/autobyteus/agent/bootstrap_steps/__init__.py
+"""
+Defines individual, self-contained steps for the agent bootstrapping process.
+These steps are orchestrated by the BootstrapEventHandler.
+"""
+
+from .base_bootstrap_step import BaseBootstrapStep
+from .workspace_context_initialization_step import WorkspaceContextInitializationStep
+# ToolInitializationStep is no longer a bootstrap step.
+from .system_prompt_processing_step import SystemPromptProcessingStep
+from .mcp_server_prewarming_step import McpServerPrewarmingStep
+from .working_context_snapshot_restore_step import WorkingContextSnapshotRestoreStep
+# LLMConfigFinalizationStep and LLMInstanceCreationStep removed.
+
+__all__ = [
+    "BaseBootstrapStep",
+    "WorkspaceContextInitializationStep",
+    "SystemPromptProcessingStep",
+    "McpServerPrewarmingStep",
+    "WorkingContextSnapshotRestoreStep",
+]