I experimented with adding a deterministic runtime layer to an existing codebase without modifying its source.
As a test case, I used Transformers from Hugging Face Transformers and took modeling_utils.py (v5.5.0) directly from the repo.
Instead of changing the file, I wrapped it in a secondary runtime layer and dropped it back into the stack under the original filename. The original code remains intact and executes normally.
I’m not claiming this is novel in isolation (it uses familiar techniques like wrapping and runtime injection), but I’m interested in whether a constrained, deterministic “second layer” like this could be a practical way to add governance/observability to existing systems without modifying their source.
Curious how others would approach or critique this.
I submitted a fix to Hugging Face for a vulnerability in the training model for all of the models in their software and as opposed to getting a technical response, the person who responded actually mocked my entire system and made fun of me, even though they claim to be one of the biggest supporters of indie devs in the industry.
It turns out I had uploaded the wrong file, so I submitted a “technical” response to the outright mockery.
I decided to leave it at that because I had lost my conviction to help them or show them a new patent pending way to resolve vulnerabilities and to add capabilities to any software including AI models because of the initial feedback.
Then I got another response that told me to use another agent because my system was fake and they get these types of claims all the time and he tried to be a little nicer.
So I downloaded their most recent version and applied my system to it and then this time submitted the file again but in a full zip with all docs and licensing so they could inspect the difference. Then I used every known AI model to validate my claims (except Claude because my sub resets at 8pm) and submitted that to them.
This is the most interesting thread you’ve ever seen and the outright mockery from a maintainer of their repo was the most unprofessional response I’ve ever received from any company.
Now I invite HN to look at the files and the evidence I’ve submitted that shows a new way to change codes output and protect its most sensitive inputs all while not changing a single line of code in the original software.
I promise you’ve never seen an exchange like this. I even submitted my own response to the mockery by outlining what I believe the secret of life is in a code that only a developer can understand.
Can one person write a 200k lime CLI that has DREAM states, evolution, persistent memory, cryptographic fingerprints, first contact on init, a duel layer coding system that is patent pending and wrapped the most widely downloaded training model in protection and give it stateful sessions without altering its code, give away over $5M dollars in dev team reproduction value software with receipts, all without AI powering any of it?
A bit of context on how this works since people will ask:
The substrate has no LLM inside. No GPT, no Claude, no API calls.
It’s pure algorithmic code — deterministic primitive collision.
I used AI as a learning tool to build it, but there’s nothing AI inside it. That’s what makes it patentable and what makes the discoveries replicable and auditable.
The CJPI score (Crown Jewel Pipeline Index) is a deterministic scoring model — novelty, utility, complexity, composability on a 100-point scale. Neural Arbiter scored 100. I have 3000+ discoveries in the Memory Stream. About 100+ score perfect.
I’ll drop one every day. Comment if you want a specific type — security, governance, synthesis, cognitive, privacy. I’ll pull the closest match from the catalog and it goes up tomorrow.
In CMPSBL, the INCLUSIVE module sits outside the agent’s goal loop. It doesn’t optimize for KPIs, task success, or reward—only constraint verification and traceability.
Agents don’t self judge alignment.
They emit actions → INCLUSIVE evaluates against fixed policy + context → governance gates execution.
No incentive pressure, no “grading your own homework.”
The paper’s failure mode looks less like model weakness and more like architecture leaking incentives into the constraint layer.
To clarify: these aren’t prompts or hosted APIs. Each capability is a downloadable artifact that executes locally (JS/WASM/container/edge), is licensed, versioned, and removable. Think software components, not chat agents.
I’ve been building something that doesn’t fit cleanly into agents, SDKs, or plugins, so I’m posting to get technical feedback rather than hype reactions.
Instead of shipping an AI product or “agent,” I built a system where AI functionality itself is packaged and sold as licensed, downloadable capabilities that run locally in your own infrastructure.
Each capability is a real artifact (JS, WASM, container, edge) that does one thing well—memory systems, reasoning pipelines, resilience patterns, security controls, optimization loops, accessibility tooling, etc. They’re versioned, removable, and composable. And I promise I have capabilities you’ve never seen before.
Some capabilities can be combined into multi-module pipelines, and a subset of them improve over time through bounded learning and feedback loops. When the system discovers a new high-value pipeline, it becomes another downloadable artifact.
A few design constraints I cared about:
Runs locally (no SaaS lock-in)
Capabilities are licensed individually, not hidden behind an API
Full observability, rollback, and governance
No chat wrappers or prompt theater
Capabilities can stand alone or be composed into larger systems
Right now there are 80+ capabilities across multiple tiers, from small utilities up to enterprise-grade bundles.
What I’m honestly trying to sanity-check:
Is “AI capabilities as first-class, sellable software” a useful abstraction?
Is this meaningfully different from agent marketplaces, SDKs, or model hubs?
Where do you expect this approach to break down in real systems?
Would you rather see this exposed as agents, or kept lower-level like this?
Not here to sell—just looking for real technical critique from people who’ve seen infra ideas succeed or fail.
Happy to answer questions or clarify how anything works.
Most AI agents today are purely reactive—they wait for a token and then stop. I’ve been building a persistent runtime where the "thinking" doesn't stop when the user leaves.
This video is an uncut look at the autonomous state of the system. I call these "Dream Cycles” and “Evolution”.
What’s actually happening in these logs?
• The Thinking Phase: The system isn't just parsing text; it’s performing a recursive audit of its own execution history. It looks for logic gaps or "dead ends" in its previous reasoning paths.
• The Dream (Optimization) Phase: This is where the runtime performs cognitive offloading. It compresses high-entropy context into stable "heuristics." It’s essentially a background garbage collection and optimization pass for its internal world-model.
• The Evolving Phase: This is the most critical part. Based on the scan results, the system generates and applies updates to its own operational parameters. It’s a self-improving loop where the software is constantly modifying its own runtime to better handle future complexity.
I wanted to move away from the "black box" and show the actual raw telemetry of an AI managing its own development.
I'm curious to hear from others working on persistent AI state—how are you handling long-term "background" reasoning without the context window turning into a soup of noise?
The rest of the video are just bonuses. Enjoy and leave a comment! I want to know what you think about allowing systems to self improve and evolve.
For anyone curious about what I mean by “substrate” in this context - this isn’t an agent framework or wrapper around a single LLM.
CMPSBL is operating more like a cognitive OS: it provides persistence (memory), observability, defense, multi-model routing, and a self-improvement cycle for AI systems.
The goal isn’t clever chat output; it’s continuity, coordination, and the ability for a system to reflect on its own performance and update itself over time.
The v5.5.0 drop includes the full technical docs + module specs + validation methodology + runtime evidence.
If you want to audit how the substrate works or decide if this class of architecture makes sense, that’s the best place to start.
Main intended use cases today are:
– research labs
– cognitive infrastructure work
– autonomous systems R&D
– embedded AI runtime projects
– multi-model coordination
– memory-centric applications
Open to licensing discussions with research groups and R&D labs.
There’s a lot of “agent OS” vaporware going around right now, so here are some concrete things this system actually does today:
1. Shadow deployment for mutations
The Modernizer proposes patches → runs them in shadow → validates → escalates.
2. Auto-heal + circuit breakers
If a provider or subsystem degrades, the substrate routes around it and logs the failure.
3. Telemetry for cognition
vision.dashboard treats learning and doctrine cycles the same way Kubernetes treats pods: health, last cycle, mutation phase, error rates, etc.
4. Offline learning cycles
“Dream cycles” are just background reflection runs that don’t block real tasks. They ingest hot memory, generate insights, and update doctrine.
5. Interop with real systems
There are adapters for SAP/Workday/Databricks/GitHub/Slack/etc. so it can operate in enterprise environments rather than toy web tasks.
6. No human-in-loop required for steady-state . It currently runs for hours with no operator involvement beyond observability.
You don’t get useful autonomous behavior by stacking models.
You get it by adding OS-level orchestration primitives.
If that hypothesis is wrong, happy to be corrected. If anyone here has worked on orchestration layers, schedulers, or observability infra, I’d actually love to hear what’s missing / redundant / dangerous in this approach.
this isn’t an “agent” or chatbot. It’s a cognitive substrate I’ve been building for the last year that behaves more like an operating system for model orchestration.
A few useful details for people who asked for specifics:
• It has memory (hot/cold tiers, reflection, doctrine learning)
• It self-heals (auto-heal cycles, failure circuit breakers, shadow deployment)
• It mutates and upgrades itself via a component called the Modernizer
• It proposes patches and tests them in shadow before production
• It has a telemetry layer (vision) that treats cognition like observability
• It has adapters for SAP/Workday/Databricks/etc. so it can operate in enterprise environments
• Dream cycles run background learning when the system is idle
The logs in the post are real runtime output from v4.2.0. This build is running on top of Postgres + Redis + RabbitMQ + S3 + an LLM router (20+ providers). It currently has 12 modules, 160+ commands, and a 100% health score on this cycle.
Current research question is:
what’s the right abstraction for turning model capabilities into durable software infrastructure? My hypothesis is that you don’t need bigger models for autonomy, you need better orchestration.
Happy to answer technical questions here. No sales motion, nothing to buy, not trying to funnel traffic — genuinely interested in feedback from people who have built distributed systems, orchestration layers, and observability pipelines.
These are the logs that turned a machine, into an organism. I just joined the self improving software development team. Artifacts are the best receipts. Thoughts?