Context
I recently came across AIRI, a popular open-source project exploring the idea of a digital companion. It brings together real-time voice, Live2D and VRM characters, desktop and mobile experiences, environment awareness, and game interaction.
AIRI creates a strong sense that the character is always there. It can speak, react through expressions and movement, and take part in digital environments. Some capabilities are still evolving, but they already form a coherent experience.
OpenLoomi has a different strength. It connects messages, email, documents, projects, and the user's screen to understand ongoing work, past decisions, and unfinished tasks. Its long-term work memory allows that understanding to remain useful across projects and over time.
OpenLoomi already has an always-resident Loomi Pet, Loop-driven baseline states, temporary runtime states from chat and external agents, decision bubbles and cards, proactive tasks, and long-term memory. The opportunity is to connect more of OpenLoomi's real activity to this existing experience, so the Pet reflects what the system is actually doing beyond the current Loop and chat paths.
User experience and feature direction
Loomi could make more of its work visible in a simple and consistent way. For example, it could:
- reflect memory retrieval, tool execution, approval, and task completion through the existing Pet state system;
- explain which sources or memories led to a suggestion;
- surface important changes, conflicting decisions, or long-running unfinished work without turning routine background processing into noise;
- let users correct its understanding of people, projects, and preferences;
- briefly report what changed, what was remembered, and what still needs attention after a task finishes.
The existing decision card already carries useful fields such as source, reason, confidence, and priority. This proposal is partly about making that evidence consistent across more proactive and agent-driven flows.
Possible first slice
A small end-to-end flow may be enough to test the idea:
- OpenLoomi detects a meaningful change in the user's work context.
- It retrieves the relevant memories and sources.
- Loomi Pet reflects that activity using the existing runtime-state path.
- Loomi explains its understanding and suggests a next step.
- The user approves or rejects the action.
- OpenLoomi performs the action, records the result, and reports what remains open.
The main question is whether this makes the product easier to follow and more coherent over time. Real-time voice, richer animation, cross-device presence, Live2D, or VRM can remain later discussions.
Technical direction
OpenLoomi already has a useful foundation:
- an always-on-top Tauri Pet window;
StateCoordinator, with a Loop-derived baseline and temporary runtime overrides;loop:state events consumed by the Pet and bubble;- chat activity and external Codex, Claude Code, and CLI state inputs;
- decision-driven
presenting, needsinput, happy, sleeping, and other visual states;
- Bubble and Card windows for short messages, evidence, and approval actions.
Rather than introduce a second state model, this could extend the existing coordinator with a small set of semantic activity events from memory retrieval, tools, approvals, and reflection.
Those activities do not necessarily need new visual states. They could map onto the current vocabulary:
- memory retrieval ->
thinking;
- tool execution ->
working;
- approval required ->
needsinput;
- result ready ->
presenting;
- task completed ->
happy.
Keeping business activity separate from visual presentation would let Loomi Pet, status text, notifications, animation, and future voice features share the same underlying signals without moving agent logic into the UI.
At a higher level, the product can still be viewed through four connected areas:
- Presence - Loomi Pet, status, animation, voice, and notifications.
- Perception - screen context, connectors, active projects, and work events.
- Memory and understanding - people, projects, decisions, relationships, and unfinished work.
- Action - skills, CLI, automation, approval, and audit history.
AIRI is a useful reference because it shows how internal AI capabilities can become something users continuously see and understand. OpenLoomi already has much of the required foundation; the next step may be to connect that foundation more consistently to the rest of the product.
Context
I recently came across AIRI, a popular open-source project exploring the idea of a digital companion. It brings together real-time voice, Live2D and VRM characters, desktop and mobile experiences, environment awareness, and game interaction.
AIRI creates a strong sense that the character is always there. It can speak, react through expressions and movement, and take part in digital environments. Some capabilities are still evolving, but they already form a coherent experience.
OpenLoomi has a different strength. It connects messages, email, documents, projects, and the user's screen to understand ongoing work, past decisions, and unfinished tasks. Its long-term work memory allows that understanding to remain useful across projects and over time.
OpenLoomi already has an always-resident Loomi Pet, Loop-driven baseline states, temporary runtime states from chat and external agents, decision bubbles and cards, proactive tasks, and long-term memory. The opportunity is to connect more of OpenLoomi's real activity to this existing experience, so the Pet reflects what the system is actually doing beyond the current Loop and chat paths.
User experience and feature direction
Loomi could make more of its work visible in a simple and consistent way. For example, it could:
The existing decision card already carries useful fields such as source, reason, confidence, and priority. This proposal is partly about making that evidence consistent across more proactive and agent-driven flows.
Possible first slice
A small end-to-end flow may be enough to test the idea:
The main question is whether this makes the product easier to follow and more coherent over time. Real-time voice, richer animation, cross-device presence, Live2D, or VRM can remain later discussions.
Technical direction
OpenLoomi already has a useful foundation:
StateCoordinator, with a Loop-derived baseline and temporary runtime overrides;loop:stateevents consumed by the Pet and bubble;presenting,needsinput,happy,sleeping, and other visual states;Rather than introduce a second state model, this could extend the existing coordinator with a small set of semantic activity events from memory retrieval, tools, approvals, and reflection.
Those activities do not necessarily need new visual states. They could map onto the current vocabulary:
thinking;working;needsinput;presenting;happy.Keeping business activity separate from visual presentation would let Loomi Pet, status text, notifications, animation, and future voice features share the same underlying signals without moving agent logic into the UI.
At a higher level, the product can still be viewed through four connected areas:
AIRI is a useful reference because it shows how internal AI capabilities can become something users continuously see and understand. OpenLoomi already has much of the required foundation; the next step may be to connect that foundation more consistently to the rest of the product.