Aria extras: conversation examples and the feature builder

This is the last post in the series. Behind the scenes covered how Aria is put together. This one covers two features that don’t belong to any of the components before it: one about how Aria talks, and one about how Aria could help build itself.

Conversation examples

Local models have a style problem. Ask a small model to be a warm, casual friend, and you still get assistant-speak: tidy paragraphs, a summary of what you said, a helpful closing question. The conversation principles push against that, but describing a style only goes so far. Showing it works better.

So Aria can be given datasets of other conversations to use as a style reference.

Retrieval, not training

Nothing is fine-tuned. Examples work the same way as memory and knowledge: retrieval.

• Importing. Upload a .parquet file or a plain-text dialogue. Aria previews it and suggests how to read it: pairs (two text columns, like He/She), threads (consecutive posts by different people become exchanges), message lists (role and content), or dialogue lines (Name: text, or alternating lines, with a blank line starting a new conversation).
• Cleaning. Each example is an exchange: up to two earlier lines, the line being answered, and the reply. Links are removed, and usernames and timestamps are never stored. Duplicates are dropped, and the set is sampled evenly down to the size you choose. The uploaded file is deleted afterwards.
• Indexing. Exchanges are embedded into their own Qdrant collection, separate from memory and knowledge.
• Using them. For each reply (not for messages Aria starts itself), Aria finds the exchanges closest to the current moment in the conversation, at most one per set, above a similarity threshold, and adds them to the prompt as STYLE EXAMPLES (data).

The prompt is explicit about what they are: examples of tone, rhythm and phrasing, never facts and never shared history. Aria shouldn’t think it went to the beach with you because someone in a dataset did. In the context budget, style examples are the first optional section to go.

Ratings and the relationship

Not every style fits every relationship. Each set has a rating:

• General sets are always used.
• Romantic sets are only used once the relationship is romantic (attachment level 5 or higher) and romance is allowed.
• Explicit sets need the same, and are never used for a Reserved persona.

So the same persona can sound like a friendly acquaintance early on, and only draw on more intimate examples when the relationship has actually got there, which the relationship posts describe.

Switching the engine or embedding model re-indexes example sets along with memories and knowledge, like any other vectors (Running it locally, Part 1).

The feature builder

The second extra is the most experimental part of the project, and it’s built to be removable.

Knowing itself described how Aria can suggest ideas, things it would like to be able to do, in the “From Aria” inbox. The feature builder takes that one step further: while it’s switched on, Aria can request a feature, and an AI coding agent builds it on a copy of the code, as a patch for me to review.

An add-on, not part of the core

The feature builder lives outside the core. Its code is in its own folders (one for the server, one for the web app), and the core projects never reference it. The API project registers it with a few lines marked “Add-on”. Removing it means deleting those folders and those lines.

It owns its own two tables, its endpoints, and one tool, request_feature, which is only offered while the builder is armed. You arm it for a limited window from Settings → Add-ons, and a monitor disarms it when the window ends.

Isolated by design

Letting an AI agent write code on your machine needs to be boring and safe:

• Every request needs approval. Aria can ask. Nothing is built until I approve it.
• The agent runs in its own sidecar container (Node with the Claude Agent SDK, on the .NET SDK image), reachable only from Aria on its own network, and it checks a shared token.
• It works on a copy. The source is mounted read-only. For each job, the sidecar copies it into a job folder without secrets or private data, and the agent works there.
• It runs with limits: default permissions, a guard that denies tools by default, and caps on turns, cost and time.
• The result is a patch (git format-patch), for review in Settings → Add-ons. Nothing is applied automatically.

So the worst case is a bad patch, which I read and decline.

The end of the series

That’s every feature in Aria, up to now. Starting from the introduction, the series covered:

• The foundations: memory and its RAG pipeline, conversations, and running it all locally.
• What makes it a persona: personality, the relationship, reaching out first, knowledge and interests, and knowing itself.
• The extras: a voice, tools and the web, a face, a talking picture, games, stories and roleplay.

What’s next is in the roadmap in Aria’s own documentation, and Aria knows about it too.

What I learned

• Show, don’t describe. A few retrieved exchanges teach tone better than any paragraph about tone, and retrieval keeps them swappable.
• Tie style to the relationship. Ratings that follow the attachment level keep a persona from sounding more intimate than the relationship is.
• Make experiments removable. An add-on that the core never references can be tried and dropped without risk.
• Agents get copies, limits and review. A patch you read is the right interface between an AI that writes code and a project you care about.