Velia began with a practical question: what is missing from a conversation when we ask it to do work on a Mac? An answer can explain how to compare two documents. Delivering the comparison still requires finding the files, reading them and checking the differences. The project took shape in this move from words to operations.

Velia is now a working macOS prototype. Conversation sits alongside tools for reading documents, finding information, keeping notes and working with permitted resources. This first chapter follows the mechanism connecting those capabilities. A document comparison will illustrate the process; it is not presented as a test already performed.

The first brick: preserving a specific request

Before calling the model, the application saves the person’s message and starts an identified execution. The code calls this a run: a record linking the goal, steps and state of that attempt. It helps prevent a late response from being attached to a later request in the same conversation.

The second brick: returning with what actually happened

In the ordinary path, the coordinator prepares the context: the request, relevant information and functions currently available. The model can propose a function call or a concluding text. For a function call, the application checks the name and arguments, passes the operation to its designated executor and collects the outcome. That outcome becomes part of the next round’s context.

A saved request feeds the context and model. A function passes through checks and execution; its outcome returns to the context. Final text passes through closure checks.
The return path matters: the next step can change because the model now has information that was previously missing.

In our example, the first outcome might list the two documents. The model can request relevant sections and then prepare the comparison. A missing file returns as a limitation: the model may ask where to find it or deliver an explicitly partial comparison. The actual sequence depends on the information received and the model’s decisions.

Choosing an operation and being allowed to perform it

A skill contains reusable instructions for a task. A tool is a function the application can execute. Loading a skill can guide the model’s work; access to a folder still depends on permissions granted to the chat and valid when the reading takes place.

This separation is central to the project. Understanding language belongs to the model, including freely worded versions of the same request. Code checks identities, revisions, parameters and permissions. It does not select behaviour by looking for a required phrase in the message.

Work must also be able to stop

The prototype records individual steps, including model calls, and distinguishes receiving an outcome from being allowed to accept it. After Stop, a late response must not reopen the stopped work. An external operation may already have had an effect, however: ending the wait does not undo work another service has completed.

This is why “I created the note” is insufficient. Without confirmation from the application responsible for creating it, the outcome remains uncertain. Immediately repeating the operation could create a duplicate. The loop must also handle errors and uncertain outcomes.

Where we stand, and the next brick

This loop belongs to the adult Velia prototype; some tasks use external services and need a connection. The Lab follows its construction, while no public installation package is available here yet. The next chapter will explore memory: what to preserve so that work can resume without turning an old assumption into a fact.

The project and further chapters Explore the Lab