Echo Agent
A self-hosted automation agent with durable memory, evolving skills, and auditable execution.
Per-dimension scores and reasoning
Evidence shows: README describes approval for high-risk tool calls, encrypted credentials at rest, auditable execution logs; CI workflow uses least-privilege GITHUB_TOKEN and includes pip-audit and pnpm audit steps; pyproject.toml specifies dependency version floors with some justifications (e.g., playwright>=1.50). Deductions: data flow transparency is only descriptive, no concrete data flow diagrams or log examples; source attribution only mentions 'Echo Agent contributors', no clear maintainer identity.
Evidence shows: README and pyproject.toml descriptions are consistent; test files show specific tests for concurrent tool execution and memory deduplication; CI includes lint, test, security, dashboard, package jobs. Deductions: no specific examples of failure messages or error handling documentation; dependency availability only indirectly verified via CI.
Evidence shows: README clearly identifies target users (individuals and teams) and scenarios (private automation), lists multiple entry points (CLI, Gateway, Webhook, Cron, 14 channels), and states environment requirements (Python 3.11+). Deductions: capability boundaries are described broadly, no detailed list of built-in tools and skills; trigger precision not detailed.
Evidence shows: README has clear structure with Quick Start, Architecture, Core Capabilities, Use Cases, Development & Contributing sections; installation instructions are detailed including mirrors, Windows, one-liner script; naming is stable (echo-agent); license is MIT; version number in pyproject.toml (0.3.6). Deductions: missing FAQ and known limitations sections; no CHANGELOG file; maintenance responsibility only via community links.
Evidence shows: README describes outputs as auditable logs and cost reports, provides CLI commands to view config and cost; marginal value in cross-session memory and self-evolving skills; cost-benefit via multi-model routing and local-first design. Deductions: no specific performance data or cost comparisons.
Evidence shows: README feature descriptions partially correspond to code structure (e.g., test files), but no specific implementation details; CI test and audit steps can be seen as cross-validation. Deductions: claims and code correspondence not explicitly marked, facts and inferences not separated.
- Publisher identity is unverified; assess supply chain risks carefully.
- Security claims in README (e.g., approval mechanism, encrypted storage) need verification through actual execution.
- Dependency version floors may not cover all known vulnerabilities; run pip-audit regularly.
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.
- An individual running a private automation assistant on a workstation or owned server can use the CLI or local Gateway with one persistent agent.
- A team that needs shared task context across CLI, webhooks, scheduled jobs, and messaging bots can connect those entry points to the same state.
- 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.
- An operations workflow that runs commands or manipulates files and needs an audit boundary can use the approval policies and execution logs.
- 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?
- 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, andoffapproval 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.
- 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.1and 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 setupThe setup wizard guides model API-key entry; data defaults to ~/.echo-agent. Start the first interactive session with:
echo-agent runHow 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 startThen 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?
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?
echo-agent cli to the same persistent gateway, sessions are independent but memory is shared.How are high-risk tool calls controlled?
manual, smart, and off policies. Unattended channels reject high-risk calls by default, and execution logs are auditable.How can I inspect operating cost?
echo-agent cost to view a cost-attribution report.