When I first imagined AEDA, it was easy to let the scope expand. A local chat interface could become a coding environment. A coding environment could become an autonomous agent. The agent could grow a browser, a workspace, a terminal, and its own versions of tools that already exist.
That direction sounds ambitious, but it creates the wrong competition. Mature editors, command-line agents, automation systems, and specialised applications are built by teams that can focus on one category for years. An independent developer should not pretend to replace all of them with weaker copies.
AEDA should be the understandable layer between a person and powerful tools—not another tool that insists it must become the entire computer.
The useful part is the handoff
People often know what they want to accomplish but not which interface, model, or tool is appropriate. They may also be uncomfortable giving an agent broad access to files, applications, and commands.
AEDA can create value by handling the handoff: gathering the context the user intentionally shares, choosing or recommending an appropriate tool, explaining the requested permissions, and keeping the action visible from proposal through validation.
For coding, that might mean sending a well-defined task and selected context to a mature CLI or editor integration. For general automation, it might mean using Hermes or another agent system behind a safer interface. The underlying tool can change while the permission and review experience remains consistent.
The Pill and Assist experience
The main product direction is therefore the AEDA Pill (also called Assist). The Pill should be a fast way to invoke help from anywhere, with contextual review, permission explanations, and visible controls for consequential requests.
The interface should answer basic questions that agent systems often leave implicit:
- What information is being shared?
- Which tool or model will receive it?
- What does the system want to read, change, or execute?
- Can the result be previewed before it is applied?
- What happens if validation fails?
- Can the action be reversed?
Local first, not local only
AEDA should adapt to the computer it runs on. A high-end GPU can support stronger local models. A mid-range card may need smaller quantized models. A low-end laptop may rely on CPU inference for private tasks and use a cloud fallback when local execution would be painfully slow.
The important point is not to force one model onto every system. The application should identify available hardware, present the trade-offs clearly, and route tasks according to privacy, performance, and cost.
Why supervision matters
Convenience becomes dangerous when the user cannot see what an assistant is doing. AEDA is being designed around explicit permissions, targeted edits, dry runs, unified diffs, validation, and rollback. These are not advanced options hidden in settings; they are part of the normal path for consequential actions.
This also changes how success is measured. The goal is not the number of tasks completed without interruption. A successful assistant should reduce confusion without removing the user from decisions that matter.
A smaller product with a clearer role
Narrowing the direction does not make AEDA less ambitious. It makes the ambition more realistic: create an accessible, local-first assistant that helps normal users benefit from powerful software without requiring them to trust an invisible autonomous system.
Future posts will go deeper into the permission broker, context selection, model routing, and how wrappers around existing tools can still provide a coherent product experience.