Automation & Ops self-hostinglong-term-memorymcp-clienta2a-json-rpctool-approvalgateway-apitask-schedulingtelegram-integration

Echo Agent

A self-hosted automation agent with durable memory, evolving skills, and auditable execution.

FollowAgents review · FARS-2.0
Not yet reviewed
See the full review method →

What does this agent do, and when should you use it?

Echo Agent is a self-hosted, long-running AI agent for private automation by individuals and teams. A shared Agent Loop handles events from the CLI, Gateway, Webhook, Cron, and multiple messaging channels. Its cognitive memory has Working, Episodic, Semantic, and Archival layers, with decay, contradiction detection, importance reranking, and BM25-plus-FAISS retrieval that can fall back when FAISS is unavailable. The project records execution trajectories and evaluates skill-improvement candidates before promotion, with rejection, cooldown, and rollback paths. Sessions, memories, trajectories, and credentials are stored locally by default, with credentials encrypted at rest; the gateway listens on loopback by default.

The Agent Loop follows the documented flow: receive an event, build context, call a model, and execute tools. It retrieves context from its four cognitive-memory layers, uses combined BM25 and FAISS retrieval, and records execution trajectories for the self-evolution engine to generate and evaluate skill candidates. Model routing can independently configure providers and models for primary reasoning, context compression, embeddings, and risk approval. Tool calls are handled through manual, smart, or off approval policies, while unattended channels reject high-risk calls by default. The agent also interoperates through A2A JSON-RPC and an MCP client with OAuth, supports dynamic tool registration, and produces cost-attribution reports through echo-agent cost.

  1. An individual running a private automation assistant on a workstation or owned server can use the CLI or local Gateway with one persistent agent.
  2. A team that needs shared task context across CLI, webhooks, scheduled jobs, and messaging bots can connect those entry points to the same state.
  3. A user whose preferences, task experience, and historical context must persist across conversations can use the four-layer memory system and its decay and contradiction checks.
  4. An operations workflow that runs commands or manipulates files and needs an audit boundary can use the approval policies and execution logs.
  5. A deployment that needs MCP tools or cross-process collaboration through A2A JSON-RPC can use the documented MCP client and interoperability layer.

What are this agent's strengths and limitations?

Pros
  • Its four-layer cognitive memory explicitly combines forgetting, contradiction detection, and importance reranking to address memory growth in long-running use.
  • The self-evolution workflow records trajectories, generates candidates, compares evaluations, and supports promotion, rejection, cooldowns, and rollback rather than blindly replacing skills.
  • High-risk tool calls have centralized `manual`, `smart`, and `off` approval modes, with unattended channels rejecting high-risk actions by default.
  • One execution path serves the CLI, Gateway, Webhook, Cron, and multiple messaging channels, with MCP, OAuth, and A2A JSON-RPC support.
Limitations
  • It requires Python 3.11+ and at least one model API key, so model operation depends on an external provider.
  • The default Gateway binds only to `127.0.0.1` and does not support remote addresses; remote access requires SSH.
  • Browser access is constrained by default Origin and allowlist protections; using a playground or browser client requires authentication, user, or Origin configuration changes.
  • Background-service installation is documented for macOS user LaunchAgents and Linux user systemd; environments without systemd need a foreground-process keeper such as tmux or nohup.

How do you install or deploy this agent?

The documented runtime is Python 3.11+ and at least one model API key is required. Install and complete initial configuration:
pip install "echo-agent[all]"
echo-agent setup
The setup wizard guides model API-key entry; data defaults to ~/.echo-agent. Start the first interactive session with:
echo-agent run

How do you use this agent?

For interactive use, run echo-agent run. For persistent operation after echo-agent setup, run:
echo-agent gateway install
echo-agent gateway start
Then use echo-agent cli from a local terminal to connect to that gateway. Sessions remain separate while memory is shared. Use echo-agent gateway status for service status, echo-agent gateway logs -f for logs, and echo-agent cost for cost attribution.

FAQ

Can it keep running after I close the terminal?
Yes. `echo-agent gateway install` registers the gateway as a macOS user LaunchAgent or Linux user systemd service, then `echo-agent gateway start` starts it.
What is shared across sessions?
When clients connect through `echo-agent cli` to the same persistent gateway, sessions are independent but memory is shared.
How are high-risk tool calls controlled?
The tool-approval system offers `manual`, `smart`, and `off` policies. Unattended channels reject high-risk calls by default, and execution logs are auditable.
How can I inspect operating cost?
Run `echo-agent cost` to view a cost-attribution report.
What happens if MCP is unavailable?
The documentation describes an MCP client with OAuth and dynamic tool registration, but does not specify a failure or fallback behavior for an unavailable MCP service.

Related agents