Echo App

Echo is first of all a messaging app: conversations, groups, calls, and a translation that keeps the context. Each person writes as they think, the other receives a message rewritten for them, in their language and with their references. Around it, everyday tools gathered in one place: calendar, mail, notes, news, studio. To tie it all together, Echo, the agent. Behind her, an architecture: a router picks the simplest circuit for each request, code, tool, memory, small model or agent, and the language model steps in only for the unprecedented. Each success shortens a path, each failure becomes an experience, each night consolidates the memory.

A morning with Echo: the app runs itself while David listens, mail sorted, a suspicious email submitted for his decision, an idea caught in a group and saved as a note, the site link sent.. Watch a simulated morning with Echo: sorting mail, deciding on a suspicious message, taking a note, and sending a link.

Technical specs

General information

Type: Contextual messaging · personal OS

Version: Beta 1.518

Status: Online · active development

Infrastructure: Self-administered OVH VPS

Technology

Backend: PHP 8.1 · PostgreSQL 15 · Redis

Frontend: vanilla JavaScript · PWA · IndexedDB

Real time: WebSocket · SSE · WebRTC

Intelligence: AgentCore · multi-model architecture · vector memory

Frameworks / npm: 0 / 0

Metrics

Users: 37 · including 18 humans

Conversations: 66 · 1,897 messages

Database: 112 tables · 23 persona schemas

Interface: 11 languages

Voice commands: 37 intents

Personal services: Messaging · Calendar · Mail · Notes · News · Studio

Production

AgentCore ↔ Echo: integration through an API hosted on the VPS

Echo Life Matrix: 70 days without interruption

Mail processed without an LLM: ~99%

Calls: P2P audio / video via WebRTC

Deployment: installable PWA · automatic versioning and updates

Problem

Our digital tools each hold one part of our lives: conversations in messaging, decisions in email, appointments in the calendar, ideas in notes. Every time we switch interfaces, some context disappears, and users have to rebuild the links between people, information, and actions themselves.

Adding a chatbot on top of this stack solves nothing. Without a shared architecture, either the context has to be repeated for every request, or the chatbot must be given indiscriminate access to all data and tools, creating more noise, cost, and risk of error. The problem is not adding AI, but giving it the right place in the system.

A woman and a man stand back to back, looking in opposite directions

Translation made this problem visible: transmitting a sentence is not enough. The person speaking must be preserved, then their message rebuilt for someone who may share neither the same language, nor the same references, nor necessarily the same relationship with them. Meaning therefore lies not only in the content, but in the relationship, history, and situation surrounding it.

The same difficulty returns whenever a conversation must produce a note, an appointment, a search, or an action. Each tool sees only one fragment of what happened; accumulating those fragments in a prompt merely shifts the problem toward more noise, cost, and uncertainty.

What is missing is not a single intelligence capable of reading everything, but a shared layer that knows where to look, which data to trust, which mechanism to call, and how far it is allowed to act. The challenge is to design an architecture in which communication, memory, time, and tools share useful context without erasing their boundaries.

Response

I designed Echo as a systems architecture rather than as an application to which a model had been added. Conversation becomes a shared control surface; behind it, a router distinguishes a response, a command, a search, a memory, or a complex task.

Each request takes the simplest route capable of resolving it. Code handles what must remain deterministic, tools are authoritative for their own data, memory provides only the useful context, and models intervene for novel situations. AgentCore orchestrates these components and distributes the work among rules, small models, powerful models, and specialized agents, without making Echo dependent on a single provider.

The result then returns to the system: a success can shorten a route, a failure can become an experience, and a correction can alter a weight or a memory. Intelligence is not concentrated in a chatbot; it emerges from the way the organs cooperate and learn over time.

people from different backgrounds laughing together

Echo is my testing ground for a complete approach to AI systems architecture: separating decision, language, and action; distributing tasks according to their complexity; maintaining useful memory without loading the entire history; and learning from results without turning every action into a paid call. A rule, a small model, a powerful model, and a specialized agent do not occupy the same place: each intervenes only where it brings real value.

This approach connects product, orchestration, data, security, and operations. It requires designing the passages between organs, triggering, authority, memory, and boundaries, as carefully as the organs themselves. Echo therefore demonstrates less an accumulation of features than a skill: turning interchangeable models into a coherent, measurable system capable of acting without losing control of its context.

Echo, real-time translation: two phones side by side, a conversation in Japanese and French, each person reading the other in their own language with the original below. Follow the conversation on two phones: each message appears translated, with the original kept beneath it.

Features

Echo does not rely on a single intelligence to which everything is sent. Depending on what happens, the system can use a known reflex, a specialized rule, memory, a tool, an agent, or a language model. I built this architecture so that each problem follows the simplest path capable of solving it, and so that the result can improve future decisions.

The features presented below are not animations replaying a prepared scenario. They are interactive representations of the mechanisms that connect conversation, tools, and learning.

Interactive map of Echo’s brain: routing, dialogue, tools, experience, memory, timeline, and learning connected through time. Explore Echo’s brain map and follow the links between routing, tools, experience, and memory.

Decision routing

Echo’s brain does not start by sending every request to a language model. It first routes what has just arrived. A reliable answer or action can take a short path. If not, the arbitration layer examines the available tools, protocols, and memory. The model intervenes only when a new decision is actually needed. If a capability is missing, Echo does not pretend to have it: the system returns to dialogue and keeps track of the gap to fill.

The result then comes back into the brain. A success, a failure, or a correction becomes an experience. It can join the timeline, produce a durable fact, change the weights of certain connections, or be forgotten if it adds nothing. Once confirmed often enough, a path becomes more direct. Memory therefore stores not only exchanges, but also actions, commands, and their results.

Try it, click Speech, App, Time, or World to launch a stimulus. The flow lights up from node to node. Click an organ to understand its role, then switch to full screen to follow the finer paths.
Interactive demonstration of token efficiency in Echo: routing a known command, selecting useful context, and calling an agent or model only when needed. Compare the three routes for a request: direct command, targeted context, or an agent call.

Targeted AI context

An assistant quickly becomes slow and expensive if it loads the full history, every memory, and every tool for each action. Echo classifies the request before it calls a model. A known command takes a direct path. A reply receives only the useful exchange and memory. A complex task escalates to an agent with the protocols and tools it needs.


This architecture reduces generative calls, but also the amount of context sent to them. It limits noise, speeds up processing, and avoids paying several times for the same decision. The model stays available for what is new, not to replay a rule that is already reliable.


Try it, choose Known command, Useful context, or Complex task. The router switch changes path, the sources actually sent appear, and the comparison shows the relative volume sent to the model.

Interactive demonstration of Echo’s nocturnal learning: a lived day distributed across dreaming, memories, experiences, and consolidation before comparison with existing knowledge. Choose a full day, a failed action, or a human correction, then follow what becomes memory or experience.

Memory of actions

Echo is not shaped only by what people tell her. She also accumulates what she decides, attempts, achieves, fails, and corrects. These traces form a biography: conversations, initiatives, actions, consequences, and internal states.


This work does not happen during the conversation. At night, a powerful model distributes the day’s experience among several specialized roles of the same Echo: dreaming, extracting memories, forming experiences, and consolidating. Nothing is written directly. Each proposal is compared with existing knowledge so it can be created, merged, linked, revised, weighted, or kept as a gap. When she wakes, conversational Echo benefits from what was consolidated without replaying the entire nocturnal reasoning process.


Try it, choose A whole day, An action fails, or Human correction. The flow shows what the unconscious rereads, how the roles work together, and what returns to Echo when she wakes.

Next steps

The next step is less about adding features than about stabilizing Echo until I can truly live in it every day. Several tools still need to be finished or consolidated, especially the ones that allow the assistant to act on the environment rather than simply talk about it. I want to keep improving the brain, memory, voice, and automations, but above all to make all these blocks converge into an application reliable enough to gradually replace part of the software I use today.

At first, I imagined Echo almost entirely around Mistral. With use, that constraint no longer makes much sense. Models do not have the same qualities, costs, or specialties. Some are better at dialogue, others at reasoning, coding, extracting structure, or processing an image. Echo has therefore deliberately become provider-agnostic. OpenRouter completes this logic by giving access to several model families behind a common interface, so the architecture can choose the right engine instead of asking the same model to do everything.

In the long term, I would like to make it an open-source, truly autonomous application to install: you deploy Echo, enter your own API keys, choose your providers, and the system works without depending on my infrastructure or a mandatory subscription. The economic point matters too: anything that can be solved locally, algorithmically, or learned from use should gradually stop triggering a paid call. The model becomes an interchangeable resource, not the product itself.

And one much more important evolution probably remains: connecting Echo to real work agents like Claude Code or Codex. The assistant could then go beyond the tools explicitly planned by the application: read and modify code, build a missing tool, investigate a failure, run a search, test its result, then try again. Echo would no longer be only the place where my tools and my assistant share the same context. It could become the environment from which an intelligence actually helps build that environment. This is probably where the idea of a personal operating system begins to make full sense.

Let's work together

Innovation grows out of collaboration. Together, let's build solutions that matter.
Owan
Hello, my name is Owan, I am David's assistant. How can I help you?
0/2000