AION

Most of the digital tools we use today operate independently from one another. Taking notes, running a command, finding information, remembering a task or performing an action on a computer usually means switching between different applications and interfaces. AI assistants bring some of these pieces together, but they often remain little more than conversational interfaces. The question I wanted to explore is different: how far can I take a personal digital assistant built from the ground up—one that runs around my own digital environment, understands me and the systems I use better over time, gains new capabilities and, when appropriate, takes action instead of simply responding?

AION is a personal engineering project inspired by the idea of JARVIS from Iron Man, but designed around real-world needs and the technological boundaries of today. My goal is not to repackage an existing conversational interface. I want to build an assistant architecture that can understand commands, select the appropriate capability, preserve context and expand as new capabilities are added over time. The project also serves as a practical laboratory where I explore AI, agent architectures, natural-language computer interaction and personal automation.

One of AION's most important constraints is keeping control in the hands of the user. Giving a personal assistant access to actions on a computer can be powerful, but it also introduces risk. The system therefore needs a clear distinction between commands that only produce information, commands that perform real actions and operations that require explicit user approval. The architecture must allow new capabilities to be introduced without breaking existing behavior. Because this is a personal project, I also avoid unnecessary infrastructure and service complexity, focusing first on a reliable core and expanding its capabilities in a controlled way.

Build a central assistant experience capable of understanding commands expressed in natural language. Bring conversation, commands, notes and activities together within the same context. Create an extensible intent and capability architecture that can identify what the user wants and select the appropriate capability. Allow new capabilities to be added without continuously modifying the core system. Gradually improve memory and context so the assistant can move beyond responding only to the current command and make use of previous interactions. In the longer term, combine voice interaction and controlled computer actions within the same architecture.

Rather than relying on a single large AI call to solve everything, I am developing AION as a modular assistant with clearly separated responsibilities. User input is first normalized and its intent is identified. The appropriate capability is then selected and the requested operation is performed. Conversation, quick actions, notes and activity history come together in a single user experience. When a new capability is needed, it can be added to the system instead of redesigning the entire application. This allows AION to evolve as a living system that gains new capabilities with each iteration rather than as one large product that must be completed all at once.

AION's client application is being developed with Angular and TypeScript. The architecture separates responsibilities such as the user interface, intent resolution, command matching, capabilities, memory and activity tracking. User input passes through a central intent layer, where matchers recognize specific types of commands and route them to the appropriate capability. When multiple matches are possible, priority and scoring determine which capability should handle the request. New commands are designed to be introduced through additional matchers and capabilities rather than changes to the core flow. Memory is treated as a separate responsibility that can evolve from short-term conversational context into more persistent user context over time.

AION is a personal engineering project that I designed and develop myself. I manage the entire process, from the product idea and user experience to architectural decisions and implementation. My objective is not simply to produce a working assistant; by building as much of the system myself as possible, I want to understand intent resolution, capability design, memory, agent behavior and human-computer interaction at a deeper level. I use AI-assisted development tools during implementation, while keeping architectural decisions, behavioral rules, quality control and decisions about the system's permissions under my own control.

Frontend: Angular / TypeScript

Architecture: Modular, capability-based personal assistant architecture

Intent: Normalized user input, matcher-based intent resolution, scoring and priority management

Capabilities: Independently extensible command and capability layers

Experience: Conversation, quick actions, notes and activity history

Memory: A memory approach designed to evolve from short-term context toward persistent user context

Interaction: Text-based interaction, with voice interaction planned for later stages

Development: AI-assisted development, automated testing and a controlled checkpoint/code review process

Build the architecture from the ground up rather than customize an existing assistant product. Separate intent and capability layers instead of relying on a single large decision mechanism. Allow new capabilities to be introduced without continuously modifying the core code. Separate operations that only provide information from those that perform real actions on the user's computer, while preserving user control for critical actions. Build a small and reliable core before attempting to create an assistant that can do everything. Treat memory and agent behavior as architectural concerns from the beginning without introducing complexity before it is actually needed.

Natural language does not follow deterministic rules, so similar expressions can potentially match different intents. As new capabilities are added, matching priorities and conflict resolution need to remain controlled so previously working commands are not broken. On the memory side, deciding what is actually worth retaining is important to avoid creating a system that remembers everything but cannot use that information effectively. Another challenge is preserving security boundaries as the assistant gains more capabilities. Providing information and performing a real action on a computer do not carry the same level of risk, so permissions and approval mechanisms need to evolve alongside the capabilities themselves.

AION is under active development. The core Angular application, main user experience, conversation and quick-action flows, notes, activity tracking and the first layers of the intent/capability architecture have been established. Work is progressing on normalizing user commands, evaluating them through different matchers and scoring competing intents. The system is not yet a finished personal assistant, but the foundation for adding new capabilities in a controlled way is now in place. The next stages focus on expanding the memory layer, introducing more real capabilities and integrating voice interaction into the system.

What makes a personal assistant genuinely useful is not simply access to a powerful AI model. It needs to understand the user's intent, select the right capability, preserve context and, when appropriate, take action safely. Even a seemingly simple command can involve several interconnected decisions around intent resolution, prioritization, memory and security. Building the system from the ground up makes the purpose of each of these layers much more visible. That is the main value of AION for me: rather than being only a finished assistant, it is a living engineering project through which I explore how personal AI systems should be designed and push the architecture a little further with every iteration.