Echo Agent: A Self-Hosted AI Agent That Keeps Memory and Skills Across Sessions

The Problem: Agents That Forget Everything Between Conversations

Most AI agents treat each conversation as a fresh start. They have no memory of your preferences, past decisions, or the outcome of a command they ran last week. For a personal assistant or a team automation tool, that is a real limitation. Echo Agent addresses this by building a persistent memory system into the agent runtime. It is designed for people who run an agent on their own server and want it to operate continuously, not as a one-shot Q&A tool. The README explicitly contrasts it with '一次性问答' (one-time Q&A) and highlights cross-session memory as the core feature. The intended user is someone who wants a private, self-hosted assistant that accumulates context and skills over time, with full control over data and access.

Four-Layer Memory and the Forgetting Curve

The memory system is the most distinctive part of Echo Agent. It uses a four-layer cognitive structure: Working, Episodic, Semantic, and Archival. Each layer serves a different retention purpose. Working memory holds the immediate context, Episodic stores past events, Semantic captures general knowledge, and Archival keeps long-term facts. The system includes automatic decay, which the README calls a '遗忘曲线' (forgetting curve), and contradiction detection. The purpose is to prevent memory bloat, a common problem when an agent runs for months and accumulates irrelevant or conflicting information. The decay mechanism prunes or downweights old memories, while contradiction detection flags or resolves conflicting facts. This is a concrete design choice: instead of storing everything forever, Echo Agent actively manages memory quality. The trade-off is that you need to trust the decay heuristics. If they are too aggressive, you lose useful context; if too lenient, bloat returns. The documentation does not specify the exact decay parameters, so you would need to test them with your own data.

Skill Evolution: Learning from Execution Trajectories

Echo Agent does not ship with a fixed set of skills. It has a self-evolution engine that generates candidate improvements from real execution trajectories. The flow is: record a trajectory, generate a candidate skill change, evaluate it against a baseline, and then either promote or reject it. There is a cooldown period and a one-click rollback. This is a significant departure from static tool registries. The agent learns from what actually happened during tool calls, not from pre-programmed rules. The evaluation step is important: it prevents every random success from becoming a permanent skill. The README says candidates only take effect after '评测验证' (evaluation verification). This adds a layer of quality control, but it also means you need to understand how the evaluation works. If the evaluation is weak, bad skills could be promoted. The rollback feature mitigates that risk, but it is a manual recovery step. For teams that want predictable behavior, this self-modifying capability is a double-edged sword. It is powerful, but it requires monitoring.

Getting Started: Commands and Configuration

Installation is straightforward. The README gives three commands: `pip install "echo-agent[all]"`, `echo-agent setup`, and `echo-agent run`. The setup command is an interactive wizard that guides you through model API keys and stores data in `~/.echo-agent`. For long-running deployment, you use `echo-agent gateway install` to register a background service. On Linux it creates a user-level systemd service; on macOS a LaunchAgent. No root is required. The gateway listens only on loopback (127.0.0.1), so remote access goes through SSH. For environments without systemd, like WSL2, the README suggests using tmux to keep the process alive. Configuration is managed via `echo-agent config explain`, `echo-agent config dump`, and `echo-agent config validate`. The dump command masks secrets. There is also a cost attribution report via `echo-agent cost`. The install script `scripts/install.sh` is a separate path for source installations, with options like `--repo gitee` and `--no-mirror-probe` for network tuning. This is a well-documented CLI, but the number of commands is high. New users will need to read the CLI reference to understand all options.

Safety: LLM-Based Approval for High-Risk Actions

High-risk tool calls, like command execution and file operations, go through an approval mechanism. The README describes it as 'LLM-based approval and explanation' that creates an auditable boundary. There are three policy levels: `manual`, `smart`, and `off`. In unattended channels, the default is to reject high-risk calls. This is a sensible default. The `smart` policy presumably lets the LLM decide, but the README does not detail how the LLM makes that decision. The key point is that every approval or rejection is logged for audit. This addresses the real problem of an agent running unattended and doing something destructive. However, the `off` policy is dangerous if enabled carelessly. The documentation likely covers this, but the README only mentions the three levels. The loopback gateway also has a CSRF protection: it rejects browser requests with cross-site Origin headers. This prevents a malicious webpage from driving your local agent. These are thoughtful security measures, but they require the user to understand the trade-offs. For example, opening browser access requires explicit configuration, which is a good thing but adds friction.

Limitations and Wrong Tool Cases

Echo Agent has clear boundaries. The gateway only listens on loopback, so it is not designed for remote access without SSH. That rules out scenarios where you need a public-facing API endpoint. The A2A support is inbound only: the README says the current runtime does not provide an outbound A2A delegation entry. So you cannot use Echo Agent to delegate tasks to other A2A agents. The memory decay and contradiction detection are heuristics; they may not fit every use case. If your work requires exact recall of every past interaction, the decay could be a problem. The self-evolution engine is also a risk: it changes the agent's behavior over time, which is not ideal for regulated environments where behavior must be deterministic. Finally, the project is in active development, with recent releases up to v0.3.7. That means APIs and config keys may change. The README mentions a one-click rollback for skills, but not for the whole system. For production use, you need to plan for upgrades and potential breaking changes.

Alternatives and Approach Differences

The most direct alternative is a plain MCP-based agent like Claude Desktop or a custom OpenAI Assistant. Those tools give you tool calling and some memory, but they do not have a built-in four-layer memory system or skill evolution. Claude Desktop relies on MCP servers for tools, and its memory is limited to conversation context or external memory tools. Echo Agent integrates MCP as a client, meaning it can use MCP servers, but it also has its own memory and evolution engine. The difference is architectural: Echo Agent is a long-running daemon with a unified state across channels, while MCP-based agents are often session-bound. Another alternative is a framework like LangChain or AutoGen, where you build your own agent loop. Those give you full control but require you to implement memory, approval, and scheduling yourself. Echo Agent offers these as built-in features. The trade-off is that you get a more opinionated system. If you need a specific memory algorithm or a different approval flow, you may hit a wall. The plugin system via entry-points offers some extension, but it is not a replacement for full customizability.

Maintenance, Licensing, and Upgrade Path

Echo Agent is MIT licensed, so you can use, modify, and redistribute it without per-seat fees. The project is hosted on GitHub and Gitee, with a documentation site. The release cadence is active: v0.3.5, v0.3.6, and v0.3.7 were released within a month. That suggests frequent updates, which is good for bug fixes but means you need to track changes. The README says that re-running the install script performs an upgrade, and it preserves existing configuration. After upgrading, you should run `echo-agent gateway restart`. The cost report command `echo-agent cost` helps monitor API spending, which is a practical maintenance feature. The background service includes crash auto-restart and boot-time startup, so operational overhead is low once set up. However, the documentation mentions a 'repository map' and 'code map', indicating a large codebase. If you modify the source, you are on your own for maintaining forks. The `[all]` dependency group suggests there are lighter install options, but the README does not list them. You would need to check the installation docs for those details. Overall, the maintenance cost is moderate: you need to monitor memory behavior, review skill evolutions, and upgrade regularly, but the tooling for that is included.

Editorial conclusion

Adopt Echo Agent if you need a self-hosted agent that retains context across sessions, evolves its skills from real usage, and enforces auditable approval for high-risk tool calls. Avoid it if you require a fully remote gateway, A2A outbound delegation, or a zero-maintenance setup without a model API key. Before deploying, verify the memory decay and contradiction detection behavior with your own workloads, confirm the approval policy for unattended channels, and test the gateway's loopback-only access boundary. The project is under active development with recent releases, so check the changelog for breaking changes before upgrading.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes