Who this guide is for
AI researchers and developers who want to explore, reproduce, and extend experiments in Agent-Lab. If you write Python, use Jupyter, and think in terms of experiments, agents and pipelines, you'll feel at home. Familiarity with LLMs, RAG and container basics is helpful but not required.
Agent-Lab provides reusable components (agent types, tools, integrations) plus a collection of Jupyter notebooks with step-by-step examples, so you can get productive quickly.
Quickstart — run the examples
Requirements: Python 3.12+, a working Jupyter environment (JupyterLab or Notebook), and optionally local Docker for end-to-end integrations. Working in a clone of the repository:
uv sync --group notebooks # runtime + notebook dependencies in one virtualenv
jupyter lab # from the repository rootOpen notebooks/ and start with 01_…, progressing through the ones that interest
you.
Notes:
- Notebooks are mostly self-contained; each header states the required environment variables and external services (API keys, endpoints).
- The required keys live in
.env— copy.env.exampleand fill it in (see the Configuration reference). - To experiment against Agent-Lab from your own project instead of the repository,
pip install btech-agent-laband assemble the app withcreate_app()— see Extending the framework in the Developer's Guide.
Project layout — quick tour
notebooks/— interactive examples of agent types, evaluation and integrations. Start here.agent_lab/— the framework package:app_factory.py— the composition root:create_app().core/— configuration sources, DI container,extra_depsresolution.domain/— models, repository interfaces, exceptions (the Entity Domain Model).services/— business logic and theagent_types/implementations.interface/—api/(HTTP routers) andmcp/(the MCP server).infrastructure/— database, auth, metrics/tracing adapters.
tests/—unit/,integration/,template/andsimulation/suites (see Testing & Simulations).doc/— the documentation you are reading.
Understanding these layers tells you where behavior lives: examples in notebooks,
core contracts in core/ and domain/, and adapters in infrastructure/.
Notebooks — the primary learning path
Typical progression:
| Notebook | Demonstrates |
|---|---|
| 01_setup_embeddings_service.ipynb | Configure and validate your embeddings provider (start here) |
| 02_test_agent_type-adaptive_rag.ipynb | Adaptive RAG: retrieval grader, query rewriter, answer grader |
| 03_test_agent_type-react_rag.ipynb | ReAct pattern with retrieval and tool usage |
| 04_test_agent_type-vision_document.ipynb | Vision + document retrieval |
| 05_test_agent_type-multiagent-coder.ipynb | Multi-agent collaboration for code tasks |
| 06_test_agent_type-multiagent-researcher.ipynb | Multi-agent research workflows |
| 07_test_agent_type-multiagent-browser.ipynb | Web-browsing agents |
| 08_test_agent_type-multiagent-voice-assistant.ipynb | Voice agent (and variants 09/10: Azure Entra ID, fast) |
| 11_mcp_client-openai-responses.ipynb | Talking to the MCP server from the OpenAI Responses API |
Each notebook contains: a short description of the experiment objective, the required environment variables and secrets, helper functions, and printed/visual outputs to inspect agent decisions and metrics.
Pro tip: run notebooks in order for an incremental learning curve. Use smaller datasets and sample sizes while iterating to keep runs fast.
Core concepts
- Agent — a registered implementation under
agent_lab/services/agent_types/(@discoverable_agent). The registry resolves it lazily through the DI container, injecting declaredextra_deps. - Tools — discrete abilities an agent can call (search, browsing, TTS/ASR),
implemented as adapters in
agent_lab/infrastructure/oragent_lab/interface/. - Container — the DI composition object (
agent_lab/core/container.py); subclass it to add providers for your experiments. - Repositories — data-access interfaces in
agent_lab/domain/repositories/. - ConfigSource — where configuration comes from; use the YAML sources in experiments, Vault in production.
When you want to modify behavior, decide whether the change is: experimental
(notebook only), architectural (core/domain/services), or
integration-level (adapter in infrastructure). Favor small, testable changes —
and add or update a notebook to show the new behavior.
Running experiments and capturing results
Notebooks print intermediate steps; for more robust experiments:
Use deterministic seeds where randomness matters.
Capture the metrics relevant to your question — latency, token usage, tool-call counts, judge scores. The observability layer exports everything as OpenTelemetry (see Observability); the simulation harness logs judge scores to Langfuse/LangWatch (see Testing & Simulations).
For repeatable runs, export notebook cells to scripts and run them in CI or on compute nodes:
jupyter nbconvert --to script notebooks/02_test_agent_type-adaptive_rag.ipynbThe
docker/app/Dockerfilebuilds a pinned runtime image for reproducible execution.
Prototyping new behaviors
- Add a new agent type: create the class under
agent_lab/services/agent_types/, decorate it with@discoverable_agent("your_type"), and add a notebook that mounts it through the DI container and exercises it with a small scenario. The full walkthrough is in Building agentic workflows. - Swap an embeddings provider: implement a compatible adapter under
agent_lab/infrastructure/and validate it with notebook 01. - Add a retrieval store or vector DB: implement repository methods in
agent_lab/domain/repositories/and an adapter inagent_lab/infrastructure/database/; seed it with a small loader notebook and demonstrate retrieval in a query notebook.
Design tip: keep adapter interfaces narrow and test them in isolation with small unit tests.
Testing and evaluation
make test_unit # unit tests — no infrastructure needed
make test # unit + integration with coverage
make test_simulations # LLM-as-judge agent simulations (live LLMs)When you change core behavior, add a unit test and a short notebook demonstrating the change — that pairing is what makes research reproducible here. The full harness, judge configuration and evaluation platforms are covered in Testing & Simulations.
Reproducibility checklist
- Pin your environment (uv +
pyproject.toml/uv.lock). - Record seeds and config files (
config-dev.yml,config-test.yml). - Save the notebook checkpoint and any output artifacts (CSV/JSON) alongside your experiment.
- Note the tracing endpoints you exported to — traces are your experiment log.