fetchai/innovation-lab-examples: What the 80+ Agent Examples Actually Contain

The gap this fills: runnable agent code instead of framework documentation

Most agent frameworks ship documentation that explains concepts and leaves the wiring to you. This repository takes the opposite approach. According to the README, every folder is a self-contained, runnable AI agent project with its own README, dependencies and environment template. The stated audience is four groups: beginners exploring autonomous agents and Fetch.ai for the first time, builders integrating LLMs, payments or Web3 into agent workflows, hackathon participants who need a working starter, and contributors who want to publish their own examples. That is a wide net, and it shapes the repo. A hackathon participant and a team evaluating payment flows need different things from the same code, which is why the index is split by category rather than by difficulty alone. The value proposition is narrow but real: you get a starting file that already imports uAgents, registers handlers and reads keys from the environment, so the first hour goes into your logic instead of into boilerplate. What you do not get is a library. Nothing here is installed as a dependency of your project; you copy or clone a folder and it becomes yours to maintain.

How the repository is organised, and why the index matters more than the code

The tree in the README groups examples into ten buckets: getting started, LLM integration, agent-to-agent, MCP, payments, RAG and knowledge, multi-agent systems, Web3, external integrations, and a contributors folder. Each bucket holds between one and eleven folders. The getting-started bucket names fetch-hackathon-quickstarter as the entry point, described as a hackathon-ready template with orchestrator plus worker agents built on Python and uAgents. The LLM bucket is the largest, spanning asi1-llm-example, dynamic-ui-on-asi1, anthropic-quickstart, gemini-quickstart, openai-agent-sdk, the Claude Agent SDK, google-genai-parallel-processing, langchain-agents, pydantic-agent and security-scanner-agent. The A2A bucket has four entries, MCP has one, and payments has four including two Stripe variants and a FET example. This layout is the most useful part of the repository. If you already know you need an agent that accepts Stripe payments, the index sends you to stripe-payment-agents or stripe-horoscope-agent without a search. If you are weighing A2A against MCP, the two buckets sit next to each other and you can read both. The cost of the layout is that there is no shared abstraction across folders. Two examples that both call an LLM may do so through different clients, different prompt structures and different error handling, because each was written to stand alone. Expect to read the code, not to import it.

Setup: one script, per-example virtualenvs, and keys you have to supply

The README gives a five-step manual path and a one-command alternative. The manual path is: clone the repository, cd into an example folder such as fetch-hackathon-quickstarter, create a virtual environment with python3 -m venv .venv and activate it, install with pip install -r requirements.txt, copy .env.example to .env and edit it, then run the agent, for example python agents/alice/agent.py. The automated path from the repository root is ./setup.sh fetch-hackathon-quickstarter, which takes the example name as its argument. Prerequisites are stated as Python 3.10 or newer, pip and git. The README is explicit that some examples require API keys, naming ASI:One, OpenAI and Stripe as examples, and directs you to each example's .env.example. That per-example .env.example is the file to read before you start, because it tells you which services the code will actually call. There is also Docker support at the repository root, in the form of a Dockerfile and a docker-compose.yml, with the README claiming you can run any example in a container. I have not run either the setup script or the Docker path, so I cannot describe how the container selects an example or whether the compose file mounts a single folder at a time. If you need that detail, read the Dockerfile before relying on it. The repository also carries a repo-wide ruff.toml as a lint baseline and a .github/scripts/run-example-tests.sh described as a per-example test runner, which suggests CI exercises examples individually rather than as a suite.

The mechanism: agents as long-running processes that exchange messages

The common thread across the uAgents examples is a process model rather than a library call. You write an agent, give it a name and a seed, register handlers for message types, and run it. The agent then listens for messages and replies. The fetch-hackathon-quickstarter folder makes this concrete by shipping an orchestrator plus worker agents, with the run command pointing at agents/alice/agent.py, so the folder contains more than one agent and they are meant to talk to each other. The A2A bucket extends the same idea across process or organisation boundaries: launch-your-a2a-agent and launch-your-a2a-research-team are about exposing an agent so another party can reach it, and a2a-uAgents-Integration is about bridging the two. The MCP bucket, mcp-agents, points the other direction, letting an agent consume external tools exposed over the Model Context Protocol. The payments bucket adds a settlement layer: fet-example uses the chain's own token, while the Stripe examples route through a conventional payment processor, and image-agent-payment-protocol ties payment to a specific service. Put together, the repository is a set of worked examples for one architecture: independent agents, message passing between them, external tools and payment rails attached at the edges. The LLM examples are the exception, since several of them are closer to single-process scripts that call a model and print a result. That difference is worth knowing before you pick a folder as a template for a long-running service.

Where the examples stop being a good fit

Three limitations are visible from the material alone. First, the repository is a collection, not a product. There are no releases retrieved for it, so there is no versioned artefact to pin against. If you copy an example into your project, you inherit its dependency list at whatever version it was written, and future changes upstream will not reach you. Second, API keys are a hard gate. The README names ASI:One, OpenAI and Stripe as services some examples require, and the phrase some examples require API keys means an unknown subset will not run at all without a paid account. For a beginner following the quickstart, the first example may be the one that needs a key. Third, the breadth cuts both ways. With categories spanning LangChain, CrewAI, AG2, Google ADK, Pydantic AI and several vendor SDKs, no single person can vouch for all of it, and the depth per folder is whatever the contributor wrote. An example that demonstrates a pattern in forty lines is not a template for a production service; it is a demonstration that the pattern works. If your requirement is a supported integration with a compatibility promise, this is the wrong artefact. If your requirement is to see how a specific combination is wired, it is the right one.

Alternatives, and the difference in approach

The closest comparison is the upstream uAgents repository itself. That project is the framework: you install it as a package, it has its own release cycle, and its documentation explains the primitives. This repository sits above it and shows those primitives applied to concrete tasks, which means it moves at the speed of examples rather than at the speed of the framework. The trade is explicit. With uAgents you get a versioned dependency and a changelog; with innovation-lab-examples you get a working configuration you can read end to end. A second comparison is a general-purpose agent framework such as LangChain or CrewAI, both of which appear in this repository as integrations. Those frameworks give you an abstraction layer over models and tools, and they are meant to be imported into your own codebase. The uAgents model here is different: an agent is a process with an address, and the interesting work happens in message handlers. The repository's langchain-agents and Crewai-agents folders exist precisely because people want both, and reading those two folders side by side is the fastest way to see where the abstractions meet. A third comparison is a vendor quickstart, such as the Anthropic or Gemini sample repositories. Those are narrower and typically maintained by the vendor against their current SDK. This repository is broader and community-fed, which is why it carries a contributors folder with its own README and CHANGELOG.

Maintenance, contribution and the licence question

The repository was last pushed in September 2026, so it is active. That said, the maintenance model is distributed across folders. The contributors directory has its own README and CHANGELOG, and the README invites pull requests, which means individual examples are maintained by whoever wrote them. The practical consequence is that freshness varies by folder, and the only reliable signal is the last commit touching the folder you care about. On process, the .github directory contains CI workflows, a pull request template, CODEOWNERS and a BRANCH_PROTECTION.md, plus a scripts/pr-ai-review.mjs described as ASI:One code review for pull requests. That is an unusual choice worth noting: the project uses its own hosted model to review incoming contributions. On licensing, the situation needs care. The repository metadata states MIT, while the README's licence badge and the LICENSE entry in the repository tree both say Apache 2.0. Those two statements conflict, and I cannot resolve which governs from the material available. Both are permissive, but they differ on patent grants and notice requirements, so if you plan to reuse code in a product, read the LICENSE file at the repository root and treat the badge and the metadata as unverified until you do. This is not legal advice, and the discrepancy is exactly the kind of thing to raise with whoever handles licensing on your side before you copy code into a distributed product.

Editorial conclusion

Adopt this repository if you are building on uAgents or Agentverse and want a runnable reference for a specific integration rather than a blank file. Do not adopt it if you need a maintained library with a stable API, or if you are targeting a framework it does not cover. Before committing, run ./setup.sh on the one example closest to your use case, read that folder's .env.example to confirm which paid keys it requires, and check whether the pinned dependency versions still resolve on Python 3.10 or newer.

Official sources

1. fetchai/innovation-lab-examples on GitHub
2. Issues
3. License: MIT
4. Project website
5. README