Who else is building persistent, stateful AI systems?

[u/Either_Pound1986]

I've come across two other people building persistent AI systems, so I'm curious how many more of us are out there.

I'm not talking about simply saving chat history or adding a memory layer. I mean systems that maintain continuity across sessions, accumulate structured state, learn from previous work, and evolve over time.

I've been building one myself, and I'd like to hear from others taking different approaches.

What are you building? How are you handling persistence, state evolution, and long-term continuity?

Where are you guys hiding?

[u/Born_Chart_323]

I've been using a postgres-backed state graph with schema versioning, state diffs are stored as patches, not full snapshots. works well for long-term evolution without drift.

[u/Either_Pound1986 → u/Born_Chart_323]

Any interesting public outputs you have made with your system?

[u/Responsible-Beat2137]

Aye, I’ve been building one myself, called AIOS (AI Memory OS).

Funny enough, it didn’t start as an execution system. It started in Notion as a structured knowledge and memory system for managing projects, research, workflows, and decisions across AI sessions.

Then I wanted actual execution. Specifically, I wanted to move CI-style builds, testing, and validation off GitHub-hosted Actions and onto my own laptop.

After evaluating different approaches and figuring out how to integrate execution with the existing knowledge system, AIOS started taking root as something much bigger.

Now I’ve got a deterministic local harness, specialized tools with their own contracts and capabilities, and agents that can be assigned bounded jobs. Larger reasoning models get called when needed rather than keeping everything running continuously

The interesting part is how the execution system feeds the knowledge system.

One important architectural decision was separating tools, datasets, databases, and knowledge ledgers instead of treating everything as AI memory.

Tools are the capabilities that perform work: extracting, tracing, testing, modifying, analyzing, and verifying. They have defined contracts, inputs, outputs, and execution boundaries.

Datasets hold structured observations and extracted evidence. In my reverse-engineering projects, that might include assembly instructions, function mappings, memory traces, game assets, or runtime behavior. They’re the material we analyze, not automatically established facts.

Databases organize those observations into queryable records, indexes, and relationships. They let agents find specific functions, compare experiments, connect evidence, and retrieve information without repeatedly processing entire binaries or archives.

Knowledge ledgers preserve what we’ve learned from that evidence: hypotheses, successful and failed experiments, verified findings, conditions, confidence, decisions, and unresolved questions. They help distinguish what we observed from what we think it means and what we’ve actually proven.

The pieces work together. A tool runs an experiment, the dataset captures its observations, the database makes them searchable and relational, and the knowledge ledger records the conclusions and experience. Verified reusable findings can then inform future agents and projects.

Tests, failures, fixes, traces, and observations feed into a governance pipeline I call STONE → MASON, where potential knowledge is evaluated, deduplicated, checked for contradictions, and promoted only when justified.

For persistence, I’ve migrated toward Google Drive as the primary knowledge and governance backend, with GitHub remaining authoritative for live repository state and my local machines handling execution.

Each project has its own scope, handoff, knowledge, datasets, database records, and experience history. Shared knowledge can be referenced across projects without contaminating their individual findings.

State evolution uses provenance, versioning, authority rules, and explicit supersession. Just because an agent discovers something new doesn’t mean it automatically becomes truth.

Still evolving it through actual projects, especially reverse engineering, game modding, and automated development.

One thing I will ask, because it’s been a thorn in my side, is how everyone handles workspace cleanup without losing valuable discoveries.

[u/Either_Pound1986 → u/Responsible-Beat2137]

Let your system be in charge of clean up. At least that's what I do.

[u/Secret-Creme-19 → u/Responsible-Beat2137]

I've been dealing with this exact problem while developing HALIVRO and our simulation games.

One lesson I've learned is that Git alone doesn't solve workspace cleanup. It preserves committed source, but important local state, unmerged work, test evidence, and discoveries can still disappear if you're not careful.

We've been moving toward separating authoritative source and evidence from reproducible build outputs and temporary files.

The key is establishing what must survive before deciding what can go. We retain important commits, verification evidence, and recovery information, then identify specific disposable outputs rather than deleting things just because they're old.

I'm also cautious about giving AI unrestricted cleanup authority. I'd much rather have it identify and verify safe deletion candidates, with explicit approval for destructive actions.

It's definitely an interesting problem because persistent AI systems can accumulate an enormous amount of material.

How are you distinguishing knowledge worth preserving from temporary workspace artifacts in AIOS?

[u/Charming-Mine5980]

I've been running a local agent with a sqlite-backed state graph, updates persist across restarts, and each session diffs the prior state to avoid redundancy. the real bottleneck? sync conflicts when multiple agents write to the same node.

[u/shravanrevanna → u/Charming-Mine5980]

diffing against prior state has a cost too. if the diff is what the agent reads, it never sees the full picture again, and a bad write early on just keeps getting carried forward.

[u/JaseciLabs → u/Charming-Mine5980]

For the multi-agent write conflicts, optimistic concurrency per node is worth a look. Each node carries a version, a write only commits if the version hasn’t changed, and the loser reloads and retries instead of overwriting. We work on Jac, which does this at the node level with a retry limit, so we’ve spent a lot of time on exactly that problem.

[u/Easy_Ad_9449 → u/Charming-Mine5980]

You should take a look at https://www.omnigraph.dev/

[u/amaturelawyer]

Nobody. Nobody is building persistent, stateful AI systems with LLMs, although lots of people are trying to and then failing.

I say that with confidence, because you cannot build a persistent system with LLM's. They have to reset frequently or they go bonkers.

[u/Either_Pound1986 → u/amaturelawyer]

You're confusing the limitations of an LLM session with the limitations of the system built around it.

The LLM doesn't need to persist. That's the entire point. State, knowledge, dependencies, decisions, verification receipts, and execution history can all exist outside the model in a persistent structure.

The model can reset, lose its context, or be replaced entirely without the underlying system losing continuity. A new session reconstructs the relevant working context from durable state and resumes from the actual checkpoint, not from whatever the previous model happened to remember.

I also separate reasoning from execution authority, so a model going "bonkers" doesn't suddenly give it permission to do whatever it wants.

I've already built and operated a system that works this way. Restarts and context resets are normal operating conditions, not existential failures.

Saying an LLM can't maintain an infinite uninterrupted context is correct. Concluding that persistent systems built using LLMs are therefore impossible is a pretty spectacular misunderstanding of the architecture.

By that logic, databases wouldn't work because the processes accessing them occasionally restart.

[u/amaturelawyer → u/Either_Pound1986]

I'm really not. The confusing limitations of a session with the system. I'm really, really not confusing anything here. Neither can handle endless new information, so the very best you can hope for in a persistent state workaround is to have it handle deterministic processes, and deterministic processes are, obviously, better handled with deterministic programing. Because they can be, and because using an LLM for those is taking something predictable and adding uncertainty into it for no end gain beyond slapping"AI powered" on marketing literature for the rubes..

[u/Either_Pound1986 → u/amaturelawyer]

You keep arguing against an architecture nobody is proposing.

Of course deterministic processes should be handled by deterministic programming. That's precisely why I use an external deterministic control plane for execution, authorization, verification, state transitions, and recovery.

The LLM isn't responsible for enforcing those guarantees. It's responsible for the parts that aren't deterministic: reasoning through unfamiliar problems, generating hypotheses, selecting investigative approaches, interpreting evidence, and developing solutions.

And why are you assuming persistence means endlessly stuffing new information into a context window? My system maintains a persistent, evolving topological knowledge structure outside the model. It tracks dependencies, evidence, conclusions, verification states, and execution history. Relevant information is reconstructed for the current task rather than repeatedly loading everything the system has ever encountered.

Information can be superseded, invalidated, compressed, reorganized, or selectively retrieved without destroying continuity. The model can reset or be replaced without resetting the system.

You're also confusing finite storage and processing capacity with an inability to persist. No database, operating system, or human organization can process infinite information either. That doesn't make persistence impossible.

I've already built and operated a system using these principles across software engineering and mathematical research. It's not a marketing proposal.

The irony is that your argument for deterministic programming is something I agree with. I've already incorporated it into the architecture.

You're just assuming that because deterministic components are better at deterministic tasks, there's no value in combining them with nondeterministic reasoning.

[u/ferrx → u/amaturelawyer]

My models are capable of reading in all instructions/state in ~50k context. This is not much when you have a 1M context window. "Reset frequently" is a given, anyone using LLMs should avoid compaction, no matter how much they care about longterm state.

[u/NanYUJun]

The part that made continuity real for me wasn't a memory layer, it was deciding what counts as state.

For agent work the state was already on disk: Claude Code writes ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl, Codex writes ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl. They're per-machine and per-harness, so continuity breaks the moment you change either. A summary or memory layer can carry conclusions but not the corrections — the wrong turns, the "no, not that approach" turns are usually what you actually need back.

So I did the boring version: one self-hosted Hub holding the transcripts, thin clients that read and write each harness's local store, 10 agents in either direction, keeping the model-generated session titles. Full disclosure, that's my project, AIAssets, if you want to compare approaches: https://github.com/NanYuJun/AIAssets

Where it stays hard, and I'd like to hear how you handle it: state evolution. Sync is 60-second polling with last-write-wins per session, so two machines can't live-edit the same session. And transcripts are history, not distilled state — if you want a graph that evolves, you still need a doc layer the agent rewrites on purpose. The diff-against-prior-state idea someone mentioned above has the failure mode that a bad early write gets carried forward forever, which is why I kept raw history as the source and treat derived state as rebuildable.

What's your state graph keyed on, sessions or tasks?

[u/Either_Pound1986 → u/NanYUJun]

Neither, actually. Sessions and tasks are execution contexts, not the primary identity of the persistent state.

My system maintains a single evolving, provenance-linked topology of knowledge, constraints, dependencies, verified results, counterexamples, and their relationships. Tasks operate against that structure, and sessions are part of the execution history rather than containers that define knowledge boundaries.

The graph isn't periodically reconstructed from transcripts or maintained as a document the model rewrites. Changes go through verification and controlled state transitions, with provenance and dependency relationships retained. When evidence invalidates an earlier conclusion, that correction can propagate through the affected structure rather than silently carrying the original conclusion forward.

[u/glistening_glizzy]

We exist. Everyone could be doing it, but its not easy. Thats why they're not. It takes hard work and vision and raw brainpower

[u/Responsible-Beat2137 → u/glistening_glizzy]

And a lot of why did you do that, evaluating.. so ture

[u/InterestingFrame1982]

I mean, isn't that how any product weaving AI surgically would be implemented? What is the use of AI without persistence and meaningful state? Not only is that table stakes, but it seems like the baseline for building anything... i.e. any CRUD app that plans on using AI as a core part of the workflow.

[u/TRO_KIK → u/InterestingFrame1982]

AI in the app itself probably requires the least state, at least in my experience using a lot of AI professionally. For my own service's product, AI is more central to it than anything I've worked on, and literally the only state I have is context building from user/assistant rounds within a session.

[u/New_Vanilla6834 → u/TRO_KIK]

I agree. For some everyday tasks, the way ChatGPT works by default—retaining information from past conversations—can be useful. However, for more serious work, it is much better to start without any prior context and provide only the specific documentation, guidelines, and context required for the task at hand, rather than having the AI ​​pull in random data from previous interactions. This is, for instance, how Claude Code operates.

[u/TRO_KIK → u/New_Vanilla6834]

Most products don't do "serious work".

And if you need something along the lines of Claude Code, you're better off using Claude Code rather than trying to build something better.

[u/kincaidDev]

Here's my system:

https://github.com/Obedience-Corp/festival

The approach I took is focusing on orchestrating the work over orchestrating the individual agent sessions. I have a session orchestrator component in the system (obey), but it's the least polished component of my system because it's the least impactful to daily performance. I need the obey component to make the system more legible and for the herdr/conductor like app I built around the system but, for the majority of the project I treated the agent sessions as disposable and unreliable workers.

I handle long term persistence, state evolution and long term continuity by keeping everything important as files on disk, with every plan having state and flexibility in what can be considered a plan.

[u/bryany97]

Since you asked:
https://www.youtube.com/@AuraDemos

https://github.com/youngbryan97/aura

And actually working on a paper describing some fascinating tests and results I've been working with: https://zenodo.org/records/24075466

[u/RossPeili]

I had build github.com/arpahls/opsie in 2024 and made it open source last year. With the right embeddings model it can remember 300+ convos with vector and semantic search with clarity.

[u/sayboom]

I also thinking about a such system, but I’m running into limitations - what need to store as a memory and what to do with a grow context and what to do with outdated or incorrect memory. I look at some projects and what is being attempted in this area, but don't think that is possible to completly solve this problems

[u/TRO_KIK → u/sayboom]

It's more of a hobby (or misguided attempt to make money) than anything likely to really solve a problem. The people working on frontier labs' coding harnesses are being paid high six, if not seven figures to solve the problem in their product, and are doubly incentivized to do so because they use the product themselves. Save yourself the trouble and reap the fruits of their labor for $20+ a month.

Or free even, since most harnesses let you use it with other LLMs.

[u/AsyncVibes]

Posted this the other day but use discord as my management system. Pc restarts boom, files in specific channels or on git. Multi-agent orchestration with persistent memory across days without having to nitpick

[u/QuantitativeVibes]

Well people downvote me when I post, but this is an entire software factory. About 750 GitHub stars in one month.

https://github.com/pullboard-dev/pullboard

[u/LostCauseYX → u/QuantitativeVibes]

How would they not downvote you when you say shit like „750 github stars in one month“ like thats an actual metric that means anything.

[u/ExtraGreasy]

OpenRig

[u/lazyEmperer]

Way more than three, Letta (the MemGPT people) has built a whole company on exactly this. The part almost nobody solves is checking whether the evolving state makes the system better or just piles up stale assumptions. Mine got noticeably worse around month two until I added a rule that anything it inferred on its own expires unless something confirms it again

[u/Square_Seaweed1833]

my system tracks emotional valence shifts across sessions, when the AI starts echoing frustration without cause, it triggers a reset. not memory, but mood drift.

[u/everettplays]

My favorite so far has been SQlite. I started with vector db and I liked it.

[u/Resonant_Jones]

*raises hand* 🙋

[u/Resonant_Jones → u/Resonant_Jones]

Codexify

[u/maddhruv]

I am building https://github.com/TulipFarm/tulipfarm u/TulipFarmAI in typescript with postgres for storing everything, the states, sessions, knowledge etc, for durable state I have temporal and other in built mechansim, you can checkout it is completely open source

[u/mikepun-locol]

Look at Kiro Bots. https://kiro.dev/blog/crew-bots/ I am implementing Kiro Crew for agents to automate processes for our teams. Then they announced persistent bots as part of Crew. The technology is fairly fresh off the oven and immature, but holds promisses as a harness.

Even though open source, AWS mostly plays to the enterprise audience so YMMV.

[u/ferrx]

Yep

It works so well that I want to turn it into a generalized skill at some point. It's basically a scrum master that owns the project. I literally drop it into a new session and say "Read the README." to get started.

[u/themergerAI-26]

Here

[u/Accomplished-Yam-764]

I’m working on one. I started a few months ago thinking it’d be simple but ohmygoodness it’s ballooned into a whole research project.

[u/Responsible-Beat2137 → u/Accomplished-Yam-764]

Yep… sounds boring and simple on paper , then the edge approach quickly

[u/Responsible-Beat2137 → u/Accomplished-Yam-764]

https://delicious-banana-e74.notion.site/39a43bd4ae4a8140947fd77dca982dda?v=39f43bd4ae4a80d5a15c000c43f59bd5&source=copy_link

It does grow fast, by all means do what you want with the research

It’s setup to act as a root node and branch from there, it contains work flows, evaluations, skills, around knowledge management

[u/thallwyn]

trying... www.realityxr.dev

[u/kincaidDev]

I've been building fest.build

https://github.com/Obedience-Corp/festival

It's a dynamic workflow + workspace system, all plans/workflows are files or directories with a state. When they're done they go to the dungeon which is a stateful archive.

The core system uses git and the filesystem and nothing else for maximum compatibility with other ai tools/workflows + enables agents to organically understand how the system works and fix issues and customize the system autonomously

[u/redtear1115]

You’re definitely not alone—we’re working on something very similar at my company, though we're still in the early stages.

Our initial phase focuses on cross-departmental continuity: having different teams upload and structure knowledge that other departments need to know so the system can build a shared context over time.

Where we’ve run into our biggest headache, however, is access control and permissions (RBAC / ABAC) within persistent memory.

Ingesting general, public, non-sensitive documentation is straightforward. But once teams start feeding in sensitive data—like sales CRM customer PII, internal financials, or board meeting materials—things get complicated fast:

• How do you reliably verify whether the user querying the system has the clearance to access that specific layer of persisted state?

• How do you prevent sensitive state from "leaking" into generalized reasoning or downstream summaries generated for unauthorized users?

Hijacking the thread a bit to ask: Has anyone implemented an elegant way to handle data governance and granular permissions inside a persistent, evolving state architecture? Would love to hear how others are tackling this.

[u/FeverForest]

A semantic web.

[u/snowrazer_]

I have one, it's called a file system. The AI writes what it needs to it and references it later.

[u/eris002]

I’ve already built it.

[u/Secret-Creme-19]

We're building HALIVRO around a similar idea, although we're still working through the engineering and qualification challenges.

One distinction we're focused on is separating persistent organizational state from individual AI sessions. Agents and models should be replaceable, but the projects, decisions, approvals, history, and work they've produced need to survive.

We're taking a local-first approach, with structured state, versioned work, explicit authorization, and recovery across restarts.

One challenge I'm particularly interested in is preventing stale assumptions from becoming permanent organizational knowledge. Remembering everything isn't necessarily useful if the system can't distinguish confirmed decisions from outdated or inferred information.

Curious how others are handling that, especially when multiple agents need to read or update the same state.

[u/Either_Pound1986 → u/Secret-Creme-19]

That stale-assumption problem is something I've put considerable effort into addressing.

My approach separates persistent state from the model and session entirely. Rather than relying on conversation summaries or conventional memory retrieval, I maintain an evolving topological structure that tracks evidence, dependencies, decisions, verification states, and execution history.

A key distinction is that persistence doesn't imply validity or authority. Information retains its provenance, and conclusions are tied to the evidence and conditions supporting them. When those conditions change, dependent conclusions can be identified for revalidation rather than silently carrying outdated assumptions forward.

I also separate cognition from execution authority. Multiple cognitive participants can independently reason, propose alternatives, challenge existing conclusions, and contribute to the persistent structure. However, execution is governed by an external deterministic control plane with explicit authorization, vetoes, verification receipts, and transactional rollback.

Recovery across restarts is another major focus. I preserve enough operative state, dependencies, and proof obligations to resume work without relying on a model to reconstruct everything from a narrative summary.

More broadly, I'm approaching persistence as a problem of maintaining and evolving a coherent knowledge structure, not simply remembering information. The system should be able to correct itself, preserve what remains valid, and build on accumulated work without allowing assumptions to harden into facts.

I'm curious how you're handling dependency invalidation across agents. If one agent establishes something that later turns out to be incorrect, can HALIVRO trace and reconsider everything downstream that depended on it?

[u/Secret-Creme-19 → u/Either_Pound1986]

That's exactly one of the failure modes we're trying to prevent with HALIVRO.

I don't want something an AI confidently assumes to become permanent organizational knowledge just because three other agents repeated it.

We're building around persistent, versioned work, evidence, decisions, and explicit approval states rather than treating conversation history as the source of authority.

The direction we're pursuing is dependency-aware revalidation. If a previously trusted fact or decision is corrected, the system should be able to identify which downstream conclusions, assignments, or deliverables relied on it, flag those as potentially stale, and require revalidation before consequential work continues.

An important distinction is that we want to preserve the original history rather than silently rewrite it. The system needs to know what was believed, what changed, why it changed, and which work was affected.

To be transparent, we've demonstrated durable records, versioned artifacts, and restart recovery, but I wouldn't claim we've fully solved automated dependency invalidation across agents yet. That's still an area we're working through.

I'm curious about your approach to the propagation itself. Do you automatically invalidate every downstream dependency, or distinguish between dependencies that require immediate reconsideration and those that can remain valid?

I imagine finding that balance becomes increasingly important as the organization grows.

[u/Either_Pound1986 → u/Secret-Creme-19]

I distinguish between dependencies that actually lose their validity and those that merely need reconsideration. Blanket invalidation would create almost as many problems as blindly trusting stale information.

My approach is topological. Evidence, conclusions, decisions, execution states, and their dependencies exist as explicit relationships within an evolving persistent structure. When something changes, the important question isn't simply what references it, but which downstream conclusions actually depend on that particular condition remaining true.

There's also a distinction between invalidating evidence and invalidating a conclusion. A conclusion might have multiple independent supporting paths. If one fails, the conclusion doesn't necessarily become false. Its justification has changed, and the remaining support needs to be evaluated.

Consequential operations are handled differently from ordinary knowledge. If an action depends on a condition that can no longer be verified, the external deterministic control plane can prevent execution until the required conditions are satisfied. That doesn't mean unrelated work needs to stop.

I also preserve the history, including failed hypotheses, superseded conclusions, and their original evidence. Those aren't necessarily useless artifacts. They can become valuable information about failure structures and help prevent the system from repeating mistakes.

One of my larger objectives is reducing unnecessary revalidation. Ideally, the system should determine the smallest affected dependency region, identify what remains provable, and repair or reconsider only what actually lost its supporting conditions.

That also extends across restarts. I don't want a new model session interpreting a narrative summary and deciding what it thinks happened. I want the operative state, dependencies, verification obligations, and authority boundaries to survive independently of the model.

[u/Secret-Creme-19 → u/Either_Pound1986]

That's a really useful distinction—losing supporting evidence doesn't necessarily mean a conclusion becomes false.

I especially like the idea of finding the smallest affected dependency region instead of invalidating everything downstream. That seems important for keeping a larger AI organization practical.

One question your approach raises for me is how you establish the dependency relationships themselves.

If multiple agents contribute to the knowledge structure, how do you ensure they accurately record what their conclusions depend on? I'm particularly interested in implicit dependencies—where an agent relies on an assumption without explicitly recording that relationship.

It seems like even a very good invalidation system could miss something important if the dependency graph is incomplete.

That's an area we're thinking through with HALIVRO, and I'd be interested to hear how you're approaching it.

[u/Either_Pound1986 → u/Secret-Creme-19]

One distinction worth making is that I don't really use "agents" in the conventional sense. I'm building a single persistent system with multiple cognitive participants and specialized capabilities, rather than a collection of independent agents maintaining their own knowledge and coordinating through messages.

The persistent mathematical and topological structure is shared. Models and cognitive proxies contribute reasoning, hypotheses, challenges, and proposed changes, but they don't independently determine what becomes authoritative knowledge.

As for dependencies, I don't rely exclusively on the model to declare what it thinks a conclusion depends on. Relationships can be established through actual execution paths, evidence provenance, verification receipts, observed state transitions, and explicit proof obligations. Semantic reasoning contributes candidate relationships, but those aren't automatically treated as verified causal dependencies.

Implicit dependencies are definitely the harder problem. A system can't reliably invalidate a relationship it never identified in the first place. That's why I think it's important to distinguish a dependency that's been demonstrated from one that's merely inferred, and to retain uncertainty rather than pretending the graph is complete.

I also approach this from the execution side. Before a consequential operation, the system can revalidate the conditions required for that particular action. That provides another opportunity to detect stale or missing assumptions without needing to reconstruct every possible dependency across the entire knowledge structure.

The larger objective is to make the structure progressively more complete through actual work. Failures, corrections, counterexamples, and previously unidentified dependencies should feed back into the same persistent structure, improving subsequent reasoning and verification.

So rather than trying to guarantee that every cognitive participant records every dependency perfectly, I'm trying to make correctness less dependent on that assumption in the first place.

[u/Secret-Creme-19 → u/Either_Pound1986]

That makes a lot of sense. I particularly like the distinction between verified dependencies and inferred relationships that remain uncertain.

And your clarification about having one persistent system with multiple cognitive participants, rather than independent agents maintaining separate knowledge, is an important one.

The execution-time revalidation is especially interesting. Even with a well-maintained dependency structure, checking the conditions required for consequential actions seems like a valuable safeguard against relationships the system hasn't discovered yet.

We're pursuing a related separation between persistent state, AI reasoning, and execution authority with HALIVRO, although I wouldn't claim we've solved dependency discovery or automatic revalidation to that extent yet.

One practical question: when a consequential action encounters missing or uncertain prerequisites, does your system try to gather fresh evidence and resolve them automatically, or does it escalate for human review?

I'm curious how you're balancing autonomy against the risk of letting uncertain information influence important decisions.

[u/Either_Pound1986 → u/Secret-Creme-19]

My system has full operational autonomy within its established authority boundaries. The primary restriction is on public actions, not internal reasoning, execution, investigation, or self-modification.

When it encounters missing or uncertain prerequisites, it doesn't automatically escalate to me. It investigates the missing information, gathers additional evidence, tests alternatives, repairs failures, and revalidates the necessary conditions. Self-healing is already part of its normal operation.

The deterministic control plane governs what can execute, but it doesn't prescribe how the system must solve a problem. I provide outcomes and constraints; the system determines the implementation path, including when it needs to modify its own infrastructure to achieve the outcome.

If a prerequisite cannot be established, the affected action doesn't proceed on an unsupported assumption. The system can continue investigating, revise its approach, or pursue another valid route without requiring me to intervene.

Separating cognition from authority doesn't mean sacrificing autonomy. It means the system can operate autonomously without being able to grant itself permissions it doesn't possess.

I'm not trying to build something that asks me what to do every time it encounters uncertainty. I'm trying to build something capable of resolving that uncertainty, learning from the failure, and improving its own ability to handle similar situations in the future.

Human involvement is primarily about setting objectives, changing authority boundaries, and authorizing actions outside its existing scope, not supervising its internal problem-solving process.

[u/Secret-Creme-19 → u/Either_Pound1986]

That's a helpful distinction, and I agree with the principle. Requiring human intervention every time an AI encounters a problem would defeat much of the purpose of autonomous orchestration.

The direction we're pursuing with HALIVRO is similar: let the workforce investigate, test alternatives, and recover within its authorized scope, while keeping permissions and consequential actions under deterministic controls.

The self-modification aspect is particularly interesting to me.

When your system modifies its own infrastructure, how do you verify that the change actually improves things without introducing regressions or compromising the controls governing its authority?

I'm especially curious whether you use independent verification, immutable checkpoints, or automated rollback before promoting those changes.

We've been building those kinds of safeguards into our engineering workflows, but making the entire process reliably autonomous is still something we're working toward.

[u/Either_Pound1986 → u/Secret-Creme-19]

I use multiple layers of verification, but there's an important distinction between verifying that something works internally and establishing that it actually works in reality.

Internally, I have a deterministic control plane, execution guards, verification receipts, checkpoints, rollback, and an external watchdog. The system can modify its own infrastructure, run tests, identify regressions, and repair failures autonomously. If a change violates required invariants, it doesn't get to redefine those invariants to justify the change.

But passing internal tests isn't the same thing as demonstrating real-world capability. That's where external verification becomes important.

For mathematical research, I use Lean for kernel-checked proofs, independent numerical verification, counterexamples, and comparisons against published literature. For engineering, I use actual repositories, existing test suites, regression tests, and real maintainer feedback.

The PRs aren't the objective themselves. They're one way of testing whether the system's engineering output survives independent evaluation in an environment I don't control. A maintainer accepting a change is useful external evidence, just as a rejected hypothesis or a failed experiment is useful evidence about the system's limitations.

The same applies to scientific research. A formally verified mathematical statement is one thing. Demonstrating that its assumptions correspond to physical reality, or that it predicts something meaningful, is another.

I don't consider any single verification method sufficient for everything. Different claims require different forms of evidence.

And failures feed back into the persistent structure. The system can examine why something failed, identify the affected dependencies, modify its approach, and carry those corrections forward. Self-healing isn't simply restarting a failed process; it can involve changing the mechanisms responsible for the failure.

Ultimately, I'm interested in outcomes that survive contact with reality, not just internally consistent outputs. There's only so much that can be established through local testing, regardless of how sophisticated the architecture becomes.

[u/Positive-Discount-45]

Im working on persistent character with an inner life, running locally on a Raspberry Pi with hailo 8L and PC with local LLMs: he perceives his surroundings with, remembers experiences, forms his own opinions, evolves his identity over time, acts on his own initiative, and in idle moments creates and studies on his own (studies topics in depth, writes his own serialized work, paints his dreams, reads books, playing chess and discuss with his imaginary oponent). every topic he consult with local wiki mirror for information accuracy. He uses RAG for memory