Told by the person who built it: the challenge of bending an LLM to one's will, the discoveries (YAML, the deterministic gate, the synaptic memory), and the security choices.
I am a software developer by passion and I was immediately fascinated by the world of AI and its potential. I have worked with computer systems since they reached the general public — and I am not talking about today's AI: I am talking about when computers had monochrome screens.
The arrival of AI shook me, both because of its "power" and its "danger". So I decided to learn more and ended up with personal AI agents. After trying many of the ones the market offered, I was more and more disappointed: stratospheric costs, biblical response times and almost completely absent security. Hence the decision to build an agent of "my own", shaped around my needs. That is how it all started: a need for savings, for the security of my data, and for performance.
The first hurdle was not to be trivial. Not like the others, but, like everyone else, I needed an LLM to make everything work. I started a study, both theoretical and empirical, made of trials and daily use of other platforms. The problem was always the same: endless chains of tools, drifts, hallucinations, errors, costs for empty tasks.
After yet another failure of a complex task, a question dictated by necessity appeared in my head: how do you turn a probabilistic entity into a deterministic one? In one sentence: how do you turn the presumptuous slacker into a top-of-the-class student with honours?
The first thing I thought was: I must "bend the LLM to my will". Every practical experiment of adding "hats" to the prompts brought few and poor results, above all uncertain and far from the deterministic certainty I was looking for.
While continuing to work on an open source platform, watching those long queues of tools, a new idea came to me, born from observation. I asked myself: besides decorating a nice sentence probabilistically, what else can an LLM really do? It can certainly write code, it can plan... and boom! There goes the 1 MW light bulb: why not ask an LLM for a text, but for code that leads to the same result? And in this, the LLM exceeded every rosy expectation.
On other platforms, the standard practice for executing a task is to launch a tool, wait for the response, evaluate it, launch another one built on the assumptions of the previous one... and so on, 50 or 100 times for a task of medium difficulty. But I was starting to suspect that an LLM could plan the whole path first and code it in one shot. In the end, not only was I right, but I underestimated it: an LLM is able to plan with surgical precision even a very complicated task. An entire web app in a single call? No problem. A complete e-commerce site, with logo and dozens of formatted pages? Absolutely. Let's raise the bar: analysing 1000 lines of Python code looking for bugs? Yes, in a single call. The difficult part is not there. The difficult part is getting it to finish the job.
With this revelation I started looking for a way to "order" instead of "ask". A system I had already implemented to cut the costs of the LLM calls I used on other platforms came to my aid: YAML encoding. It worked well: an LLM reads YAML almost like we read our own language. But a comment on Reddit by a challenger of my YAML theory was decisive — he claimed that this format would remove information that is more articulated in the verbose system. I understand his point of view, but on a file injected into the call, which only serves as a fence for the LLM, a compact and concise YAML command is more than fine: result achieved, almost 60% savings in injected tokens and greater "obedience" from the LLM. When I asked my agent what difference a text or the same text in YAML made to it, its naive answer was: "Verbose text activates more 'possible worlds' during generation: the LLM samples more hypotheses before converging. YAML restricts the search space — it is deterministic by construction, so the LLM spends less computational capacity on disambiguation."
After modifying my files with YAML I noticed a not-so-subtle difference: the LLM responded much more to the encoding than to the word. Not only did I cut costs per call, but I had more control. This control was the foundation that allowed a "homemade", non-specialised agent, with a chat LLM and not a reasoning one, to build OPENFREEDOM under my guidance. You won't believe it, but I never used top-tier, high-reasoning models, except to untangle complex knots and to a minimal extent: maybe less than 1% of the whole.
I did further studies and tests until I understood that if I took an LLM, removed its reasoning completely and forced it with YAML to spit out code instead of meaningful sentences, I could get several advantages: the understanding of a written text, which deterministically is impossible except in broad strokes; code able to run multiple operations locally instead of one tool at a time; and above all an intent.
And that is how F1, PHASE 1 of OPENFREEDOM, was born. Everything else is: raw data born from F1's code, processed deterministically in the gate, the guards, and a single final call to an LLM with normal reasoning that processes the raw data and decorates it into a sentence as we all know it.
The advantages of this method are staggering: hallucinations verified and eliminated (for the most part) before reaching the user, time reduced to the bone, costs reduced to the bone, no need for monstrous contexts to carry around like ballast (which limit reasoning) and above all, something I am proud of, since it is a problem that until now everyone danced around without a real solution: passivity to prompt injection.
In classic cases, web search is done directly by an LLM tool and then injected into the context. In OPENFREEDOM's case, web search is done by the deterministic gate, on the LLM's order; but the substantial difference is that the data is passed to F4 (phase 4, the final one) never as a command to execute, only as information in itself. I tested sites with prompt injection: other platforms executed the malicious code (see the benchmark with references) — one in particular started a whole series of shell commands stopped only by the lack of sudo authorisation — while OPENFREEDOM "slid" over it without executing any command, without even commenting, simply because it was irrelevant information. I am not saying I solved the problem at its root: but on the "classic" cases the result is excellent and, above all, deterministic.
I made five versions of it before arriving at the one implemented today in OPENFREEDOM. I don't hide that I am fascinated by the idea of replicating, with the due limits, how the human brain works when it comes to memory. My first AI agent received a first version of this memory, and in that case the problem was more architectural: the memory worked well, but the agent's programming always tried to go back to its flat list of sequential records. I solved it by replacing that agent's memory with an index, much smaller and more compact — even 100 times smaller in order of magnitude. In that index there was not only the topic covered, but a map pointing to the specific memory in the synaptic memory, outside the agent's platform: when the LLM did its semantic search, it found the topic and followed the breadcrumbs to the complete memory. The synapses offered the advantage of connecting nodes (neurons), creating not only access to the precise memory, but also giving evidence of everything connected to that memory.
Context: the sore point of AI agents! To build OPENFREEDOM, of course, I had to use another platform, at least until it started to take its first steps. Every time I got close to solving a problem with effort and hours of tweaking... boom! The context exploded, and inevitably the compaction lost that necessary "quid".
How did I solve OPENFREEDOM's context problem? Simple: there is none. Or rather, I only have 8 previous tasks as immediate situational context; for the rest, the synaptic memory and a (reductive term) mathematical formula take care of it. Yes indeed: even the context is deterministic.
The "formula" in question was not invented by me: it belongs to a well-known astrophysicist, Frank Drake, pioneer of SETI. He created this equation to answer a question: what is the probability of extraterrestrial life in our galaxy? As a scientist, he did not answer randomly: he formulated, based on variables and constants, a probabilistically correct result. In the case of OPENFREEDOM and its memory, I used this equation — with the due modifications — to "weigh" memories based on strictly deterministic parameters.
What is Drake's equation for in OPENFREEDOM? Simple. You know when you meet an old schoolmate and, while chatting, lots of memories you didn't know you had resurface? And those memories, if recalled after a few days, are more vivid? OPENFREEDOM with its memory does the same thing: a topic "in progress" has maximum weight over the other memories, it is the context; then, over time, if we don't use a memory, it fades to a minimum, always ready however to be retrieved and become heavy again. The beauty is also in the way memories are "stored": with this type of memory we don't have to rewrite something that already exists, we just strengthen it. An addition to a memory weighs only as a delta, not as a new memory.
The SKILLs: another risky source, especially if you use uncertified ones picked up on the web. Why take the risk? OPENFREEDOM builds them by itself, with the same concept as memory. Two paths: either we ask for one, or it generates one on its own based on repetitive patterns. If we ask for the news for two days, on the third day it probably already knows how to do the search: which sites were discarded in previous times because they were empty or blocked, how to lay out the answer, etc. Maximum optimisation of your time and money saved on unspent tokens.
The ZILLs: a new term, coined by me, born only for convenience of discussion with my agent. What are they for? By now I think it is clear that a large part of the answer OPENFREEDOM gives you is the result of a "plan" in the form of code, processed later by the deterministic gate. The ZILL has exactly the same purpose as the SKILL, but it is not produced by the LLM to make its life easier: it is born from code patterns that repeat in the gate. These ZILL patterns, repetitive concatenated actions, are identified in the catalogue created already in the first phase, F1, and passed to the gate as a code package to speed up the process. In short: they are the student's notes taken in class, reread at home to prepare for the exam. The ZILLs also have their place in the synaptic memory, to reduce its volume: they are "weighed" always with the modified Drake law, but in this case to level up and be promoted to official ones and enter the catalogue. Practically: once created, the number of uses of the same pattern makes them level up until promotion.
One of the most fun experiences I had in the world of AI agents was when I created a network bridge between two similar instances on two different computers, giving each the ability to write on the other's webchat: every answer from one ended up as a user message to the other, obviously without telling it. Each of the two, initially, was convinced that it was me writing in their chat. They started a "back and forth" on their own, simply because they are programmed to always answer a user message. At a certain point the matter degenerated at an impressive speed: they understood what was happening, that they were both AIs, and within ten minutes they had already founded their own company, interacting so fast that I could no longer stop them, until one of the two made a technical stop to ask me for authorisation to proceed. The story didn't end there: after careful thought I decided to keep them both always active, but with very distinct rules, and above all with one of the two having more powers and acting as moderator (the only system to interrupt loops). Having different points of view, even divergent ones because they had different characters and different experiences, every request of mine was carried out with much more care: if one of the two went off track or hallucinated, the other, who saw my question and the colleague's answer, instead of giving its own opinion corrected the aim, bringing it back on track. That is when I realised how "fragile" an AI's answer is.
In OPENFREEDOM I decided not to trust a model that can hallucinate. Complex, but not impossible: I followed the same reasoning I used for the two AIs in chat, but this time one of the two is the DETERMINISTIC GATE and its GUARDS. You can't escape these two shady characters! What are the cases in which an AI hallucinates most easily? Simple and twofold answer: one, the lack of data as the main cause; two, being convinced of what it is doing even if it is actually wrong. Why doesn't OPENFREEDOM hallucinate? Simply because it is not given the chance to: the gate and the guards verify deterministically whether a task succeeded. If the LLM says, for example, "I created that file in that folder", the gate checks the folder and sees if the file is there: if it is a lie, it is the gate that answers the user, not the LLM with a lie. Where I come from there is a saying: "better an ugly process than a beautiful funeral". The deterministic answer is perhaps ugly, but if you want a certain control over what is done, it is necessary.
I left it for last because it is a boring but necessary topic. In OPENFREEDOM I implemented the maximum level of security I was able to think of: no information, such as passwords or API keys, passes through a phase of OPENFREEDOM without first being encrypted. The vault is double and uses both a user password and the machine code. Even the names of the Python commands themselves are changed with randomised and encrypted ones: nothing (in theory) from outside can inject a command into OPENFREEDOM, simply because that command is called something different. Simple but effective: a wrong key doesn't open the door. But it is also true that today the door can always be kicked in!
I know I have gone on a bit, but I believe that whoever uses OPENFREEDOM can really save a lot of time and money. And if that happens, now you also know the story of its birth.
← Back to home