Aser: a Python agent framework that assembles from named parts

What Aser is solving, and for whom

Most agent frameworks make you choose between a two-line demo and a configuration file that hides the wiring. Aser takes the opposite route. The README describes it as a minimalist, modular framework where you assemble an agent with a few lines of code, and the full example shows that assembly as a single constructor call: Agent(name="aser", model="gpt-4o-mini", tools=[web3bio, exa], knowledge=knowledge, memory=memory, chat2web3=[connector], mcp=[price], trace=trace). Every capability is a named argument. Nothing is registered through a decorator, a plugin manifest or a global registry.

That design targets a specific reader. If you are building a chat wrapper and want the shortest path to a working bot, Aser is not shorter than the alternatives. If you are building something where you need to swap one memory backend for another, or add an MCP server without touching the rest of the agent, the argument list is the whole configuration surface and you can see it in one place. The example index reinforces this: it is organised by capability (memory, RAG, tools, toolkits, trace, API, CLI, Discord, Telegram, Farcaster) and then by topology (router, sequential, parallel, reactive, hierarchical multi-agent). That is a catalogue of parts, not a tutorial path.

The repository topics point at the same audience: a2a-protocol, erc8004, mcp, onchain-ai, text2sql, rag, multi-agent. This is a framework written by people building Web3-adjacent agents, and the examples assume you may want a Farcaster client or an ERC8004 identity alongside a plain LLM call.

The constructor argument list is the architecture

The clearest description of how Aser works is the full configuration example, because each argument corresponds to a subsystem the agent calls during a turn. model selects the LLM and is the only required piece in the basic example. tools is a list of callables the agent can invoke. knowledge is a retrieval source, which the README associates with the RAG example. memory is a storage object. mcp is a list of Model Context Protocol servers, and the README separately lists MSCP, described as Model Smart Contract Protocol, in the advanced examples. chat2web3 takes connectors, which is how the Web3 examples are wired in. trace collects execution data.

What the README does not give is the internal data flow. There is no diagram description beyond an architecture.png image reference, no description of how a tool result is fed back into the model, and no statement about the order in which memory, knowledge and tools are consulted. The argument names imply a pipeline: retrieve knowledge, load memory, offer tools, call the model, record a trace. Treat that as inference from the interface, not as documented behaviour. If you need to know whether knowledge retrieval happens before or after memory injection, the README will not tell you; the examples/ directory is the place to look.

The multi-agent examples are similarly structural. Router, sequential, parallel, reactive and hierarchical are listed as separate files, which suggests each topology is expressed as a composition of Agent objects rather than as a mode flag on a single agent. That is a reasonable choice for readability, but it means the coordination logic lives in your code, not in the framework.

Installing Aser and the environment variables it expects

Two installation paths are documented. From PyPI: pip install aser. From source: git clone https://github.com/AmeNetwork/aser.git, then cd aser and pip install -r requirements.txt. The README adds a note for the source path: run pip install -e . in the root directory before running the examples, so that Python finds the aser module locally. If you installed from PyPI, the README says the examples run directly.

Configuration is through a .env file, created from .env.example. The README is explicit that you do not need to configure every variable, only the ones you use. The two it names are MODEL_BASE_URL and MODEL_KEY, both under a #MODEL comment. That pair implies an OpenAI-compatible endpoint rather than a hardcoded provider, since a base URL and a key are the minimum for pointing at a self-hosted or proxied model. The README does not list the other variable names, so anything beyond model credentials has to be read from .env.example in the repository.

The smallest working program is three lines: import Agent from aser.agent, construct it with a name and a model string such as "gpt-4.1-mini", then call agent.chat("what's bitcoin?") and print the response. Note that the basic example passes the model directly to the constructor while the environment section defines MODEL_BASE_URL and MODEL_KEY; the README does not explain how those two paths interact, so if you set both, verify which one wins before assuming.

Where Aser's approach breaks down

The most concrete limitation is release state. No releases were retrieved for this repository, and the README documents installation as either PyPI or a clone of main. There is no version compatibility table, no changelog in the supplied material, and no statement about API stability. If you pin aser in a production requirements.txt, you are pinning either a PyPI version whose relationship to main is unstated, or a commit. For an agent framework where the constructor signature is the entire configuration surface, a rename of one argument is a breaking change across your codebase.

Second, the framework is Python-only and the examples lean on external services. The client examples cover Discord, Telegram and Farcaster, and the tool examples reference exa and web3bio. Each of those is a dependency with its own credentials and rate limits, and the README does not describe how failures in one client propagate. There is a trace argument, which suggests observability is opt-in rather than built in, but the README does not say what trace records or where it writes.

Third, the README is a feature index rather than a specification. The advanced section lists MSCP twice under two different example files, and the ERC8004 entries are labelled Experiments. That labelling is honest, and it is also a signal: the onchain pieces are the least settled part of the project. If your use case is a plain RAG agent over internal documents, most of the repository's surface area is irrelevant to you, and the parts you would use (knowledge, memory, tools) are the least documented in the README.

How Aser differs from LangGraph and similar graph frameworks

The closest comparison in this space is LangGraph, which models an agent as a state graph: you declare nodes and edges, and the framework executes the graph. Aser's README shows no graph declaration. Coordination appears as separate example files for router, sequential, parallel, reactive and hierarchical topologies, which implies you compose Agent objects in ordinary Python and the control flow is your loops and conditionals. The difference matters at debugging time: with a graph you can inspect the execution structure the framework holds; with Aser the structure is your code, so a stack trace points at your function rather than at a framework node.

A second contrast is scope. LangGraph is a general orchestration library and expects you to bring your own model client and tool abstractions. Aser bundles those concerns as constructor arguments, including mcp and chat2web3, and ships clients for Discord, Telegram and Farcaster. That is more opinionated at the edges and less opinionated in the middle. If you already have a memory layer and a retrieval layer, Aser's knowledge and memory arguments are the integration points, and the README does not document their expected interfaces, so you will be reading examples/agent_memory.py and examples/agent_knowledge.py to find out what shape those objects must have.

There is also the A2A angle. The README lists A2Aser for integrating Google's Agent2Agent protocol and a separate A2A Client example. Frameworks that treat agent-to-agent messaging as a first-class transport, rather than as another tool, will have a different answer here; Aser's README presents A2A as one example among many rather than as the core abstraction.

Maintenance cost, licence and what to check first

The licence is MIT, stated in the README and confirmed in the repository metadata. MIT permits commercial use, modification and redistribution with the copyright notice retained. That is permissive and unsurprising for a framework of this kind. It says nothing about the licences of the optional pieces: the Discord, Telegram and Farcaster clients, the exa and web3bio tools, and any MCP servers you attach are separate dependencies with their own terms, and the README does not enumerate them. If you ship an agent built on Aser, the dependency audit is yours.

Maintenance cost depends on how much of the example surface you adopt. A basic agent using only model and tools has a small footprint, and the pip install aser path means upgrades are a version bump. An agent using memory, knowledge, MCP and a chat client has four or more integration points, each of which the README documents by example only. Upgrading then means re-reading the relevant example file to see whether the expected object shape changed. The absence of retrieved releases makes it hard to judge how often that happens; the last push timestamp on the repository is the only recency signal available, and it is not a substitute for a changelog.

The last push date in the metadata is 2026-04-21, and the repository is not archived. That tells you the project is active at the time of writing and nothing more. Before committing to Aser, run the intermediate examples that match your use case, starting with examples/agent_knowledge.py if you need RAG and examples/agent_mcp.py if you need MCP, and confirm the interfaces those files expect against the stores and servers you already run.

Editorial conclusion

Aser suits Python developers who want an agent whose parts are visible in the constructor: model, tools, memory, knowledge, mcp, chat2web3, trace. It is a poor fit if you need a stable released API, since no releases were retrieved and the README documents only the current main branch. Before adopting, open examples/agent_memory.py and examples/agent_knowledge.py and check that the memory and knowledge interfaces match your existing stores.

Official sources

1. AmeNetwork/aser on GitHub
2. Issues
3. License: MIT
4. Project website
5. README