agentbyte 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- agentbyte-0.1.0/.github/copilot-instructions.md +502 -0
- agentbyte-0.1.0/.gitignore +39 -0
- agentbyte-0.1.0/.gitlab-ci.yml +63 -0
- agentbyte-0.1.0/.gitmodules +3 -0
- agentbyte-0.1.0/.python-version +1 -0
- agentbyte-0.1.0/PKG-INFO +312 -0
- agentbyte-0.1.0/README.md +299 -0
- agentbyte-0.1.0/docs/book-designing-multi-agent-system.md +9167 -0
- agentbyte-0.1.0/docs/study/topic_model_client.md +2452 -0
- agentbyte-0.1.0/docs/study/topic_tools.md +1625 -0
- agentbyte-0.1.0/examples/function-tool-example.py +259 -0
- agentbyte-0.1.0/examples/llm-client-dependency-injection.py +474 -0
- agentbyte-0.1.0/examples/message-types-example.py +234 -0
- agentbyte-0.1.0/examples/openai-client-example.py +456 -0
- agentbyte-0.1.0/examples/pico-agent-test.py +39 -0
- agentbyte-0.1.0/examples/round-robin.py +108 -0
- agentbyte-0.1.0/notebooks/01-Authentication-and-Identity-of-AI-clients.ipynb +430 -0
- agentbyte-0.1.0/notebooks/01-tools-example.ipynb +444 -0
- agentbyte-0.1.0/notebooks/02-azure-open-ai-client-wrapper.ipynb +311 -0
- agentbyte-0.1.0/notebooks/agent-knowledge-building.ipynb +144 -0
- agentbyte-0.1.0/notebooks/pico-init-agent-test.ipynb +135 -0
- agentbyte-0.1.0/pyproject.toml +36 -0
- agentbyte-0.1.0/src/agentbyte/__about__.py +2 -0
- agentbyte-0.1.0/src/agentbyte/__init__.py +18 -0
- agentbyte-0.1.0/src/agentbyte/llm/__init__.py +94 -0
- agentbyte-0.1.0/src/agentbyte/llm/auth.py +184 -0
- agentbyte-0.1.0/src/agentbyte/llm/azure_openai.py +794 -0
- agentbyte-0.1.0/src/agentbyte/llm/base.py +590 -0
- agentbyte-0.1.0/src/agentbyte/llm/openai.py +782 -0
- agentbyte-0.1.0/src/agentbyte/llm/types.py +131 -0
- agentbyte-0.1.0/src/agentbyte/messages.py +416 -0
- agentbyte-0.1.0/src/agentbyte/settings/__init__.py +1 -0
- agentbyte-0.1.0/src/agentbyte/settings/core.py +123 -0
- agentbyte-0.1.0/src/agentbyte/tools/__init__.py +76 -0
- agentbyte-0.1.0/src/agentbyte/tools/base.py +583 -0
- agentbyte-0.1.0/src/agentbyte/tools/core_tools.py +523 -0
- agentbyte-0.1.0/src/agentbyte/tools/decorator.py +80 -0
- agentbyte-0.1.0/src/agentbyte/types.py +65 -0
- agentbyte-0.1.0/tests/test_llm_types.py +447 -0
- agentbyte-0.1.0/tests/test_tools.py +540 -0
- agentbyte-0.1.0/uv.lock +1409 -0
|
@@ -0,0 +1,502 @@
|
|
|
1
|
+
# Agentbyte Codebase Guide for AI Agents
|
|
2
|
+
|
|
3
|
+
## Project Overview
|
|
4
|
+
**Agentbyte** is an **enterprise-ready** Python toolkit for designing scalable, production-grade multiagent systems. This project serves a dual purpose:
|
|
5
|
+
|
|
6
|
+
1. **Learning Journey:** Master advanced AI engineering concepts by studying [picoagents](../external_lib/designing-multiagent-systems/picoagents/) architecture, patterns, and design decisions
|
|
7
|
+
2. **Knowledge Application:** Build Agentbyte step-by-step based on personal knowledge and preferences, deepening expertise in multiagent systems
|
|
8
|
+
3. **Enterprise Library:** Create a production-ready library with multi-framework and multi-LLM support
|
|
9
|
+
4. **Cross-Framework Compatibility:** Enable seamless composition of agents from Agentbyte, [Microsoft Agent Framework](https://github.com/microsoft/agent-framework), and [Pydantic AI](https://ai.pydantic.dev/)
|
|
10
|
+
|
|
11
|
+
The development approach is iterative and intentional: understand a pattern from picoagents → implement it in Agentbyte with custom enhancements → validate with examples → move to next pattern. This methodology builds both library quality and deep AI engineering expertise.
|
|
12
|
+
|
|
13
|
+
## Learning & Implementation Goal
|
|
14
|
+
|
|
15
|
+
We will work **chapter-by-chapter** starting from **Chapter 4** in [docs/chapters](../docs/chapters/), studying each chapter, then **implementing the concepts ourselves** in Agentbyte. Chapters may be **skipped when not relevant** to the current implementation phase. Each chapter follows a **learn → implement → validate** loop, with examples used only as references (no direct copying). We will skip certain chapters and comeback to them later when relevant to the current implementation phase. The focus is on **deep understanding** and **intentional design**, not just code replication.
|
|
16
|
+
|
|
17
|
+
- Study plan should be created for chapters in [study](../docs/study/)
|
|
18
|
+
- When implementing tools (Chapter 4.6.4), follow the step-by-step guide in [docs/study/topic_tools.md](../docs/study/topic_tools.md). Use its file creation steps, class responsibilities, and parity checklist as the execution plan.
|
|
19
|
+
|
|
20
|
+
**Core Stack:**
|
|
21
|
+
- Python 3.13+
|
|
22
|
+
- [picoagents](../external_lib/designing-multiagent-systems/picoagents/) >= 0.2.3 (reference framework for learning agent orchestration patterns)
|
|
23
|
+
- [picoagents](../external_lib/designing-multiagent-systems/examples/) Example References mentioned in the book
|
|
24
|
+
- [pydantic](https://docs.pydantic.dev/) for data validation and settings management
|
|
25
|
+
- **LLM Providers:**
|
|
26
|
+
- OpenAI API (GPT-4.1, GPT-5.1 series models)
|
|
27
|
+
- AWS Bedrock (future integration)
|
|
28
|
+
- **Frameworks:**
|
|
29
|
+
- Pydantic AI (integration in progress)
|
|
30
|
+
- Microsoft Agent Framework (integration in progress)
|
|
31
|
+
|
|
32
|
+
## Supporting Books & Resources
|
|
33
|
+
- ** Books Reference Chapters: [Designing Multiagent Systems with LLMs](../docs/chapters/)
|
|
34
|
+
|
|
35
|
+
## Architecture
|
|
36
|
+
|
|
37
|
+
### Directory Structure & Naming Conventions
|
|
38
|
+
|
|
39
|
+
**Core Principle**: Agentbyte mirrors the [picoagents structure](../external_lib/designing-multiagent-systems/picoagents/src/picoagents/) to maintain consistency and reduce cognitive load when switching between frameworks.
|
|
40
|
+
|
|
41
|
+
**Picoagents Reference Structure**:
|
|
42
|
+
```
|
|
43
|
+
picoagents/
|
|
44
|
+
messages.py # Public: Message types (core types for all agents)
|
|
45
|
+
types.py # Public: Framework types (Usage, ChatCompletionResult, etc.)
|
|
46
|
+
context.py # Public: Agent context and state
|
|
47
|
+
_base.py # Private: Base classes for framework internals
|
|
48
|
+
_component_config.py # Private: Internal component configuration
|
|
49
|
+
agents/
|
|
50
|
+
_base.py # Private: Abstract base classes
|
|
51
|
+
_agent.py # Implementation (could be public or private)
|
|
52
|
+
llm/
|
|
53
|
+
_base.py # Private: Abstract base for LLM clients
|
|
54
|
+
_openai.py # Implementation (could be public or private)
|
|
55
|
+
_azure_openai.py # Implementation (could be public or private)
|
|
56
|
+
tools/
|
|
57
|
+
_base.py # Private: Abstract base for tools
|
|
58
|
+
_core_tools.py # Implementation
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
**Agentbyte Implementation Rules**:
|
|
62
|
+
|
|
63
|
+
1. **Mirror the Package Structure**: Create same folder layout as picoagents (agents/, llm/, tools/, memory/, orchestration/, etc.)
|
|
64
|
+
|
|
65
|
+
2. **Naming Convention for Files**:
|
|
66
|
+
- **Public modules** (no underscore): Used when you want to expose the module/class in `__init__.py`
|
|
67
|
+
- Example: `llm/openai.py` → exported as `from agentbyte.llm import OpenAIChatCompletionClient`
|
|
68
|
+
- **Private modules** (with underscore): Use `_` prefix ONLY when:
|
|
69
|
+
- Module is internal/base only (e.g., `_base.py` for abstract classes)
|
|
70
|
+
- Module should NEVER be imported directly by users
|
|
71
|
+
- Module is implementation detail not part of public API
|
|
72
|
+
- **Decision**: If a module's class is exported in `__init__.py`, it should NOT have underscore
|
|
73
|
+
|
|
74
|
+
3. **Location Rule for Core Types**:
|
|
75
|
+
- **Top-level modules** (directly under agentbyte/):
|
|
76
|
+
- `messages.py` - Message types (SystemMessage, UserMessage, AssistantMessage, ToolMessage)
|
|
77
|
+
- `types.py` - Framework types (ToolResult, and other root-level types)
|
|
78
|
+
- `context.py` - Agent context (when implemented)
|
|
79
|
+
- **Package-specific types** (in subpackage):
|
|
80
|
+
- `llm/types.py` - LLM-specific types (ChatCompletionResult, ChatCompletionChunk, Usage)
|
|
81
|
+
- `tools/types.py` - Tool-specific types (if needed)
|
|
82
|
+
- `agents/types.py` - Agent-specific types (if needed)
|
|
83
|
+
|
|
84
|
+
4. **Class Naming & Organization**:
|
|
85
|
+
- Follow picoagents class hierarchy
|
|
86
|
+
- Use picoagents field names and structures for message types
|
|
87
|
+
- Document when custom enhancements differ from picoagents
|
|
88
|
+
|
|
89
|
+
** Picoagents is the reference architecture, but Agentbyte is not a copy—it's an implementation based on understanding picoagents patterns, with intentional design decisions for enterprise readiness and cross-framework compatibility. But should follow same module structure and naming conventions for consistency and ease of learning. Also picoagent use unnecessary _ to make a module private when it should be public and part of the API. Agentbyte should avoid this and only use _ for actual private/internal modules that are not part of the public API.
|
|
90
|
+
|
|
91
|
+
Picoagents Structure: `tree external_lib/designing-multiagent-systems/picoagents/src/picoagents`
|
|
92
|
+
```
|
|
93
|
+
external_lib/designing-multiagent-systems/picoagents/src/picoagents
|
|
94
|
+
├── __init__.py
|
|
95
|
+
├── _cancellation_token.py
|
|
96
|
+
├── _component_config.py
|
|
97
|
+
├── _middleware.py
|
|
98
|
+
├── _otel.py
|
|
99
|
+
├── agents
|
|
100
|
+
│ ├── __init__.py
|
|
101
|
+
│ ├── _agent.py
|
|
102
|
+
│ ├── _agent_as_tool.py
|
|
103
|
+
│ ├── _base.py
|
|
104
|
+
│ └── _computer_use
|
|
105
|
+
│ ├── __init__.py
|
|
106
|
+
│ ├── _computer_use.py
|
|
107
|
+
│ ├── _interface_clients.py
|
|
108
|
+
│ ├── _planning_models.py
|
|
109
|
+
│ └── _playwright_tools.py
|
|
110
|
+
├── cli
|
|
111
|
+
│ ├── __init__.py
|
|
112
|
+
│ └── _main.py
|
|
113
|
+
├── context.py
|
|
114
|
+
├── eval
|
|
115
|
+
│ ├── __init__.py
|
|
116
|
+
│ ├── _base.py
|
|
117
|
+
│ ├── _runner.py
|
|
118
|
+
│ ├── _targets.py
|
|
119
|
+
│ ├── examples
|
|
120
|
+
│ │ ├── __init__.py
|
|
121
|
+
│ │ └── basic_evaluation.py
|
|
122
|
+
│ └── judges
|
|
123
|
+
│ ├── __init__.py
|
|
124
|
+
│ ├── _base.py
|
|
125
|
+
│ ├── _composite.py
|
|
126
|
+
│ ├── _llm.py
|
|
127
|
+
│ └── _reference.py
|
|
128
|
+
├── llm
|
|
129
|
+
│ ├── __init__.py
|
|
130
|
+
│ ├── _anthropic.py
|
|
131
|
+
│ ├── _azure_openai.py
|
|
132
|
+
│ ├── _base.py
|
|
133
|
+
│ └── _openai.py
|
|
134
|
+
├── memory
|
|
135
|
+
│ ├── __init__.py
|
|
136
|
+
│ ├── _base.py
|
|
137
|
+
│ └── _chromadb.py
|
|
138
|
+
├── messages.py
|
|
139
|
+
├── orchestration
|
|
140
|
+
│ ├── __init__.py
|
|
141
|
+
│ ├── _ai.py
|
|
142
|
+
│ ├── _base.py
|
|
143
|
+
│ ├── _handoff.py
|
|
144
|
+
│ ├── _plan.py
|
|
145
|
+
│ └── _round_robin.py
|
|
146
|
+
├── termination
|
|
147
|
+
│ ├── __init__.py
|
|
148
|
+
│ ├── _base.py
|
|
149
|
+
│ ├── _cancellation.py
|
|
150
|
+
│ ├── _composite.py
|
|
151
|
+
│ ├── _external.py
|
|
152
|
+
│ ├── _function_call.py
|
|
153
|
+
│ ├── _handoff.py
|
|
154
|
+
│ ├── _max_message.py
|
|
155
|
+
│ ├── _text_mention.py
|
|
156
|
+
│ ├── _timeout.py
|
|
157
|
+
│ └── _token_usage.py
|
|
158
|
+
├── tools
|
|
159
|
+
│ ├── __init__.py
|
|
160
|
+
│ ├── _base.py
|
|
161
|
+
│ ├── _coding_tools.py
|
|
162
|
+
│ ├── _core_tools.py
|
|
163
|
+
│ ├── _decorator.py
|
|
164
|
+
│ ├── _mcp
|
|
165
|
+
│ │ ├── __init__.py
|
|
166
|
+
│ │ ├── _client.py
|
|
167
|
+
│ │ ├── _config.py
|
|
168
|
+
│ │ ├── _integration.py
|
|
169
|
+
│ │ ├── _tool.py
|
|
170
|
+
│ │ └── _transports.py
|
|
171
|
+
│ ├── _memory_tool.py
|
|
172
|
+
│ └── _research_tools.py
|
|
173
|
+
├── types.py
|
|
174
|
+
├── webui
|
|
175
|
+
│ ├── __init__.py
|
|
176
|
+
│ ├── _cli.py
|
|
177
|
+
│ ├── _discovery.py
|
|
178
|
+
│ ├── _execution.py
|
|
179
|
+
│ ├── _models.py
|
|
180
|
+
│ ├── _registry.py
|
|
181
|
+
│ ├── _server.py
|
|
182
|
+
│ ├── _session_store.py
|
|
183
|
+
│ ├── _sessions.py
|
|
184
|
+
│ ├── agent_framework_devui
|
|
185
|
+
│ │ └── ui
|
|
186
|
+
│ │ ├── assets
|
|
187
|
+
│ │ │ ├── index-BzhEszHZ.css
|
|
188
|
+
│ │ │ └── index-DByFJNGD.js
|
|
189
|
+
│ │ ├── index.html
|
|
190
|
+
│ │ └── vite.svg
|
|
191
|
+
│ ├── frontend
|
|
192
|
+
│ │ ├── README.md
|
|
193
|
+
│ │ ├── components.json
|
|
194
|
+
│ │ ├── eslint.config.js
|
|
195
|
+
│ │ ├── index.html
|
|
196
|
+
│ │ ├── package.json
|
|
197
|
+
│ │ ├── plan.md
|
|
198
|
+
│ │ ├── public
|
|
199
|
+
│ │ │ └── vite.svg
|
|
200
|
+
│ │ ├── src
|
|
201
|
+
│ │ │ ├── App.css
|
|
202
|
+
│ │ │ ├── App.tsx
|
|
203
|
+
│ │ │ ├── assets
|
|
204
|
+
│ │ │ │ └── react.svg
|
|
205
|
+
│ │ │ ├── components
|
|
206
|
+
│ │ │ │ ├── agent
|
|
207
|
+
│ │ │ │ │ └── agent-view.tsx
|
|
208
|
+
│ │ │ │ ├── message_renderer
|
|
209
|
+
│ │ │ │ │ ├── ContentRenderer.tsx
|
|
210
|
+
│ │ │ │ │ ├── MessageRenderer.tsx
|
|
211
|
+
│ │ │ │ │ ├── index.ts
|
|
212
|
+
│ │ │ │ │ └── types.ts
|
|
213
|
+
│ │ │ │ ├── mode-toggle.tsx
|
|
214
|
+
│ │ │ │ ├── orchestrator
|
|
215
|
+
│ │ │ │ │ └── orchestrator-view.tsx
|
|
216
|
+
│ │ │ │ ├── shared
|
|
217
|
+
│ │ │ │ │ ├── app-header.tsx
|
|
218
|
+
│ │ │ │ │ ├── chat-base.tsx
|
|
219
|
+
│ │ │ │ │ ├── context-inspector.tsx
|
|
220
|
+
│ │ │ │ │ ├── debug-panel.tsx
|
|
221
|
+
│ │ │ │ │ ├── entity-selector.tsx
|
|
222
|
+
│ │ │ │ │ ├── example-tasks-display.tsx
|
|
223
|
+
│ │ │ │ │ ├── examples-gallery.tsx
|
|
224
|
+
│ │ │ │ │ ├── session-switcher.tsx
|
|
225
|
+
│ │ │ │ │ └── tool-approval-banner.tsx
|
|
226
|
+
│ │ │ │ ├── theme-provider.tsx
|
|
227
|
+
│ │ │ │ ├── ui
|
|
228
|
+
│ │ │ │ │ ├── attachment-gallery.tsx
|
|
229
|
+
│ │ │ │ │ ├── badge.tsx
|
|
230
|
+
│ │ │ │ │ ├── button.tsx
|
|
231
|
+
│ │ │ │ │ ├── card.tsx
|
|
232
|
+
│ │ │ │ │ ├── dialog.tsx
|
|
233
|
+
│ │ │ │ │ ├── dropdown-menu.tsx
|
|
234
|
+
│ │ │ │ │ ├── file-upload.tsx
|
|
235
|
+
│ │ │ │ │ ├── input.tsx
|
|
236
|
+
│ │ │ │ │ ├── label.tsx
|
|
237
|
+
│ │ │ │ │ ├── loading-spinner.tsx
|
|
238
|
+
│ │ │ │ │ ├── loading-state.tsx
|
|
239
|
+
│ │ │ │ │ ├── message-input.tsx
|
|
240
|
+
│ │ │ │ │ ├── scroll-area.tsx
|
|
241
|
+
│ │ │ │ │ ├── slider.tsx
|
|
242
|
+
│ │ │ │ │ ├── tabs.tsx
|
|
243
|
+
│ │ │ │ │ └── textarea.tsx
|
|
244
|
+
│ │ │ │ └── workflow
|
|
245
|
+
│ │ │ │ └── workflow-view.tsx
|
|
246
|
+
│ │ │ ├── hooks
|
|
247
|
+
│ │ │ │ ├── messageHandlers.ts
|
|
248
|
+
│ │ │ │ └── useEntityExecution.ts
|
|
249
|
+
│ │ │ ├── index.css
|
|
250
|
+
│ │ │ ├── main.tsx
|
|
251
|
+
│ │ │ ├── services
|
|
252
|
+
│ │ │ │ └── api.ts
|
|
253
|
+
│ │ │ ├── types
|
|
254
|
+
│ │ │ │ ├── index.ts
|
|
255
|
+
│ │ │ │ └── picoagents.ts
|
|
256
|
+
│ │ │ ├── utils
|
|
257
|
+
│ │ │ │ └── message-utils.ts
|
|
258
|
+
│ │ │ └── vite-env.d.ts
|
|
259
|
+
│ │ ├── tsconfig.app.json
|
|
260
|
+
│ │ ├── tsconfig.json
|
|
261
|
+
│ │ ├── tsconfig.node.json
|
|
262
|
+
│ │ ├── vite.config.ts
|
|
263
|
+
│ │ └── yarn.lock
|
|
264
|
+
│ └── ui
|
|
265
|
+
│ ├── assets
|
|
266
|
+
│ │ ├── index-CWk64UM3.js
|
|
267
|
+
│ │ └── index-vt1cujlT.css
|
|
268
|
+
│ ├── index.html
|
|
269
|
+
│ └── vite.svg
|
|
270
|
+
└── workflow
|
|
271
|
+
├── __init__.py
|
|
272
|
+
├── core
|
|
273
|
+
│ ├── __init__.py
|
|
274
|
+
│ ├── _checkpoint.py
|
|
275
|
+
│ ├── _models.py
|
|
276
|
+
│ ├── _runner.py
|
|
277
|
+
│ └── _workflow.py
|
|
278
|
+
├── defaults.py
|
|
279
|
+
├── schema_utils.py
|
|
280
|
+
└── steps
|
|
281
|
+
├── __init__.py
|
|
282
|
+
├── _echo.py
|
|
283
|
+
├── _function.py
|
|
284
|
+
├── _http.py
|
|
285
|
+
├── _step.py
|
|
286
|
+
├── _transform.py
|
|
287
|
+
└── picoagent.py
|
|
288
|
+
```
|
|
289
|
+
|
|
290
|
+
We should always stick on this folder structure and naming convention for consistency and ease of learning. The goal is to learn deeply and create a production-ready library, not just copy code.
|
|
291
|
+
|
|
292
|
+
**Current Agentbyte Structure** (should follow above):
|
|
293
|
+
```
|
|
294
|
+
src/agentbyte/
|
|
295
|
+
__init__.py
|
|
296
|
+
messages.py # ✅ Message types (Message, SystemMessage, UserMessage, AssistantMessage, ToolMessage)
|
|
297
|
+
types.py # ✅ Core framework types (ToolResult, etc.)
|
|
298
|
+
llm/
|
|
299
|
+
__init__.py
|
|
300
|
+
base.py # Implementation of BaseChatCompletionClient
|
|
301
|
+
openai.py # OpenAIChatCompletionClient implementation
|
|
302
|
+
azure_openai.py # AzureOpenAIChatCompletionClient implementation
|
|
303
|
+
auth.py # Authentication utilities (agentbyte-specific)
|
|
304
|
+
types.py # LLM types (ChatCompletionResult, ChatCompletionChunk, Usage)
|
|
305
|
+
agents/ # (Not yet implemented)
|
|
306
|
+
tools/ # (Not yet implemented)
|
|
307
|
+
settings/
|
|
308
|
+
orchestration/ # (Not yet implemented)
|
|
309
|
+
```
|
|
310
|
+
|
|
311
|
+
**Key Difference from Picoagents**: Agentbyte does NOT use underscore prefix for base classes (base.py instead of _base.py, openai.py instead of _openai.py) since they ARE part of the public API and are exported in __init__.py.
|
|
312
|
+
|
|
313
|
+
---
|
|
314
|
+
|
|
315
|
+
## Types Organization Strategy
|
|
316
|
+
|
|
317
|
+
### ⚠️ Important: Avoid Picoagents' Monolithic Types Antipattern
|
|
318
|
+
|
|
319
|
+
**Problem with picoagents**: All types (504 lines) packed into single `types.py` module causes:
|
|
320
|
+
1. **Forward reference cascades**: Requires `model_rebuild()` calls at module end
|
|
321
|
+
2. **Circular import temptation**: Forces `if TYPE_CHECKING` imports
|
|
322
|
+
3. **Poor separation of concerns**: Everything mixed together (Usage, ToolResult, ChatCompletionResult, AgentResponse, 14 Event types, Evaluation types, etc.)
|
|
323
|
+
4. **Maintenance burden**: Hard to find and modify specific types
|
|
324
|
+
5. **Import overhead**: Importing one type pulls in entire 504-line module
|
|
325
|
+
|
|
326
|
+
**Agentbyte Solution**: Distribute types by module/domain—cleaner, fewer hacks needed.
|
|
327
|
+
|
|
328
|
+
### Type Placement Rules
|
|
329
|
+
|
|
330
|
+
**Root-level `types.py`** (fundamental framework types used everywhere):
|
|
331
|
+
- `ToolResult` - Used by tools module and potentially orchestration
|
|
332
|
+
- Future: `AgentResponse` scope TBD when agents module implemented
|
|
333
|
+
- Future: Global response enums/constants if any
|
|
334
|
+
- **Principle**: Only types that truly belong at framework root level
|
|
335
|
+
|
|
336
|
+
**`messages.py`** (at root level):
|
|
337
|
+
- All message types (SystemMessage, UserMessage, AssistantMessage, ToolMessage, MultiModalMessage, ToolCallRequest)
|
|
338
|
+
- **Usage** (moved here in Phase 1) ← Key decision to avoid forward references
|
|
339
|
+
- **Rationale**: Usage is message-adjacent metadata, not a separate domain type
|
|
340
|
+
- **Benefit**: Eliminates `model_rebuild()` calls and TYPE_CHECKING imports
|
|
341
|
+
|
|
342
|
+
**`llm/types.py`** (LLM-specific types):
|
|
343
|
+
- `ChatCompletionResult` - LLM API response
|
|
344
|
+
- `ChatCompletionChunk` - Streaming chunk
|
|
345
|
+
- `ModelClientError` - LLM error exception
|
|
346
|
+
- **Principle**: Only types specific to LLM request/response protocol
|
|
347
|
+
|
|
348
|
+
**`tools/core_tools.py`** (when implemented, tool-specific logic):
|
|
349
|
+
- Tool implementations (ThinkTool, CalculatorTool, etc.)
|
|
350
|
+
- Tool factory functions
|
|
351
|
+
- No separate types module for tools unless needed
|
|
352
|
+
|
|
353
|
+
**Future Modules** (when implemented):
|
|
354
|
+
|
|
355
|
+
`agents/types.py` (if needed):
|
|
356
|
+
- `AgentResponse` (potentially—scope TBD)
|
|
357
|
+
- Agent-specific types (not core framework types)
|
|
358
|
+
|
|
359
|
+
`orchestration/types.py` (if needed):
|
|
360
|
+
- `OrchestrationResponse`
|
|
361
|
+
- `StopMessage`
|
|
362
|
+
- Orchestration-specific types
|
|
363
|
+
|
|
364
|
+
`events.py` (if stream events become significant):
|
|
365
|
+
- Event hierarchy (BaseEvent, TaskStartEvent, ToolCallEvent, etc.)
|
|
366
|
+
- Separate from core types due to size (14+ event types in picoagents)
|
|
367
|
+
|
|
368
|
+
`evaluation/types.py` (if needed):
|
|
369
|
+
- `EvalTask`, `EvalTrajectory`, `EvalScore`, `EvalResult`
|
|
370
|
+
- Only when evaluation framework is built
|
|
371
|
+
|
|
372
|
+
### Anti-Patterns to Avoid
|
|
373
|
+
|
|
374
|
+
❌ **Don't**: Put all types in `types.py` (picoagents antipattern)
|
|
375
|
+
- Creates forward reference chains
|
|
376
|
+
- Requires `model_rebuild()` patches
|
|
377
|
+
- Bloats single module with unrelated types
|
|
378
|
+
|
|
379
|
+
❌ **Don't**: Use `if TYPE_CHECKING` to hide circular imports
|
|
380
|
+
- Defeats purpose of static type checking
|
|
381
|
+
- Hides dependency issues that should be architectural problems
|
|
382
|
+
- Requires runtime model rebuilding as workaround
|
|
383
|
+
|
|
384
|
+
❌ **Don't**: Create `tools/types.py` for single `ToolResult`
|
|
385
|
+
- Too granular; root `types.py` is appropriate for framework fundamentals
|
|
386
|
+
- `ToolResult` is as fundamental as Message types
|
|
387
|
+
|
|
388
|
+
✅ **Do**: Co-locate types with the modules that primarily use them
|
|
389
|
+
- `messages.py` has Usage (message metadata)
|
|
390
|
+
- `llm/types.py` has LLM response types
|
|
391
|
+
- `tools/base.py` imports ToolResult from root (fundamental type)
|
|
392
|
+
|
|
393
|
+
✅ **Do**: Use module-specific types files only for significant type groups
|
|
394
|
+
- When a module has 3+ cohesive types
|
|
395
|
+
- When types are rarely imported outside that module
|
|
396
|
+
- When keeping them separate reduces circular dependencies
|
|
397
|
+
|
|
398
|
+
### Current Agentbyte Type Organization
|
|
399
|
+
|
|
400
|
+
```
|
|
401
|
+
src/agentbyte/
|
|
402
|
+
types.py # ✅ ToolResult (fundamental)
|
|
403
|
+
messages.py # ✅ Message types + Usage (no hacks needed!)
|
|
404
|
+
llm/
|
|
405
|
+
types.py # ✅ ChatCompletionResult, ChatCompletionChunk
|
|
406
|
+
tools/
|
|
407
|
+
base.py # ✅ Imports ToolResult from agentbyte.types
|
|
408
|
+
core_tools.py # ✅ Implementations of tools
|
|
409
|
+
# Future modules will follow same pattern
|
|
410
|
+
```
|
|
411
|
+
|
|
412
|
+
**Why this is better than picoagents**:
|
|
413
|
+
- No `model_rebuild()` calls anywhere
|
|
414
|
+
- No `if TYPE_CHECKING` conditional imports
|
|
415
|
+
- No forward reference strings ("Usage", "AssistantMessage")
|
|
416
|
+
- Direct imports throughout
|
|
417
|
+
- Clean separation by module concern
|
|
418
|
+
- Usage class logically placed with messages (its domain)
|
|
419
|
+
|
|
420
|
+
---
|
|
421
|
+
|
|
422
|
+
## Framework & Provider Compatibility Roadmap
|
|
423
|
+
|
|
424
|
+
### Current Phase: Foundation & OpenAI Integration
|
|
425
|
+
- Build core abstractions based on picoagents patterns
|
|
426
|
+
- Implement agentbyte abstractions for agent orchestration
|
|
427
|
+
- Full OpenAI GPT-4 and GPT-5 series model support
|
|
428
|
+
- Create reproducible examples and enterprise patterns
|
|
429
|
+
- Establish settings and configuration management for production deployments
|
|
430
|
+
|
|
431
|
+
### Phase 2: Pydantic AI Integration
|
|
432
|
+
- Integrate [Pydantic AI](https://ai.pydantic.dev/) for validation-heavy agent tasks
|
|
433
|
+
- Build adapters for transparent Pydantic AI agent composition
|
|
434
|
+
- Create examples showing specialized agent selection patterns
|
|
435
|
+
- Enable mixed Agentbyte + Pydantic AI deployments
|
|
436
|
+
- Reference: [https://ai.pydantic.dev/](https://ai.pydantic.dev/)
|
|
437
|
+
|
|
438
|
+
### Phase 3: Open Telemetry & Observability
|
|
439
|
+
- Integrate Open Telemetry for distributed tracing and monitoring
|
|
440
|
+
|
|
441
|
+
### Phase 4: Microsoft Agent Framework Integration
|
|
442
|
+
- Study [Microsoft Agent Framework](https://github.com/microsoft/agent-framework) agent model and orchestration patterns
|
|
443
|
+
- Create adapter layers for seamless interoperability
|
|
444
|
+
- Design shared abstractions for enterprise agent lifecycle management
|
|
445
|
+
- Enable mixed Agentbyte + Microsoft Agent Framework deployments
|
|
446
|
+
- Reference: [https://github.com/microsoft/agent-framework](https://github.com/microsoft/agent-framework)
|
|
447
|
+
|
|
448
|
+
|
|
449
|
+
### Phase 5: AWS Bedrock LLM Support
|
|
450
|
+
- Implement Bedrock client adapter for Claude, Llama, and other Bedrock models
|
|
451
|
+
- Build multi-LLM provider abstraction layer
|
|
452
|
+
- Create cost-optimization patterns (e.g., use cheaper models for simple tasks)
|
|
453
|
+
- Support cross-region and failover strategies
|
|
454
|
+
- Enable enterprises to avoid OpenAI lock-in
|
|
455
|
+
|
|
456
|
+
### Cross-Framework & Multi-LLM Composition Patterns
|
|
457
|
+
- **Design Goal:** Enterprise deployments mixing frameworks and LLM providers transparently
|
|
458
|
+
- **Approach:**
|
|
459
|
+
- Adapter interfaces normalize agent execution, tool invocation, and messaging
|
|
460
|
+
- Provider abstraction enables seamless LLM switching without code changes
|
|
461
|
+
- Orchestrators manage intelligent agent and provider selection
|
|
462
|
+
- **Enterprise Use Cases:**
|
|
463
|
+
- Use Pydantic AI for strict validation tasks + Agentbyte for orchestration
|
|
464
|
+
- Route tasks to specialized agents (e.g., Microsoft Agent Framework for Azure-native scenarios)
|
|
465
|
+
- Switch LLM providers based on cost, latency, or capability requirements
|
|
466
|
+
- Implement fallback chains: GPT-4 → Bedrock Claude → GPT-4-turbo
|
|
467
|
+
- **Implementation Pattern:** Adapters and orchestrators handle all framework/provider differences transparently
|
|
468
|
+
|
|
469
|
+
## What NOT to Do
|
|
470
|
+
|
|
471
|
+
- Don't copy code directly from picoagents—study it, understand it, then implement with your own understanding and enhancements
|
|
472
|
+
- Don't hard-code API keys or configuration—always use settings classes (enterprise requirement)
|
|
473
|
+
- Don't skip the learning phase to rush implementation—understanding patterns deeply is the goal
|
|
474
|
+
- Avoid notebook-only code; move reusable patterns into src/agentbyte/ (this is the actual library)
|
|
475
|
+
- Don't ignore cross-framework compatibility during design—keep Microsoft Agent Framework and Pydantic AI patterns in mind
|
|
476
|
+
|
|
477
|
+
|
|
478
|
+
## Conding Tips and Tricks
|
|
479
|
+
- When picking certain topics from certain sections of the book, first only focus on that section and not the whole chapter if not relevant to the current implementation phase
|
|
480
|
+
|
|
481
|
+
## Coding Rules:
|
|
482
|
+
- Try to create minimal tests with pytest and pytest async for testing any code. **AVOID heredoc blocks** (`uv run python3 << 'EOF'`) as they tend to hang/freeze in terminal output:
|
|
483
|
+
- ✅ Good: `uv run python3 -c "from agentbyte.llm import X; print(X)"`
|
|
484
|
+
- ✅ Good: `uv run pytest tests/test_file.py -v`
|
|
485
|
+
- ❌ Bad: Multi-line heredoc blocks get stuck in terminal display
|
|
486
|
+
- If complex testing needed, create a temporary test file instead
|
|
487
|
+
- Use settings classes for all configuration management, never hard-code values
|
|
488
|
+
- Our code is uv to have a packaged applciation which means we do not need to import from src but from agentbyte directly. For example, in our notebooks we should import from agentbyte like `from agentbyte.tools import FunctionTool` instead of `from src.agentbyte.tools import FunctionTool`
|
|
489
|
+
- Notebook already has a async main thread so do not use `asyncio.run()` in the notebooks, just call the async function directly like `await test_example1()`
|
|
490
|
+
- **Run ruff check after creating any code** to ensure code quality:
|
|
491
|
+
- Check for unused imports: `uv run ruff check <file_or_dir> --select F401`
|
|
492
|
+
- Run full checks: `uv run ruff check <file_or_dir>`
|
|
493
|
+
- Auto-fix fixable issues: `uv run ruff check <file_or_dir> --fix`
|
|
494
|
+
- This catches unused imports, style issues, and other code quality concerns early
|
|
495
|
+
## Success Criteria
|
|
496
|
+
|
|
497
|
+
✓ **Deep Understanding:** Can explain the "why" behind each pattern and design decision
|
|
498
|
+
✓ **Documented Code:** Each component has clear rationale for its design approach
|
|
499
|
+
✓ **Working Examples:** Practical demonstrations of each pattern from Agentbyte
|
|
500
|
+
✓ **Cross-Framework Ready:** Abstractions are designed to integrate with MS Agent Framework and Pydantic AI
|
|
501
|
+
✓ **Enterprise Quality:** Settings, error handling, and configuration management suitable for production
|
|
502
|
+
✓ **Iterative Growth:** Library grows step-by-step with learning, not all at once
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Python-generated files
|
|
2
|
+
__pycache__/
|
|
3
|
+
*.py[oc]
|
|
4
|
+
build/
|
|
5
|
+
dist/
|
|
6
|
+
wheels/
|
|
7
|
+
*.egg-info
|
|
8
|
+
|
|
9
|
+
# Virtual environments
|
|
10
|
+
.venv
|
|
11
|
+
.env
|
|
12
|
+
|
|
13
|
+
# IDE
|
|
14
|
+
.vscode/
|
|
15
|
+
.idea/
|
|
16
|
+
*.swp
|
|
17
|
+
*.swo
|
|
18
|
+
*~
|
|
19
|
+
|
|
20
|
+
# OS
|
|
21
|
+
.DS_Store
|
|
22
|
+
.DS_Store?
|
|
23
|
+
._*
|
|
24
|
+
.Spotlight-V100
|
|
25
|
+
.Trashes
|
|
26
|
+
ehthumbs.db
|
|
27
|
+
|
|
28
|
+
# Testing
|
|
29
|
+
.coverage
|
|
30
|
+
htmlcov/
|
|
31
|
+
.pytest_cache/
|
|
32
|
+
|
|
33
|
+
# Jupyter
|
|
34
|
+
.ipynb_checkpoints/
|
|
35
|
+
*.ipynb_checkpoints
|
|
36
|
+
.envs
|
|
37
|
+
|
|
38
|
+
docs/chapters/
|
|
39
|
+
data/Designing-Multi-Agent-Systems.pdf
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
stages:
|
|
2
|
+
- build
|
|
3
|
+
- test
|
|
4
|
+
- publish
|
|
5
|
+
|
|
6
|
+
variables:
|
|
7
|
+
PYTHON_VERSION: "3.12"
|
|
8
|
+
PIP_DISABLE_PIP_VERSION_CHECK: "1"
|
|
9
|
+
PIP_NO_CACHE_DIR: "1"
|
|
10
|
+
TWINE_NON_INTERACTIVE: "1"
|
|
11
|
+
|
|
12
|
+
.build_template:
|
|
13
|
+
image: python:${PYTHON_VERSION}
|
|
14
|
+
before_script:
|
|
15
|
+
- python -m pip install --upgrade pip
|
|
16
|
+
- python -m pip install uv
|
|
17
|
+
|
|
18
|
+
build_package:
|
|
19
|
+
stage: build
|
|
20
|
+
extends: .build_template
|
|
21
|
+
script:
|
|
22
|
+
- uv build
|
|
23
|
+
artifacts:
|
|
24
|
+
paths:
|
|
25
|
+
- dist/
|
|
26
|
+
rules:
|
|
27
|
+
- if: "$CI_COMMIT_TAG"
|
|
28
|
+
|
|
29
|
+
test_package:
|
|
30
|
+
stage: test
|
|
31
|
+
extends: .build_template
|
|
32
|
+
script:
|
|
33
|
+
- uv sync --all-groups
|
|
34
|
+
- uv run pytest
|
|
35
|
+
rules:
|
|
36
|
+
- if: "$CI_COMMIT_TAG"
|
|
37
|
+
|
|
38
|
+
publish_package:
|
|
39
|
+
stage: publish
|
|
40
|
+
extends: .build_template
|
|
41
|
+
needs:
|
|
42
|
+
- build_package
|
|
43
|
+
environment:
|
|
44
|
+
name: release
|
|
45
|
+
id_tokens:
|
|
46
|
+
PYPI_ID_TOKEN:
|
|
47
|
+
aud: pypi
|
|
48
|
+
before_script:
|
|
49
|
+
- apt-get update
|
|
50
|
+
- apt-get install -y curl
|
|
51
|
+
- python -m pip install --upgrade pip
|
|
52
|
+
- python -m pip install uv
|
|
53
|
+
script:
|
|
54
|
+
- test -d dist
|
|
55
|
+
- |
|
|
56
|
+
token_json=$(curl -s -X POST "https://pypi.org/_/oidc/mint-token" \
|
|
57
|
+
-H "Content-Type: application/json" \
|
|
58
|
+
-d "{\"token\":\"${PYPI_ID_TOKEN}\"}")
|
|
59
|
+
- |
|
|
60
|
+
PYPI_UPLOAD_TOKEN=$(echo "$token_json" | python -c "import sys,json; print(json.load(sys.stdin)['token'])")
|
|
61
|
+
- uv publish --token "$PYPI_UPLOAD_TOKEN"
|
|
62
|
+
rules:
|
|
63
|
+
- if: "$CI_COMMIT_TAG"
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
3.12
|