ANNIE V4: Building a Persistent Local AI Runtime

Why I Started V4

Most AI products are built around a temporary interaction. A user provides a prompt, the model generates an answer, and the useful context slowly disappears as the conversation grows or the session ends. That can work for quick questions, but it is a weak foundation for long projects, continuing research, or any relationship that depends on history.

I wanted ANNIE to become something more persistent. The goal was to create a system that could remember what I was building, recognize why a decision had been made, recover after an interruption, and connect a new request with relevant work from weeks or months earlier. V4 grew from that requirement for continuity.

This version is also a response to the limits I found in earlier ANNIE builds. A model can sound thoughtful while lacking the right memory. It can claim that work is complete without proof. It can call a tool when conversation would have been better, or give a confident answer when fresh evidence was required. ANNIE V4 treats those problems as systems problems, not issues that can be solved by a larger prompt alone.

What ANNIE V4 Is

ANNIE V4 is a local-first AI runtime built around a language model rather than a thin interface placed in front of one. The model is still responsible for interpretation and natural responses, but it operates inside a larger environment that manages memory, projects, research, tools, background work, speech, evaluation, and controlled execution.

The simplest way to describe it is as personal AI infrastructure. It is designed to remain present across different kinds of work while preserving one coherent relationship with the user. Conversation is the main interface, but the system behind that conversation can maintain state, retrieve relevant evidence, follow a project, and record what actually happened.

I do not view ANNIE as a character placed on top of disconnected utilities. The identity of the assistant comes from continuity. It should remember prior work, understand its current limits, distinguish a plan from an executed result, and communicate uncertainty naturally. That requires the surrounding runtime to be as important as the model itself.

From Chatbot to Runtime

A chatbot mainly waits for text and returns text. A runtime has to coordinate many forms of state and decide what the current request actually needs. Some turns should remain ordinary conversation. Others require memory retrieval, research, file inspection, a project plan, a controlled tool, or a longer-running process.

ANNIE V4 separates the visible conversation from the machinery supporting it. The user should receive a direct answer instead of internal status text, raw tool output, or development labels. Background activity can still be recorded for inspection, but it should not take over an unrelated conversation. This sounds like a small distinction, yet it is central to making a complex assistant feel coherent.

The same principle applies to failure. If something breaks, the useful response is not a wall of internal records. ANNIE should explain what the failure means, how it affects the requested task, and what the next reasonable action is. Turning system state into human meaning is one of the core design goals of V4.

Memory Beyond Chat History

Long-term memory is one of the foundations of the project. ANNIE needs to remember personal preferences, decisions, ongoing goals, project context, corrections, failed approaches, and useful lessons without treating every old detail as equally important.

The system therefore treats memory as a selection problem. A current question should retrieve the right part of the past, not simply paste a large conversation archive into the model. Personal history, project knowledge, recent messages, visual material, and learned constraints have different roles. ANNIE must choose the relevant layer and keep unrelated memories from contaminating the answer.

Continuity also has to survive technical interruptions. A long task should not become fictional because a process restarted or a browser disconnected. V4 records completed work and durable task state outside the model's temporary context. The model receives a bounded working view, while the larger system preserves the committed history needed to continue honestly.

Research as a Continuing Process

ANNIE's research direction goes beyond returning search results. The larger goal is to preserve the path from a question to evidence, from evidence to a hypothesis, and from a hypothesis to an experiment that can be evaluated. A useful research system should remember what was already tried, where an idea came from, what contradicted it, and whether a result was actually measured.

V4 contains research pipelines for gathering sources, organizing papers and notes, proposing testable questions, and connecting research findings with practical experiments. It also maintains a research memory layer intended to preserve relationships among ideas, prior attempts, benchmarks, failures, and successful patterns.

This is important because generated novelty is easy to mistake for discovery. A language model can produce an interesting idea without proving that the idea is new, correct, or useful. ANNIE's research systems are moving toward a stricter standard where a promising output becomes a candidate for testing, not an automatic conclusion.

ANNIX and Durable Project Work

ANNIX is the project-work side of ANNIE V4. It is designed to let the assistant understand a selected project, keep project-specific memory, plan work, inspect relevant files, and continue through multiple stages without losing the original objective.

For software work, the intended flow includes understanding the repository, planning a narrow change, previewing the effect, validating it in isolation, preserving rollback information, and reporting the result with evidence. The same project framework is expanding toward research, documents, creative workflows, and administrative work where the output is more than a chat response.

Resumability matters here. Complex work rarely fits inside one perfect interaction. ANNIX is being built to preserve milestones, progress, open questions, validation results, and the next safe action so a project can continue after context pressure or interruption. The long-term goal is for ANNIE to follow the work itself, not merely remember that a conversation happened.

Tools Without Uncontrolled Autonomy

ANNIE can work with research tools, local files, code analysis, documents, images, project environments, and selected external systems. The important design question is not how many tools can be attached. It is whether the system knows when a tool is necessary, what authority it has, and how to prove the outcome.

Read-only inspection, planning, simulation, approval, execution, and verification are treated as different stages. A proposed action is not an executed action. A successful command is not proof that the user's objective was achieved. High-impact operations should remain behind explicit policy and approval boundaries, with isolated testing and rollback evidence where appropriate.

This makes ANNIE slower to grant itself authority, which is intentional. I am more interested in dependable agency than demonstrations that look autonomous for a few minutes. A capable system should be able to explain what it intends to do, operate within a known scope, and verify the resulting state before it claims success.

Voice as the Same Assistant

Speech is another major part of ANNIE V4. I want voice interaction to feel like access to the same memory and reasoning system, not a separate lightweight assistant with canned responses or a smaller version of the truth.

Spoken turns return to the same conversation path used by text. The final answer is checked and sanitized before speech generation, and interruption controls allow the user to stop playback naturally. Faster voice interactions can use a smaller working context, while deeper questions retain access to the fuller reasoning and memory path.

The direction is a responsive local voice loop that remains honest about what the system knows and what it has done. Speed matters, but it cannot come from inventing an answer before the real model has produced one.

Learning From Failure

One of the most ambitious parts of V4 is its improvement spine. The idea is to make failures useful. A wrong route, weak memory choice, incomplete answer, failed tool call, poor project result, or broken assumption should become structured evidence that the system can study later.

The intended sequence is deliberate. Observe the failure, understand it, preserve the lesson, turn it into an evaluation, propose a small repair, test that repair in isolation, review the evidence, and only then consider a controlled change. After any accepted change, the system should monitor whether the result actually improved the original behavior.

This is different from asking a model to rewrite itself freely. ANNIE's improvement work is designed around gates, comparisons, sandboxes, regression checks, approval, rollback planning, and measured impact. Many of these systems remain experimental, but the direction is clear. Improvement should be earned through evidence rather than declared by the model that proposed it.

What RSI Means in ANNIE V4

Recursive self-improvement, or RSI, is one of ANNIE V4's central research directions. I use that term carefully. It does not mean giving a model unrestricted permission to rewrite itself and trusting whatever comes next. In ANNIE, RSI means building a closed evidence loop where the system can identify a weakness, study it, propose a bounded improvement, test that proposal, and retain it only when the result is demonstrably better.

The RSI path has several distinct lanes. Reactive repair begins with a real failure and tries to prevent it from happening again. Proactive improvement looks for missing capabilities or weak areas before they become visible failures. Capability maturation takes an early idea through clearer requirements, evaluation, and repeated testing. Promotion controls whether a proven candidate is allowed to affect the working system. Impact learning then asks whether the accepted change actually helped during later use.

ANNIE's research systems support this direction by turning observations into hypotheses, hypotheses into experiments, and promising research into small prototypes that can be measured. Candidate approaches can be compared against a baseline instead of judged by how convincing their descriptions sound. Memory strategies, routing decisions, tool use, project workflows, and new capabilities can all become subjects of controlled improvement.

The recursive part comes from using the evidence produced by one cycle to improve the quality of the next cycle. Better failure detection should create better evaluations. Better evaluations should produce more focused repair candidates. Better experiments should make promotion decisions more reliable. Measured outcomes should help the system choose more useful future work. The goal is compounding improvement, not an endless stream of generated architecture.

Verification, feedback, efficiency, and real-world impact all matter. A candidate that passes a narrow test but makes the larger system slower, less reliable, harder to control, or worse for the user should not count as progress. ANNIE's RSI direction is built around retaining useful gains while rejecting changes that only appear impressive in isolation.

The honest current boundary is that ANNIE V4 has substantial RSI infrastructure and several parts of the improvement chain have been exercised, but it is not a proven self-improving general intelligence. Many advanced lanes remain guarded, sandboxed, shadow-tested, or dependent on stronger end-to-end evidence. The project direction is to prove that ANNIE can repeatedly produce small, useful, measurable improvements without bypassing human control or losing the behavior that already works.

Evidence and Reality Checks

Large AI systems can accumulate impressive architecture while still failing at ordinary tasks. ANNIE V4 includes several reality-checking layers because source code, configuration, and a passing isolated test do not automatically prove that a live user workflow works.

The project tracks whether an answer used the right memory, whether a requested handler actually ran, whether a claim has supporting evidence, whether a task survived interruption, and whether a proposed improvement produced a measurable result. Internal dashboards are intended to distinguish what is active, what is blocked, what needs approval, and what remains unverified.

This focus on evidence is also why I avoid describing ANNIE as fully autonomous. Some systems are active foundations, some are guarded tools, some run only as experiments, and some represent future direction. Keeping those categories separate makes the project more credible and gives development a clearer next step.

Practical Use Cases

The first use case is long-term project collaboration. ANNIE can hold the context surrounding a codebase, research effort, product idea, or operating plan and help continue the work without rebuilding the entire history every time.

The second is private research. A local-first system can collect questions, sources, notes, hypotheses, and experimental results while preserving the reasoning history around them. That makes it useful for technical investigation, product research, AI experiments, and other work where the process matters as much as the final answer.

The third is controlled computer work. ANNIE is being developed to inspect projects, prepare changes, run bounded validations, create artifacts, and coordinate selected tools or environments while keeping consequential operations gated.

The fourth is everyday continuity. A persistent assistant should be able to remember preferences, prior decisions, unfinished questions, and the state of ongoing work. That is less dramatic than autonomous demos, but it is one of the capabilities that would make a personal AI system genuinely useful over years.

What I Am Deliberately Not Building

I do not want ANNIE to produce canned personality responses and call that memory. I do not want background processes to interrupt normal conversation with unrelated status. I do not want plans to be presented as completed work, or internal confidence to substitute for external evidence.

I also do not want unrestricted action simply because an agent can call a tool. The system should not silently send messages, publish work, modify important projects, activate new capabilities, or perform external actions without the required authority and verification.

These constraints are part of the product, not temporary obstacles around it. The challenge is to create an assistant that can become more capable while remaining understandable and correctable by the person using it.

Current Limits

ANNIE V4 is a large experimental codebase, and complexity is one of its main risks. A system with many specialized paths can become difficult to reason about, difficult to test end to end, and too eager to add another subsystem when the real need is to strengthen an existing one.

The project is therefore moving toward consolidation and proof. Important paths need repeated live use, clearer ownership, fewer overlapping responsibilities, and better measurements of whether they help the user. Some advanced research and improvement systems are intentionally kept in read-only, shadow, sandboxed, or disabled states until their value and safety are demonstrated.

Local operation also creates practical constraints around compute, model quality, latency, storage, and maintenance. The architecture has to adapt to the hardware available without pretending that every local model can perform every role equally well.

The Project Direction

The immediate direction is reliability. ANNIE should answer the current user clearly, retrieve the right memory, preserve completed work, and tell the truth about what happened. Those basic contracts matter more than adding another impressive label.

The next direction is deeper project execution. ANNIX is intended to carry a task from initial understanding through planning, work, validation, repair, and final delivery while preserving enough state to resume safely. Over time, that framework can support software, research, media, documents, operations, and other structured work.

Research is another major lane. I want ANNIE to move from finding information toward building testable hypotheses, running bounded experiments, remembering failed approaches, and translating useful research into measured prototypes. The system should become better at forming the right problem, not only answering the question it was given.

The longer-term improvement direction is evidence-backed RSI. ANNIE should be able to notice recurring weaknesses, create evaluations, compare candidate solutions, and retain changes only when they produce verified positive impact. That is a much harder goal than generating code, but it is the path toward a system that can improve without losing accountability.

Ultimately, I see ANNIE as a private AI infrastructure layer that can support a person's work for a long period of time. It should connect conversation, memory, research, projects, tools, voice, and learning while keeping the human operator in control of consequential decisions.

The Long View

ANNIE V4 is not finished, and I do not expect this kind of project to have a simple finish line. The models will change, the tools will change, and the useful boundary between assistance and agency will keep moving. The durable part is the architecture around trust, continuity, evidence, and control.

My goal is to build an assistant that becomes more useful because it understands the history of the work, not because it pretends to know everything. It should be able to think with me, research with me, help operate projects, and improve from real outcomes while remaining honest about its limits.

That is what ANNIE V4 represents today. It is a serious attempt to build the connective system around local AI so that a model can become a persistent collaborator rather than a temporary answer box.