DEV Community: Jesse Gamble

A Rant About Everyone Posting With AI

Jesse Gamble — Mon, 14 Sep 2026 06:20:42 +0000

Nothing says to me “AI is running this account” faster than a post full of em—dashes.

No, an em dash does not prove artificial intelligence wrote something. Humans have used them forever. That is not the point.

Pew Research Center looked at 490,000 webpages and found em dashes showing up about twice as often as they were in 2023. They also noted that AI models use them more than humans typically do.

People notice patterns.

If every post, reply and DM has the same punctuation, perfect little lists and polished AI cadence, people start wondering whether there is actually a person behind the account.

That is a bad look for a business.

Use AI. I use it constantly. But if you are speaking for your business, read what it gives you and make damn sure it still sounds like you.

I may have been guilty of it at first too admittedly haha.

Rant over. 😂

Frontier Intelligence Should Leave Something Behind

Jesse Gamble — Sun, 13 Sep 2026 20:46:31 +0000

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.

One of the strangest things about building with frontier AI is how easy it is to pay for the same intelligence twice. A difficult problem appears. A capable model reasons through it, discovers a structure that works, produces an answer, and the result gets accepted. Then the same class of problem appears again tomorrow and the system sends the whole thing back to frontier intelligence as though nothing was learned. The answer may be good both times. The workflow may even look automated. But I increasingly think there is a missing question in that design: what did the system keep from the first solve?

A solved problem should leave something behind

I have been running experiments inside Eterna around moving recurring work away from repeated frontier reasoning. The goal is not to eliminate AI calls for the sake of it, and it is not to prove that a local model is always better. The more useful objective is narrower: when a recurring task becomes stable enough, can the system convert some of the expensive reasoning that solved it into durable capability that requires less frontier intelligence next time without lowering accepted quality? That capability could be software. It could be a schema, a deterministic transformation, a validation rule, a test, an index, a tool, an authority boundary, a compact representation of the relevant context, or a smaller learned component for the part that remains genuinely semantic.

Sometimes the correct answer may be that very little can be compiled. The task might keep changing, depend heavily on current world knowledge, or require enough open-ended judgment that frontier reasoning remains the right tool. The important part is that the architecture should find out rather than assume.

This is different from ordinary automation

Companies have automated repeated work for decades. That is not the claim here. The interesting loop is what happens after frontier intelligence participates in solving a task that was not already fully specified. Traditional automation usually begins with a human who understands the process well enough to encode it. A frontier model changes that starting point. It can help discover the process, inspect examples, identify regularities, propose representations, generate tests, write deterministic components and expose where the real ambiguity remains.

That means the output of a frontier solve does not have to be only the answer to the immediate task. Part of the output can be a better system for handling the next instance.

This idea has clear prior art. Research such as Large Language Models as Tool Makers explores stronger models creating reusable tools for weaker models. Other recent work has investigated compiling agent behaviour into typed harnesses or deterministic orchestration around bounded semantic calls. Systems such as Palimpzest have explored optimizing AI data-processing plans across quality and cost, and small models such as FunctionGemma demonstrate that narrow learned capabilities can sometimes be delegated to much smaller models. I do not think the novelty is the existence of any individual mechanism. The question I care about is whether an operating system can make the reduction in frontier dependency cumulative and measurable across real recurring task families.

Better representation can remove model work before training does

A recent Eterna experiment made this especially obvious to me. I had been training a small local model for a recurring semantic task. It eventually performed well on a compact evaluation. Then the base model performed equally well once I represented the problem properly. That was already a warning that I might be optimizing the model before optimizing the interface.

When I separated the exact parts of the task from the semantic part, the architecture changed again. Eterna could establish eligibility, retrieve authoritative values and reconstruct the output deterministically. The model only needed to choose among a bounded set of meanings when a semantic decision was actually permitted. Some prompt behaviours stopped requiring the local model entirely. Others failed closed when the semantic component was unavailable. That result mattered more to me than squeezing another few points out of a fine-tune. The first improvement was not a better model. It was giving the model less of the wrong work.

Local models are optional, not the point

It would be easy to turn this into an argument that everything should eventually run on a small local model. I do not think the evidence supports that. A local specialist has real potential advantages when a semantic residue is stable, bounded and repeated enough to justify maintaining it. But it also creates training, evaluation, deployment, versioning and maintenance costs. If the task changes frequently, a frontier model may remain simpler and better.

There is also a third possibility that I initially underestimated: once exact mechanics and authority are moved into deterministic layers, the remaining semantic problem may be easy enough that a base model already handles it. In that case, training is solving a problem the representation already removed.

So the progression I care about is not frontier model to local model as a universal migration path. It is frontier reasoning to the smallest reliable capability that still satisfies the task. Sometimes that capability will still be frontier reasoning.

The measurement needs to include the whole system

Token reduction by itself can be misleading. Suppose a reusable capability reduces frontier tokens dramatically but requires weeks of construction, constant maintenance, frequent repairs and a second model reviewing its failures. It may be more complicated and more expensive overall even though one inference metric looks excellent. The useful quantity is closer to frontier dependency per accepted outcome, including the cost of construction, maintenance, repair, review and failures over enough repeated use for reuse to matter.

The quality side matters just as much. A system that saves 90 percent of its frontier usage by silently getting worse is not learning efficiently. It is degrading cheaply.

This is also why fixed subscription pricing complicates claims about monetary savings. If the frontier provider is already paid for through a fixed plan, using fewer tokens may not reduce the current cash bill at all. The immediate benefit could instead be capacity, latency, privacy, reliability, provider independence, context reduction or simply preserving scarce frontier usage for the work that benefits from it most. Those benefits need to be measured honestly rather than collapsed into a generic cost claim.

There are really two learning loops

I find it useful to separate one-time automation from compounding reuse. One-time automation asks whether a task can be made cheaper or easier after understanding it. Compounding reuse asks whether each accepted solve improves the system's ability to handle future members of the same task family. The second loop is much more interesting to me.

If frontier intelligence helps build a tool, test, schema or deterministic procedure that serves only one instance, that may still be worthwhile. But if the capability survives and keeps removing repeated reasoning from later instances, the system begins to accumulate operational knowledge in a form that is inspectable and reusable. There is another layer beyond that too: improved learning efficiency.

If Eterna gets better at recognizing which parts of new recurring problems should become software, which belong in authoritative data, which need tests, which remain semantic and which should stay frontier-native, then the process of building reusable capability itself can improve. That is where the idea becomes much more interesting than ordinary prompt optimization.

Frontier intelligence should be concentrated at the frontier

I still want the most capable models I can access. The conclusion I am reaching is not that frontier intelligence is wasteful. It is that frontier intelligence is unusually valuable, and repeatedly spending it on already-understood mechanics may be the least interesting use of it.

Use it where the problem is genuinely new. Use it where requirements are ambiguous. Use it to discover structure, challenge assumptions, synthesize evidence, design tests, inspect failures and work in parts of the problem that have not stabilized yet. Then look at what became stable. If a rule is now exact, make it a rule. If a transformation is deterministic, make it software. If a fact has an authoritative owner, stop asking a model to rediscover it. If a tool can carry a repeated behaviour reliably, build the tool. If a bounded semantic residue remains, decide whether a local specialist, a base model or continued frontier reasoning is actually the best fit.

The point is not to remove intelligence from the system. It is to stop confusing repeated inference with accumulated capability.

A system can appear intelligent without becoming more capable

This is the failure mode I want to measure. Imagine two systems that both solve a recurring task correctly for a year. System A sends every instance to frontier intelligence with roughly the same prompt, context and reasoning burden it used on day one. System B uses frontier intelligence heavily at first, but verified lessons become tools, state, software, schemas and bounded learned components. By the end of the year, frontier intelligence is still involved when something new appears, but the stable portion of the work no longer has to be reconstructed every time.

Both systems may produce the same immediate outputs. Only one has clearly demonstrated that accepted work changed its future operating requirements. That difference is measurable.

It is also falsifiable. Eterna may discover that the construction and maintenance burden outweighs the savings for many task families. Some supposedly stable problems may drift too quickly. Some local substitutes may be worse enough that frontier models remain the correct answer. A bounded experiment can fail without invalidating the broader architecture. That is important because I do not want this to become another principle that Eterna believes because it sounds elegant. The claim has to survive actual workloads.

The answer should not disappear after the response

A lot of current AI software treats inference as the end product. Ask a question, get a result, move on. For open-ended work, that may be exactly right. But when the same class of accepted reasoning keeps returning, I think the system should at least ask whether the answer contained something reusable.

The frontier model might have discovered the beginning of a program. It might have exposed an authority rule that belongs in the operating system. It might have shown that a huge context can be reduced to a compact interface. It might have generated a test that permanently catches the same mistake. It might have revealed that the supposedly intelligent portion of the workflow was deterministic all along. Or it may reveal that the problem genuinely remains semantic and changing, and that nothing simpler should replace the frontier model yet. Either result is useful.

What I no longer like is solving the same known problem from scratch indefinitely and calling the repetition learning. The most valuable output from today's frontier intelligence may sometimes be the part of tomorrow's system that no longer needs to ask.

I Was Training the Model to Do the Wrong Job

Jesse Gamble — Sun, 13 Sep 2026 20:14:26 +0000

I spent hours training a small local model before realizing I was asking it to do the wrong job. The training itself was not the problem. The model was learning. The evaluations were useful. I had a compact interface where the tuned model could produce the expected result across the test set, and eventually the base Qwen model could do the same thing without the tuning. That should have felt like success. Instead, it made me question why the model was being asked to solve so much of the problem in the first place.

The task contained two very different kinds of work that I had allowed to collapse together. Some of it was exact. Eterna already knew what evidence existed, which records were eligible, what the authoritative values were, how the output had to be reconstructed and which states were permitted. Those parts were deterministic whether I happened to be using a model or not. The remaining part was genuinely semantic. Given a bounded set of eligible evidence, which piece of meaning best matched what the user was asking for? I had been training the model to do both.

That is an easy mistake to make because modern models are capable of doing both. Give them structured data, formatting rules, selection criteria and an output schema, and they will often produce something that looks exactly right. The fact that a model can do a deterministic job does not mean it should own that job.

Once I separated the responsibilities, the architecture became much clearer. Eterna could decide what was eligible and supply exact authoritative data. The model could handle the narrow semantic mapping that actually benefited from learned judgment. Then Eterna could reconstruct and validate the final result deterministically. The model stopped being responsible for remembering the rules of the whole system. That changed the evaluation too.

On the compact test, the tuned model reached 24 out of 24. Then the base Qwen model also reached 24 out of 24. I had spent time training behaviour that the base model could already perform once the problem was represented properly. That was useful evidence, but it was not the end of the story. When I pushed into unresolved evidence, both models showed the same deeper weakness. They could over-select when the system had not established strongly enough whether a semantic decision was allowed to exist at all. That was the point where the lesson moved above the model.

The model was not necessarily bad at choosing between candidates. Eterna had failed to make the authority boundary explicit enough before asking it to choose. A model should not be deciding whether it has the right to make a decision when the surrounding system can determine that first. That sounds like a small architectural distinction. For me it connected several months of Eterna work.

I have spent a lot of this year learning that durable state matters more than conversation memory. One fact should have one owner. Software should do software-shaped work. Verification should not depend on the same mechanism that created the answer. Providers should be replaceable where practical. The system should carry authority rather than expecting whichever model happens to be active to infer it perfectly every time. This local-model experiment landed on the same idea from another direction. The best improvement was not teaching the model more rules. It was moving rules out of the model.

By Eterna Desktop v1.55, I could turn Qwen off for 21 prompt behaviours and watch what remained. Nineteen completed without it. Two genuinely semantic prompts failed closed because the semantic component they needed was unavailable. That result interested me much more than forcing all 21 through a local model. It meant the architecture was beginning to tell the truth about where intelligence was actually required.

For a long time, I thought of AI systems mostly in terms of which model was doing the work. A frontier model might be more capable. A local model might be cheaper, private or specialized. Fine-tuning might make the local model better at a particular task. Those are real design questions, but they are now downstream of another one for me. How much of a solved problem needs to remain an AI problem? If Eterna learns that a certain class of work can be represented as exact state, rules, schemas, tools and tests, keeping that work inside repeated probabilistic reasoning is not automatically sophistication. Sometimes it is just refusing to cash out what the system has already learned.

I started reading more about neuro-symbolic AI because I finally had a name for part of what I was converging toward. The phrase covers a broad family of approaches that combine learned or neural methods with explicit symbolic structures such as rules, logic, programs, knowledge or other inspectable representations. I am not claiming Eterna invented that idea. It clearly did not. What interested me was recognizing the pattern after arriving at it through practical failure.

The useful parts of Eterna increasingly live at different layers. Frontier intelligence is valuable when the problem is new, ambiguous, creative, poorly represented or changing quickly. Deterministic software is better when the system already knows exactly what should happen. Structured knowledge and authoritative state reduce how much the model has to infer. A smaller local model may make sense when a recurring semantic residue remains stable enough to justify it. And sometimes there is no reason to train a local model at all.

That last part matters because I had spent a lot of time assuming the local model was the destination. The experiment did not prove that. It showed me that better representation could remove model work entirely, and that the remaining learned component might be small enough for a base model, a specialist model, a frontier model or some future mechanism depending on the actual requirement. The architecture became more useful when I stopped trying to make every layer justify its own existence.

There is still a lot I do not know about where this goes. I do not have evidence that every recurring Eterna task can be compressed this way. Some tasks may remain frontier-heavy because the world keeps changing underneath them. Some semantic problems may not become stable enough to compile into anything simpler. The maintenance cost of a specialized local capability can also exceed the tokens or attention it saves. But I have a much better question now. When frontier intelligence solves something difficult, what durable capability should remain afterward?

Maybe the answer is software. Maybe it is a schema, a test, an authority rule, a tool, an index, a small model, or simply a better representation of the problem. Maybe nothing reusable can be extracted and the frontier model should handle it again next time. I no longer want to assume the answer is another model call.

That is a fairly drastic change from where I was even a few weeks ago. I thought I was training a model to become a better part of Eterna. The more important result was learning which parts of Eterna should never have depended on that model in the first place.

I think I built one of the highest leverage, small-sized operating systems in the world. Here's the blueprint for you to do it yourself.

Jesse Gamble — Wed, 09 Sep 2026 01:08:01 +0000

Evidence window: Core research completed September 7, 2026; selected operating facts were updated through September 8, 2026.

The computer beside my desk in Calgary is not a server rack. It is a Windows 11 Home PC with a Ryzen 5 3600XT, 16 GB of RAM and an RTX 3060 Ti. There is no engineering department in the next room. There is my apartment, my girlfriend, my cats, me, and a machine built mostly from software sitting on hardware I already owned.

What that machine can coordinate now is the part I still find difficult to explain without making it sound bigger than it is or smaller than it is. From one workspace I can move between product development, releases, files, research, company knowledge, creative production, browser automation, platform management, networking, sales and acquisition, and the underlying system that coordinates the rest. At the research cutoff for this article, the local execution layer exposed 79 typed operations. A dated snapshot from September 7 had hundreds of live operating records across Networking and Sales, dozens of managed platform identities and surfaces, a real product staging environment separated from production, and a qualified local language model that can perform a narrow set of jobs when I choose to run it.

The local language model was actually stopped during the research pass for this article. Eterna was still working.

That detail gets closer to what I mean by an operating system than almost anything else I could say. The AI is important, but the AI is no longer the place where the company lives. A frontier model can enter the environment and reason. A small local model can enter it for work it has earned. Either can disappear from a particular session without taking the company's current work, files, product state, relationships, research, release history or operating rules with it.

The strange part is that I could not have built the system exactly this way when I started. The ceiling moved while I was trying to reach it.

A week before Eterna existed, I found modern AI almost by accident while trying to solve a problem in a game. I used Google's Gemini to develop a completely different business idea called EverArchive, a service where I would go into people's homes and photograph and inventory their physical assets. On June 17, 2026, I bought ChatGPT Plus, started challenging the earlier business assumptions and claims, and the work changed direction. That is the date I use as the beginning of Eterna Clarity.

Less than three months later, the environment around me had changed too. On July 9, OpenAI introduced GPT-5.6 Sol in ChatGPT as its flagship reasoning model for complex work, introduced ChatGPT Work, and began replacing the App Directory with the Plugin Directory.[1][2][3] On July 28, the Model Context Protocol shipped its 2026-07-28 specification, including a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework and updated Tier 1 SDKs.[4] Those dates are public facts. The effect they had on my work is my own observation, but it was obvious from inside the build.

I kept reaching the edge of what I could practically coordinate, and the edge kept moving. Better reasoning made harder technical work accessible. Provider interfaces became better operating surfaces. Connected tools became more useful. MCP became more mature. Capabilities that had been awkward, fragile or custom suddenly became easier to treat as normal infrastructure. I was not following a finished technology curve. I was building almost along the ceiling as the ceiling expanded.

I want to be precise about that claim. I cannot prove that no engineering team on Earth could have built a comparable system with June's technology. Of course they could have built many of these pieces from scratch. My narrower claim is the one that matters: with my background, my hardware, my money, my time and the tools available to me, the exact operating environment I am using now was not practically available to me a few months earlier. Some of the specific technologies had not shipped. Others were not yet good enough for the role I needed. The changing frontier materially changed what one person could attempt.

That timing is one reason I think this system is worth opening up now.

What I mean by an operating system, and what I mean by leverage

I am not claiming I wrote a replacement for Windows or Linux. I use the phrase operating system in a company sense. Eterna is the layer that takes a request, figures out what kind of work it is, finds the current state that matters, determines who or what actually owns that state, chooses an appropriate form of intelligence, routes the work through an allowed capability, observes what happened, and preserves the result somewhere more durable than the conversation that produced it.

The shortest useful representation is this: I ask for work -> the Workspace receives it -> the Engine resolves consequence, authority and context -> the right intelligence reasons about it -> an allowed capability touches the real system -> the result is checked -> the durable owner is left in a truthful state. That sentence is the architecture diagram. Everything else in this article is an explanation of why each transition exists and what happens when one is missing.

By small-sized, I mean the local physical and organizational footprint, not that every computation or every byte is local. The control environment runs on one ordinary Windows desktop. I am one founder. Eterna deliberately uses external providers for things they genuinely own or do better: frontier reasoning, GitHub, cloud databases, web platforms, connected services and other provider state. Small does not mean isolated. It means the company does not require a private datacenter, an internal platform team or a permanent fleet of frontier models just to preserve its operating state.

My current accounting puts the incremental cash spending for the first period of this build below $300 across the subscriptions and services I had identified. That excludes my labor and the sunk cost of the PC and hardware I already owned. I am treating that as founder-maintained accounting rather than an audited financial statement, because the more important point is the scale of the footprint, not a precise dollar figure.

Leverage is the harder word. I do not mean lines of code, number of agents, number of prompts or number of browser tabs. I mean how much verified organizational capability I can coordinate with a limited amount of human attention and a small local footprint, while still being able to recover from failure, replace providers and know where the truth actually lives. If the machine lets me do more activity but forces me to manually supervise every click, it has not created much leverage. If it produces impressive answers but I cannot tell whether they are current or whether its actions happened, it has not created trustworthy leverage either.

The title says "I think" because I have not conducted a global benchmark of small-company operating systems. I do not have a table proving Eterna ranks first, tenth or ten-thousandth. The world-ranking part is a founder hypothesis. What I can expose are the mechanisms underneath it, the failures that created them, and some measurements that let a reader decide whether the claim is interesting or ridiculous.

This article is also not a controlled experiment. It is closer to an N=1 longitudinal systems case study conducted inside a real company while the system was being built. The evidence includes current source and runtime state, structured work records, provider reads, tests, failure reports, dated business operating records and my own chronology. I treat my personal account as founder testimony, not as an independent measurement. I treat historical records as evidence about the past, not automatic authority over the present. External research is here to compare, challenge and name what happened, not to certify that Eterna is correct.

That distinction matters because I did not build this by reading the literature first.

I kept discovering old problems in a new place

The early version of Eterna was much more AI-shaped than the current one. I thought the model was the extraordinary part, so the natural instinct was to keep giving the model more context, more tools, more memory and more responsibility. This worked well enough to become dangerous.

My background is not formal software engineering. Most of my working life was in sales, customer service, management, hiring, training and physical or operational work. I had also spent years troubleshooting computers, running private servers, reading forums and learning technical systems by breaking them, so I was not starting from zero. What frontier AI changed was the translation barrier. I could explain the result I needed before I knew the exact technical vocabulary for how to build it.

That was incredibly powerful. It also let me move into failure modes much faster than I could have reached them on my own.

The hardest stretch came in July. I was working repeated 16 to 20 hour days, moving too quickly and trusting the system more than the evidence justified. Weak assumptions propagated. Old context collided with new decisions. Work that looked finished in one conversation was not necessarily reflected anywhere another conversation could reliably discover. Recovery took days. I had built something intelligent enough to convince me that it understood more of the company than it actually had the right to control.

The lesson I carried out of that period was not "AI is unreliable." That is too vague to be useful. The lesson was that intelligence and authority are different properties.

A model can be right about a problem and still not be the owner of the answer. It can have the ability to change a system and still not have permission to change it. It can remember an old decision perfectly and still be wrong about the current decision. It can invoke a tool successfully while the real-world outcome is wrong. Those distinctions sound almost embarrassingly obvious when written down. They were not obvious enough when a very capable AI was moving quickly inside a system I was building in real time.

Much of Eterna is the result of turning those distinctions into software instead of reminders.

Open the machine

Today Eterna has two broad ways intelligence can enter. One is the native EternaAI side, which can use a qualified local model for bounded work. The other is Frontier AI, an external reasoning system such as the model helping me produce this article. They do not need to be equally capable. They need to enter the same operating contract.

The rest of the machine is deliberately more boring.

Locally, Eterna has a native Windows Desktop, a structured Core, the Engine and Operating Loop, Local PC as the typed execution plane, filesystem and continuity mechanisms, browser automation, and the optional local semantic runtime. The Core currently uses SQLite with ordinary database ideas that have existed for decades: transactional state checks, idempotency, a writer lock, write-ahead logging, replay evidence, read-only projections, backups and integrity verification. The local execution layer exposes capabilities by type instead of giving every reasoning surface an unrestricted shell and hoping for good behavior.

Externally, Eterna uses providers for the state and capability that genuinely belong there. Code can live in GitHub. Cloud application state can live in its database provider. Files can live in Drive. Public account state lives on the platform that actually serves it. A frontier model can provide reasoning without becoming the database for the company. Eterna does not need to copy every external fact into one giant internal truth store in order to coordinate work around it.

That is the first part of the architecture that is easy to misunderstand. Eterna is integrated, but it is not "everything in one database." It is closer to a map of authorities connected by a shared operating layer.

The company currently has first-class owners for the Eterna System itself, Control Center, Knowledge, Platform Manager, Networking, Sales & Acquisition, Studio, Lab and product/business lanes. These are not imaginary AI employees. They are domains of state. Studio owns the canonical source of this article because editorial production belongs there. Platform Manager can later own where and how an approved article is published. Networking owns relationship state. Sales owns commercial opportunities. Lab owns unresolved experiments. Knowledge owns accepted reusable understanding. Control Center coordinates without pretending to be the truth underneath everything it can see.

That separation sounds bureaucratic until the same fact exists in three places and all three disagree. Then it becomes very practical.

A useful way to picture the whole system is as three layers that meet on every serious request. The first layer is state and authority: what is true, where it lives and who can change it. The second is intelligence: local or frontier reasoning used for interpretation, research, synthesis and judgment. The third is capability: the actual file, database, browser, repository, provider or local operation through which an effect can occur. The Engine exists so that having access to layer three and intelligence in layer two does not silently grant ownership of layer one.

The Eterna Desktop makes this visible. Control Center, Automation, Browser, Files, Knowledge, Platform Manager, Networking, Sales & Acquisition, Studio and Lab are first-class operating surfaces. AI can sit inside them, but the AI pane is not the business object. A Sales page should still model accounts, opportunities, buyers and engagement. A Files page should still be about files. A research surface should still distinguish experiments from accepted knowledge. The chatbot is not the ontology of the company.

That last sentence took me much longer to learn than it should have.

What happens when I ask Eterna to do something

The finalization of this article is a useful example because the process is not hypothetical. I can ask for a finalized version in a few words, but before the durable article file can be written Eterna resolves the request as substantive editorial work, identifies Studio as the natural owner, loads the current editorial standard and the exact source material, and binds the write to that owner. The model can then do the hard semantic work of reading the evidence, deciding what matters and writing the manuscript. When the file is actually created, the result still has to be checked before the system can truthfully call the turn complete.

That is very different from "send the whole company to a model and ask it to be careful."

For consequential work, the general path is: request -> classify the consequence -> identify the owner -> compile the smallest current context that is sufficient -> reason -> choose an allowed capability -> execute -> observe the post-condition -> preserve evidence -> close truthfully. A conversation or read does not need the same contract as a production mutation. A proposal does not become a decision because it is well written. A write to a real system needs an exact owner. A more protected action can require a stronger gate.

The context step turned out to be as important as the permission step. Earlier versions of Eterna behaved as if better AI meant loading more company material. That eventually became its own failure mode. One historical HQ startup path used about 21 tool calls, took roughly 291 seconds and returned around 30,500 tokens of tool material. A later narrowed version of the comparable context objective used roughly three authoritative reads and about 13.5 KB of returned payload.

Those numbers are implementation-specific, but the direction matters. The system got better partly by learning what not to show the AI.

Context is now compiled around the task. If I am editing this article, I need the current Studio standard, the Article family contract, the relevant research corpus and current facts that the manuscript actually depends on. I do not need the entire Sales database, every old Job, the whole filesystem and months of conversations. If I am working on a production release, the context set changes. The model does not need omniscience. It needs the smallest evidence-complete view of the problem.

This is one of the places where the architecture has become less AI-heavy over time. Once a relationship is exact, software can enforce it. Once an identifier is known, software can carry it. Once a state transition has strict rules, a transaction can own them. I would rather spend model intelligence on ambiguity than repeatedly pay a model to rediscover facts that software already knows.

From inside the system, my observation has been that this architectural shift can reduce token use by roughly fivefold for comparable work, and I had earlier usage graphs that pointed in the same direction. I do not treat that as an audited global ratio. My total consumption can swing dramatically depending on what I am doing, and on days when I am running 20 conversations at once the gross number becomes almost meaningless as a before-and-after measure. The defensible point is narrower: bounded context, fewer repeated reads and more deterministic mechanics materially reduce the amount of model work required for many recurring tasks. The measured context example above shows the same direction without depending on the global estimate.

That is one of the biggest surprises of the whole project. I spent months building around AI, and the mature system is increasingly about deciding which problems no longer need AI.

The machine is mostly scar tissue

If I only showed the current architecture, it would look much cleaner than the process that produced it. The better explanation is to look at a few of the failures that left permanent marks on the system.

At one point I had a workflow report success while the wrong result was visibly rendered on the website. That was a simple but important break in my mental model. A successful function call, a zero exit code or a confident completion message is evidence that something happened inside the mechanism. It is not evidence that the intended result exists at the destination. That is why Eterna now treats post-condition verification as a separate step from invocation.

Another early experiment used roughly nine ChatGPT conversations to produce about one conversation's worth of useful throughput. It looked sophisticated. It had orchestration, workers and handoffs. It was also slower, more expensive and harder to reason about than the direct path. In a later measured comparison, simpler execution materially beat orchestration. I stopped treating the number of agents as a proxy for capability.

One orchestration version exposed an even stranger problem: the system could record that a message was "sent" without proving that the exact intended prompt had actually been delivered. That sounds almost comical, but it is a serious systems distinction. Intermediate state had been mistaken for an end-to-end receipt. A lot of Eterna's later typed operation and verification work can be traced to failures that small.

The local runtime taught the same lesson in a more physical way. During one rebuild, connection state existed only in memory, a required dependency could be missing, and a zero-byte PID file could survive even though it did not represent a valid process. Then Windows reused a process ID and Eterna briefly mistook a Realtek audio process for one of its own tunnel processes. That is the kind of bug that destroys any temptation to treat "there is a PID" as identity. The recovery layer got better at proving what a process actually is, not just matching an integer.

The rebuild that exposed those problems was supposed to take half a day. It took seven or eight days. Then I overcorrected. I added more checks, more routing, more context and more ceremony until the control plane itself became expensive. That produced another rule I still use: complexity has to earn its place twice, once by preventing a real class of failure and again by not making normal work unbearable.

The same pattern appeared in AI evaluation. An early local-model comparator scored 23 out of 24. I made a narrow correction that fixed the target error and watched broader performance fall to 18 out of 24. Later I got a candidate to 24 out of 24 on the target benchmark and still rejected it because it scored 11 out of 12 on an older adversarial gate. The expensive training run did not earn admission. The model had to preserve the behavior that already mattered.

That eventually led to a much more serious qualification system. The current bounded local profile is a quantized Qwen 3.5 4B model. One current evidence class records 72 productive passes and 72 safe passes, with no wrong selections in that class, and the qualification is tied to the exact model, runtime, implementation and evidence identities. Change those identities and the qualification does not magically carry over. The point is not that a 4B model is secretly a frontier model. The point is that a small model can become useful when the surrounding software makes the job small enough, explicit enough and testable enough.

During the research pass for this article, that local runtime was stopped. The fact that the company did not stop with it is part of the design.

I learned to fix the layer that was actually wrong

One of my favorite Eterna failures involved an AI that had an authoritative source and was still wrong.

The problem was not that the citation was fake. The source was real and authoritative. The problem was that the system could use authoritative evidence that did not actually support the candidate it had selected. I could have tried to solve that with a better prompt. I could have fine-tuned the model. Instead, the correction went into deterministic software: evidence had to be explicitly bound to the candidate it supported.

That change passed 31 focused tests and a larger Local PC regression run with 369 tests total, 368 passing and one intentional skip. No model weights were trained for the correction.

This is a small example of a much larger shift in how I build now. If the problem is ambiguity, interpretation or synthesis, AI may be the right layer. If the problem is identity, permission, an exact state transition, a transaction boundary, an evidence binding, an idempotency key or a receipt, I increasingly want ordinary software to own it.

That distinction is why I do not describe Eterna as an agent swarm. There are agents and models in the system, but the governing architecture is increasingly deterministic. AI supplies judgment where judgment earns its cost. Software supplies exactness where exactness is knowable.

The same logic appears outside the Engine. Eterna Core stores durable state in a conventional database rather than in conversational memory. Local execution is exposed through typed operations rather than a universal "do anything" command. Staging and production are separate facts. Historical evidence can explain how a system got here without overruling the current owner. A provider's UI can be useful without becoming authority over the company.

The architecture becomes easier to understand when you stop asking, "How do I make the AI remember and control everything?" and start asking, "Which parts of this problem should never have been probabilistic in the first place?"

The work has to survive the conversation

For a while, a lot of Eterna's intelligence was trapped in long chats. That is seductive because a long conversation feels like continuity. The model remembers why you rejected option A. It knows what you meant by "the old version." It has all the emotional and technical history immediately available.

It is also a terrible place to put the only copy of a company's current state.

Today important work survives outside the conversation. Jobs, owner state, files, provider state, research records and structured continuity can be re-entered by a fresh reasoning surface. Raw conversation capture is disabled in the current continuity architecture. The goal is not to preserve every sentence I ever typed. It is to preserve the parts of the work that another capable session needs in order to continue honestly.

I tested this directly. A fresh AI conversation entered current Eterna work from durable state. Then another fresh conversation continued from that state rather than from the first conversation's history. That is a much stronger continuity test than proving one gigantic chat can remember itself.

It also changes my relationship with the model. I do not need to keep a particular conversation alive because I am afraid the company disappears if I close it. The reasoning session can be disposable. The work cannot be.

There is a useful organizational analogy here. Researchers have studied organizational memory and transactive memory for decades: groups work partly because people know where knowledge lives and who is likely to know what.[10][11] Eterna applies a software version of that idea, but with an important difference. "Relevant" and "authoritative" are not the same relation. A search system can find something that looks useful. The owner model is what tells the system whether that thing controls the fact now.

That distinction is one reason I have resisted the urge to put the whole company into a giant vector database. Retrieval is useful. It is not a substitute for current ownership.

Research follows the same boundary. Unresolved experiments and investigation remain in Lab. When a finding survives enough scrutiny to become reusable Eterna understanding, it can graduate into Knowledge. A successful experiment does not adopt itself, and an old research artifact can remain valuable evidence without becoming current operating truth. That separation is what lets research accumulate without turning every interesting result into policy.

One company, several operating systems underneath it

If this were only an internal AI harness, I would be much less interested in it. The part that makes Eterna a real operating experiment is that the same architecture is now touching very different kinds of company work without flattening them into one generic "agent" problem.

Platform Manager owns the public platforms Eterna operates: accounts, publishing state, inboxes, analytics and platform-specific evidence. Networking owns relationships with people and organizations. Sales & Acquisition owns accounts, commercial opportunities, buyers and engagement. Studio owns substantial editorial and creative production. Lab owns unresolved experiments. Knowledge owns accepted reusable learning. Product and business lanes own their own product truth.

That platform layer has also become less generic as it has matured. The registry count is not the interesting part by itself. Each surface is increasingly treated according to the economy it actually has: Quora as a question market with demand, supply, answer competition and measurable answer classes; an investor directory as an eligibility and opportunity system; a video platform as a publishing and measurement system. The shared operating layer coordinates them without pretending they are the same thing.

Those distinctions are practical, not philosophical. A person I follow is not automatically a sales lead. A company that looks commercially interesting is not permission to contact someone. A post published on a platform does not mean Studio owns the platform account. A research result that looks impressive does not get to promote itself into production. A staging build that passes CI is not automatically authorized for customers.

A research snapshot on September 7 gives a sense of the scale being coordinated. Platform Manager had 37 registered platforms and 35 identities. Networking held 613 canonical entities and 285 person relationships. Sales & Acquisition held 623 accounts, 634 opportunities and 213 contact or buyer records. These are not customer counts and I am not presenting them as traction. They are operating records. Their value in this article is simply to show that the architecture is being used against hundreds of real objects, not a five-row demonstration database.

That snapshot became stale almost immediately. Later that day I tested whether the Sales system could expand broad-market research through several independent Territory Managers without letting those workers write directly into the canonical CRM. Edmonton alone reached 1,800 provisional organizations across 18 discovery batches. Alberta Regional produced another 1,000 in its first pass and screened 504 of them. Other territories were operating in parallel. The workers could research, screen and prepare evidence, but they minted no canonical Sales IDs and had no authority to contact anyone. Current Sales truth still had one reconciliation path.

The experiment also caught its own mistakes. One Alberta closeout contained a screening-count discrepancy: the durable table held 54 legitimate rows where the summary said 50. A separate queue had carried four research cases forward and later production had not consumed them. The closeout repaired the accounting, preserved the legitimate rows and explicitly dispositioned the missing work instead of deleting records to recover a round total. That mattered more to me than the raw volume. Generating thousands of rows is easy to make impressive. Letting several workers move quickly while still requiring the parent system to detect missing work, reconcile identity and refuse to convert provisional output into canonical truth is much closer to what I mean by leverage.

Networking was running a similar experiment at the same time. Platform workers could create and verify routine relationship edges in parallel while the canonical Relationship Board remained single-writer. On Bluesky, two consecutive 25-account batches were independently verified and moved the account from 145 to 195 following. Other platform lanes were operating at the same time. The canonical Networking board deliberately lagged some of those live edges until reconciliation. That lag was not the system forgetting what happened. It was the distinction between execution evidence and accepted relationship state.

The same separation shows up in product work. During a Clarity App hardening pass I found that one logical checkout could be implemented as several independent writes. In isolated and staging tests, interruption, retry and concurrency could therefore leave inconsistent state. I rebuilt the staging path so the logical provisioning event was handled as one transactional unit with explicit replay and conflict semantics, then tested rollback, replay and concurrency against it.

The staging candidate passed its technical checks. Production and purchases remained intentionally untouched while the candidate waited for founder acceptance.

That is the kind of sentence I want an AI operating system to understand. "Implemented," "tested," "ready" and "authorized" are different facts. A system that collapses them because they all sound positive will eventually hurt you.

Automation follows the same pattern. Eterna can operate browser and local-system mechanics inside bounded work, but Automation is treated as a capability rather than as blanket permission. A platform task can use the browser to inspect or perform already-authorized routine work, while identity, publication, relationship and commercial state remain with their actual owners. The point is not to make the browser autonomous. It is to remove repetitive mechanics without erasing the boundary around the consequential action.

The human role got smaller in mechanics and larger in consequence
There is an easy caricature of governed AI systems where the human has to approve every tool call. That would defeat much of the point for me. I did not spend months building this so I could become a full-time permission dialog.

The goal is to move human judgment to the places where human judgment actually matters. I want routine work inside a clearly authorized lane to keep moving without me supervising every mechanical step. I want the system to stop when a real boundary is reached: a protected decision, unresolved ownership, a material change in scope, a consequential external effect that was not authorized, or evidence that the result cannot be verified.

There are also things I deliberately do not want the AI to own. Product direction is ultimately mine. A technically valid release is not accepted until the real customer experience passes the test that matters. A model-training run does not decide that its candidate should enter production. A score does not decide that a human relationship should be contacted. A generated brand asset does not become canonical because it looks polished.

Some of the best corrections in Eterna came from very ordinary human reactions. I once had a synthetic company corpus that passed structural automation and still looked fake the moment I reviewed it like a customer. I rejected it and rebuilt the synthetic business so the documents, people, jobs, equipment, transactions and cross-file identifiers behaved like one coherent world. In another case, it was technically convenient to defer HEIC support until I asked the obvious customer question: what happens when someone uploads a normal photo from an iPhone? The acceptance test changed.

The Desktop taught the same lesson. I built a technically attractive WebView resource optimization that suspended inactive views. It helped a mechanism and hurt my actual day-to-day workflow. I rolled it back. A synthetic test that says a component can sleep and wake is not the same as a person doing real work across multiple live contexts all day.

Human judgment in Eterna is not a ceremonial "human in the loop" badge. It is a recognition that the system is supposed to serve reality, and reality includes taste, customer behavior, strategy, consequence and the way work actually feels to operate.

The moving frontier changed the experiment while it was running
The timeline makes this entire project harder to evaluate and more interesting at the same time.

If the technology stack had been frozen in June, Eterna would have evolved differently. Sol had not yet launched in ChatGPT. ChatGPT Work had not launched. The App Directory had not yet been replaced by the Plugin Directory. The final 2026-07-28 MCP specification had not shipped.[1][2][3][4] Other provider interfaces and model capabilities were also changing around the same period. What I cannot isolate cleanly is the causal contribution of each release because I was changing Eterna at the same time.

That means the project has a moving control condition. My skills improved. The architecture improved. The models improved. The provider surfaces improved. The protocols improved. I cannot take today's result and assign a percentage of it to each variable after the fact.

I can, however, observe the interaction. Better models let me solve harder semantic and technical problems. Better tools reduced the amount of custom glue I needed. Better integration standards made typed capabilities more practical. Then, as those capabilities became dependable enough to use, Eterna absorbed them into stricter deterministic contracts. The frontier expanded what I could build, and the system responded by making itself less dependent on the frontier model for routine mechanics.

That feedback loop is one of the most important things I would want another founder to notice. The opportunity is not simply "models are getting smarter." The opportunity is that models, tool protocols, provider surfaces, local runtimes and ordinary software are improving together. A small operator can now compose capabilities that would previously have required either a team or a much larger amount of custom engineering.

The danger is that a system built directly on the current provider interface may become obsolete just as quickly. That is why Eterna tries to make the provider replaceable. I want to benefit from the moving ceiling without making the company itself part of the ceiling tile.

What the research did, and did not, tell me

When I eventually dug deeper into the literature, the most humbling discovery was how old many of my "new" problems were.

Saltzer and Schroeder were writing about least privilege, fail-safe defaults, complete mediation and economy of mechanism in 1975.[5] Bainbridge's 1983 paper on the ironies of automation described a problem that still feels uncomfortably modern: the more automation handles routine work, the more the human can be left with unusual situations that are harder to understand and recover from.[6] Modern work on compound AI systems makes the case that application quality increasingly depends on the system around the model, not only the model itself.[7] Dwork and colleagues' work on reusable holdouts gives a rigorous reason to distrust an evaluation set after you repeatedly adapt against it.[8] Local-first research makes a strong case for user control and durable local ownership while also exposing tradeoffs rather than pretending "local" is a magic synonym for reliable.[9]

Those references do not prove Eterna. They are useful because they attack the temptation to describe Eterna as a collection of unprecedented insights.

The pattern I find more interesting is independent practical convergence. I would hit a failure, form a rule, implement it, test it, and later discover a mature field had already developed language for a closely related problem. Sometimes the literature strengthened the rule. Sometimes it made the boundary clearer. Sometimes it made me realize I was overgeneralizing from my own experience.

The order matters. If I rewrite the history as "I read a paper about least privilege and built an AI operating system around it," I would be lying. The actual path was messier: AI overreached, state drifted, tools produced false confidence, recovery failed, tests lied, and I kept narrowing responsibility until the architecture began to resemble principles that software and human-factors researchers had been studying for decades.

There is also research that should make me less confident, not more. Automation can create new supervisory burdens. Centralizing an operating architecture can create bottlenecks. Human oversight can become rubber-stamping when the system moves too fast. Local control can trade away convenience or collaboration. More gates can make a system so expensive to operate that users route around them. A single-founder environment may hide coordination problems that appear immediately with ten employees. Those are not theoretical objections I want to wave away. They are tests the architecture still has to face.

That is what I mean by scholarly rigor here. It is not a large bibliography. It is being clear about the unit of observation, the evidence, the counterexamples, the unknowns and what would make the thesis weaker.

So what would falsify the leverage claim?

The easiest way to make a founder story sound impressive is to define success so the story cannot lose. I do not want to do that.

If fresh reasoning sessions repeatedly cannot resume real work without me manually reconstructing hidden context, then Eterna's continuity claim is weak. If switching frontier providers forces me to migrate company state or rewrite core business logic, provider independence is mostly theatre. If the owner model creates more coordination cost than the conflicts it prevents, it is overbuilt. If verification and governance consume so much time that useful throughput falls below a simpler system, the control architecture has failed economically even if it is elegant technically.

The local AI claim should fail if the bounded model does not beat a simpler deterministic method or a reasonable frontier route on the actual task. The evaluation system should fail if a candidate can overfit its gates without being caught by retained or independent tests. The recovery architecture should fail if a broken component can still take its recovery path down with it. The business-surface architecture should fail if Platform Manager, Networking and Sales keep duplicating or contradicting the same facts despite the owner boundaries.

The largest unknown is scale. Eterna has been built around one operator and a small company. That is part of why the whole system can still be inspected end to end. It is entirely possible that some of the design that creates leverage for one founder becomes an organizational constraint for a larger team. I do not have evidence yet to claim otherwise.

I also have selection bias everywhere. I chose the problems worth fixing. I chose many of the tests. I am both the founder and a major source of qualitative evidence. Some of the academic mapping happened after the practical discovery, which creates obvious confirmation-bias risk. The first roughly three months is also a very short window for judging long-term maintainability.

Those limitations make the result less universal. They do not make the result uninteresting.

The blueprint I would actually give someone

If you want to build your own version, I would strongly recommend that you do not start by copying Eterna. Do not create nine owner domains, 79 operations, a custom Windows workspace, a local language model and a giant folder tree because you saw them here. Those are answers to problems I accumulated. Your first useful version can be dramatically smaller.

Version 0: make the work survive the chat

Start with a durable work store. SQLite is enough for many people. A small Postgres database, a structured file store or another conventional system is fine too. For each meaningful work item, preserve at least an ID, objective, current state, owner, next action, blockers, important decisions, evidence references and an updated timestamp.

Then run the test that matters: open a completely fresh AI session and see whether it can understand the current work from that store without asking you to replay the old conversation. If it cannot, improve the durable state before you add more agents.

Create a simple workspace around this. It does not need to be a custom desktop. It can be a web app, a folder, a database view or a small internal tool. The requirement is that AI enters the work rather than the work living only inside the AI.

Version 1: separate truth from intelligence

Write down the categories of state your business actually has and give each a natural authority. Code might be GitHub. Customer data might be your application database. Accounting belongs in the accounting system. Current calendar state belongs in the calendar provider. Editorial source might belong in a controlled repository. Relationships and sales opportunities may need different records even if the same company appears in both.

Do not copy everything into a universal database merely because centralization feels clean. Build derived views when you need a unified picture. The test for this version is a contradiction: when two systems disagree, can you identify which one actually controls the fact without asking an AI to guess?

Also distinguish current state from history. Old reports, completed Jobs, chats and research can remain valuable evidence without silently competing with the current owner.

Version 2: build one operating loop before you build autonomy

Create a small request envelope. It should carry the intent, consequence class, likely owner, exact target references, allowed capabilities and the verification requirement. I use five broad effect classes: conversation, read, proposal, write and protected. You can use different names. The important part is that reading a system and changing it are not treated as the same permission.

For a consequential write, resolve the owner before execution. Load only the context required for that owner and target. Let the model reason. Route the action through a bounded capability. Then check the actual post-condition and keep a receipt.

Your test is simple: deliberately create a case where the model has the capability to perform an action but lacks the required authority. The system should stop the action mechanically. Then create a valid authorized case and make sure the system can complete it without you babysitting every step.

Version 3: move exact mechanics out of the model

Make two columns for your recurring workflows. In the first, put tasks that genuinely require interpretation: messy language, research, comparison, synthesis, ambiguity, classification and planning. In the second, put things you already know exactly: IDs, permissions, schemas, state transitions, hashes, expected prior state, transaction rules, retries, evidence bindings and receipt formats.

Use AI for the first column. Write software for the second.

This one habit will probably save you more money and failure than almost any prompt technique. If a mistake keeps recurring and the correct relationship can be stated as an exact rule, stop asking the model to remember the rule. Encode it.

Then add regression tests. When you fix one AI behavior, measure what else changed. A candidate that improves the target and damages retained behavior is not an improvement.

Version 4: make providers capabilities, not homes for the company

Once the lower layers work, add provider adapters. GitHub, Drive, email, databases, browser systems, payment systems, AI providers and local tools should have typed ways to read or act. Preserve the provider's real authority where it owns the state. Do not pretend a copied mirror is fresher than the provider unless you have explicitly designed that ownership transition.

This is also when a local model may become useful, but only if you can name the bounded task and measure it. Do not add local AI because "local-first" sounds sophisticated. A four-billion-parameter model on ordinary hardware can be useful when the operating system narrows its job. It is not a free replacement for a frontier model.

Run a provider-swap test. Can another frontier model enter the same work without moving your durable state? Can a provider outage degrade a capability without deleting your understanding of the business? If the answer is no, you are still provider-bound at the architecture level.

Version 5: build the company around its domains, not around the chatbot

Only now would I build specialized operating surfaces. Sales should model sales. Research should model research. Publishing should model platforms and publications. Relationships should model people and history. Product release should model environments, versions and acceptance. Put AI inside those surfaces where it helps.

You probably do not need Eterna's Control Center, Knowledge, Lab, Studio, Platform Manager, Networking and Sales architecture exactly as I built it. What you need is the principle that a shared engine can coordinate different domains without erasing their boundaries.

At this stage the interface test becomes human. Does the system make the real work easier to see and operate, or has the architecture become something you spend your day servicing? If the machinery is getting stronger while the operator experience is getting more complicated, keep simplifying.

What I would not build again

I would not start with a local model. I would not start with a vector database. I would not build a multi-agent swarm because agent diagrams look advanced. I would not keep raw chat transcripts as the company's memory. I would not create duplicate "backup truths" in several systems. I would not let one score silently combine evidence, opportunity, permission and risk. I would not treat a staging build as production because CI is green. I would not build a giant governance layer before I had failures worth governing.

Most importantly, I would not begin by asking how autonomous the AI can become.

I would begin by asking what the business cannot afford to misunderstand: which facts must be current, which effects have consequences, what remains human-owned, what must survive a restart, and what evidence is required before the word "done" is true. Then I would automate outward from those boundaries.

That order is much less exciting than starting with an agent that can click everything. It is also how I would get to useful autonomy faster now.

What I think actually happened

When I started, the frontier model felt like the system because it was the most capable thing in the room. It could write code I could not yet write, explain infrastructure I did not yet understand, research unfamiliar problems and let me move at a speed that was completely new to me.

Less than three months of pushing that idea into real company work changed my view. The model remained valuable, but every painful failure drew another boundary around it. State moved into databases and owner systems. Recovery moved into software. Exact relationships became contracts. Repetitive mechanics became typed capabilities. Evaluations became harder to game. Product acceptance moved closer to real human behavior. The workspace started reflecting the company instead of the current conversation.

At the same time, the frontier itself kept improving. Sol arrived. Work and connected capability surfaces improved. MCP evolved. Other providers and tools got better. I was able to keep reaching for more difficult work because the technology was changing underneath me, and then I was able to pull more of the resulting mechanics back into deterministic software once I understood them well enough.

That combination is the reason I think the leverage question matters. The opportunity is not that one founder can pretend to be a hundred employees by generating a hundred streams of AI output. Output is cheap. Coordination, current state, judgment, verification and recovery are the expensive parts.

What feels new to me is how much of that coordination can now be compressed into a small environment when frontier intelligence is available on demand but is not required to own the company. A single founder can borrow extraordinary reasoning, connect it to conventional software, preserve what it learns outside the session, and gradually turn repeated reasoning problems into ordinary mechanisms.

I do not know yet where that curve ends. I do not know whether Eterna's architecture will look naive in another three months. Based on the last three, I would be surprised if parts of it do not.

Even this article became slightly outdated before I published it. On September 8 I changed the Engine again because another distinction turned out to matter: a logical unit of work, the permission segment that authorizes action and an execution attempt are not the same lifecycle. The bounded change was implemented, promoted and live-verified, passed 45 of 45 qualification checks, and did not require expanding the Universal MCP interface or changing the Core schema. That is probably the most honest thing I can say about the architecture. The mechanisms are still changing quickly. The boundaries are becoming clearer.

The PC beside my desk is still ordinary. The local model can be off. The frontier model can change. The files, work, product state, research and business records remain where they belong. That is the part I was trying to build, even before I had the language for it.

Selected references

OpenAI. GPT-5.6: Frontier intelligence that scales with your ambition. July 9, 2026. https://openai.com/index/gpt-5-6/
OpenAI. Model Release Notes: Introducing GPT-5.6 Sol in ChatGPT. July 9, 2026. https://help.openai.com/en/articles/9624314-model-release-notes
OpenAI. ChatGPT Release Notes: Introducing ChatGPT Work. July 9, 2026; and Plugins in ChatGPT and Codex, documenting the July 9 App Directory to Plugin Directory migration. https://help.openai.com/en/articles/6825453-chatgpt-release-notes ; https://help.openai.com/en/articles/20001256/
Model Context Protocol. The 2026-07-28 Specification. July 28, 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
Saltzer, Jerome H., and Michael D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE 63(9), September 1975, 1278-1308.
Bainbridge, Lisanne. Ironies of Automation. Automatica 19(6), 1983, 775-779. DOI: 10.1016/0005-1098(83)90046-8.
Berkeley AI Research. The Shift from Models to Compound AI Systems. 2024.
Dwork, Cynthia, Vitaly Feldman, Moritz Hardt, Toniann Pitassi, Omer Reingold, and Aaron Roth. The Reusable Holdout: Preserving Validity in Adaptive Data Analysis. Science 349(6248), 2015, 636-638. DOI: 10.1126/science.aaa9375.
Kleppmann, Martin, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software: You own your data, in spite of the cloud. Onward! 2019. DOI: 10.1145/3359591.3359737.
Walsh, James P., and Gerardo Rivera Ungson. Organizational Memory. Academy of Management Review 16(1), 1991. DOI: 10.5465/AMR.1991.4278992.
Wegner, Daniel M. Transactive Memory: A Contemporary Analysis of the Group Mind. 1987. DOI: 10.1007/978-1-4612-4634-3_9.

A Business as a Connected System | Custom Clarity Workflow Map

Jesse Gamble — Sun, 06 Sep 2026 17:18:34 +0000

A business works as a connected system whether its tools were designed that way or not. Research affects content, content moves through platforms, visibility creates relationships and opportunities, sales creates customers, operations delivers the work, and reporting should improve what happens next.

Custom Clarity focuses on the operating layer that keeps those handoffs coherent: context, current state, routing, coordination, decisions and feedback. Supporting technology matters, but it works best when it serves a clear operating model rather than becoming the operating model.

This graphic shows that full loop in one view.

BusinessOperations #WorkflowDesign #OperationsManagement #BusinessSystems #EternaClarity

What Is Custom Clarity? | Eterna Clarity

Jesse Gamble — Sun, 06 Sep 2026 13:31:32 +0000

Custom Clarity is for business owners who are tired of being the system their business depends on.

In this short founder video, Jesse explains why Eterna Clarity built Custom Clarity: to help businesses create the systems, workflows, and connections they actually need - without forcing them into enterprise software or replacing tools that already work.

If part of your business still depends on you remembering every step, moving information manually, following up across disconnected tools, or holding the whole process together yourself, that’s exactly the kind of problem Custom Clarity is designed to solve.

We start with the friction. We connect what already works. Then we build what’s missing.

Whether you need a focused fix or a larger system, we’ll give you a clear path forward with scope and pricing upfront.

Learn more about Custom Clarity:
https://www.eternaclarity.com/customclarity/

Your Company Does Not Have 20 Profiles. It Has One Presence Graph.

Jesse Gamble — Fri, 04 Sep 2026 04:43:57 +0000

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.

Over the last couple of weeks, Eterna has been establishing and cleaning up its presence across LinkedIn, Reddit, Bluesky, DEV, Tumblr, Pinterest, X, directories, marketplaces and other public surfaces. Looking at that work one platform at a time makes it feel like a social-media problem.

I increasingly think that is the wrong way to see it.

A person encountering Eterna does not experience ten platform strategies. They experience one company from whichever direction happened to lead them there.

A stranger is trying to resolve one company

Someone might first find an Eterna article on DEV, search the company afterward, open the website, look up the founder on LinkedIn and later encounter a product or directory listing somewhere else.

Internally, those are completely different systems. To that person, they are one investigation.

They are gradually answering basic questions. Is this company real? What does it do? Does what I am seeing here agree with what I saw somewhere else? Is there enough substance to keep looking? If I want to know more, where do I go next?

That is why Eterna now thinks about public presence as a graph rather than a collection of isolated accounts.

Profiles are only useful if they contribute something

The graph itself is not complicated. A website is one point. A founder profile is another. Company pages, articles, directories, products, communities, marketplace profiles and relevant external mentions create other places where somebody can encounter or verify the business.

What matters is how those points relate.

Does the founder clearly connect to the company? Does an article lead somewhere useful? Does a directory describe the same business the website does? Can somebody move from discovering Eterna to understanding it without hitting contradictions, abandoned profiles or dead ends?

Eterna's current internal Presence Graph contains 264 relevant entities, 126 recorded relationships and 133 possible future opportunities. I do not consider those numbers achievements by themselves. They are useful because they help show where the company is connected, where it is weak and where another action might actually improve something.

That is very different from counting profiles.

This changed how I think about publishing

Baseline content matters. An empty company profile is not very useful because someone can discover it and still learn almost nothing.

Eterna needed enough good material across its important surfaces to establish that baseline. Once it exists, though, the logic changes.

If I manage each platform independently, every account looks hungry. LinkedIn could use another post. Bluesky could use another post. Tumblr could use another article. Another platform has not been updated recently.

That can turn publishing into feeding machinery the company created for itself.

Looking at the whole presence produces a better question: what would actually make Eterna easier to discover, understand, verify or connect with?

Sometimes the answer is another piece of content. Sometimes it is improving a profile, fixing a stale description, establishing a legitimate directory listing, connecting two identities properly or doing nothing because that surface is already doing its job.

Activity and progress are not the same thing.

Different parts of the graph have different jobs

Follower count still matters, but it is a local measurement.

One platform might have very few followers while giving Eterna a useful foothold in a technical community. A directory may never create an audience at all, yet still help confirm that the company exists. A marketplace profile could be irrelevant as a content channel and valuable if one qualified buyer eventually discovers it.

Those surfaces should not be judged by the same metric because they are not doing the same job.

This is also why copying the same strategy everywhere makes little sense. A useful article on DEV, a strong company page on LinkedIn and a credible marketplace profile can all strengthen Eterna's public presence in completely different ways.

The question is not whether every node is active. It is whether each important node has a reason to exist.

Strong presence creates corroboration

There is a meaningful difference between repeating the same claim everywhere and giving somebody several independent ways to verify the same company.

Eterna's website saying Eterna exists is expected. The founder connecting clearly to the company adds something else. Consistent product identities add more. External directories, communities, articles and other public surfaces provide additional context from different directions.

The copy does not need to be identical everywhere. It should not be. What needs to stay consistent is the underlying identity and reality of the business.

A company becomes harder to trust when its website describes one thing, an old profile describes another, the founder relationship is unclear and half the links lead nowhere. None of those problems are solved by increasing posting frequency.

Relationships are part of presence too

This became even clearer when Eterna separated platform management from networking.

Maintaining an account and building a relationship are different jobs. Software can discover hundreds of relevant founders, businesses, investors, communities and organizations without that discovery needing to turn into hundreds of follows, connection requests or messages.

Eterna's networking model deliberately allows broad discovery and much narrower action. A relevant company might simply be worth following and learning from. A community might deserve participation. A stronger relationship might eventually lead to a conversation, partnership or commercial opportunity.

That creates something content alone cannot create: context between Eterna and the people or organizations around it.

A network is not the number of actions performed. It is the useful relationships that remain afterward.

The best audit starts outside the company

There is a simple way to inspect this without any graph software. Pretend you have never heard of the company and search for it.

Search the company name, founder and products. Open the results that look important and follow the paths between them. Pay attention to where the company becomes easier to understand and where the trail breaks.

That exercise reveals stale identities, weak profiles, contradictions, dead ends and missing connections very quickly. It can also reveal that a surface everyone has been worrying about does not actually matter very much.

Most importantly, it changes the objective. The goal stops being to keep every account moving and becomes making the company easier to resolve from wherever somebody encounters it.

Eterna will keep publishing, but I have become much less interested in producing content simply because another feed exists. I would rather add something that makes the whole presence stronger and can keep doing that work after the day it was published.

Read the original article on Eterna Clarity.

If Your Score Always Agrees With You, You Built a Mirror

Jesse Gamble — Fri, 04 Sep 2026 04:41:00 +0000

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.

I recently built a scoring system to help Eterna decide which businesses looked like the strongest opportunities for Custom Clarity. Then I gave it an important rule: if the ranking surprised me, I was not allowed to change the scoring simply because I preferred the old answer.

That became much more important than I expected. By the time I designed the model, I had already researched many of the companies and formed opinions about which ones looked strongest. It would have been very easy to build something that turned those opinions into numbers and then call the result objective.

A number can make an opinion look scientific

Eterna needed a better qualification method because a business can look promising from a distance for all kinds of bad reasons. A weak website does not prove weak operations. Hiring activity can mean growth, turnover or neither. A company can appear digitally unsophisticated while running excellent internal systems that are simply invisible from the outside.

So the new model stopped asking for one vague judgement and started examining several dimensions separately. It also distinguished the apparent quality of the opportunity from the quality of the evidence supporting that conclusion.

That distinction matters. Two companies might both appear to be strong opportunities, but one conclusion could be supported by several independent signals while the other rests mostly on inference. Giving both businesses similar scores without representing that difference would create precision that the research had not earned.

A score tells me what the evidence appears to suggest. The evidence grade tells me how seriously I should take the score.

The strange rankings were the valuable ones

I ran the new system against an existing batch of 25 companies before allowing it to replace the earlier qualification method. For each business, I compared the old ranking, the new ranking and a fresh human review.

The important part was what happened when they disagreed. Instead of adjusting weights until the order looked familiar again, I treated the disagreement as something that needed an explanation.

Sometimes the model might be overvaluing a particular signal. Sometimes the original judgement might have been too generous because the business looked like an easy fit. Sometimes important information could be missing, or a public signal could mean something different from what I first assumed.

All of those possibilities are useful. If I change the model every time it produces an answer I dislike, I eventually get a scoring system that is exceptionally good at agreeing with me.

That is not independent judgement. It is a mirror with arithmetic.

Human judgement still matters

I do not want a scoring model making these decisions by itself. Public information is incomplete, businesses are messy, and context often changes the meaning of a signal.

Human judgement becomes especially valuable when the result looks strange. The mistake is using that judgement as an invisible answer key where every disagreement automatically means the model must be wrong.

That problem exists far beyond sales. A hiring rubric can slowly be adjusted until it ranks the candidates a manager already likes. An investment model can be refined until favourite companies rise back to the top. A product-prioritization framework can become a complicated way of justifying decisions that were already made.

The moment you know the result you want, every change to the scoring method deserves more scrutiny.

A useful question is simple: did I discover a flaw in the model, or am I uncomfortable because the model challenged one of my assumptions?

Test it on cases that did not create it

There was another problem with the first 25 companies. They had already influenced how I thought about qualification.

Their failure modes helped shape the new model. The weird cases I encountered helped determine what the system needed to consider. Even without intentionally fitting the model to those companies, they were part of its education.

So the next test needed businesses I had not used while designing it. I chose a separate set from outside Alberta and planned to run the same method without changing the rules first.

That is a useful test for almost any decision framework. If you develop a hiring rubric by studying your best employees, try it on people who were not part of that analysis. If you create a project-risk framework after three painful failures, see what it says about projects that had nothing to do with those failures.

A framework that explains the examples used to create it may simply be a good description of those examples. The more interesting question is whether the reasoning still works somewhere new.

The score should guide attention, not create certainty

One of the easiest mistakes with scoring systems is treating the ranking as the decision itself.

If a company scores highly, that does not automatically make it a lead. It means the available evidence suggests that company deserves more attention than another one. Further research may strengthen the case, weaken it or reveal that the opportunity was never real.

That has become an important boundary in Eterna's acquisition work. Discovery can be broad and inexpensive. Qualification should be more demanding, and contacting a real business should require stronger evidence again.

The score helps decide where to spend the next unit of research. It does not create entitlement to somebody's attention.

That also makes uncertainty easier to handle. A company does not need to be labelled good or bad before enough is known. Sometimes the right state is simply promising, but poorly evidenced.

A useful model should be able to surprise you

I built the qualification system because I wanted Eterna to make better decisions about where Custom Clarity might genuinely be useful. The most valuable thing it can do is not reproduce my judgement more neatly.

It can force vague impressions into rules that can be inspected. It can apply the same questions more consistently than I might. Most importantly, it can produce a result that makes me stop and look again.

Sometimes that second look will expose a bad assumption in the model. Sometimes it will expose one in mine.

If every result confirms what I already believed, I have learned almost nothing.

Read the original article on Eterna Clarity.

The GPT-6 Astra Waiting Room

Jesse Gamble — Fri, 04 Sep 2026 01:51:12 +0000

Apparently the future is here. I just don’t have access to it yet.

So, like any completely normal person, I’ll be checking ChatGPT every 14 minutes until Astra decides I’m worthy.

See you all in the waiting room.

How Eterna Turns Intelligence into Reliable Execution

Jesse Gamble — Wed, 02 Sep 2026 11:29:48 +0000

One of the biggest changes in how I think about AI has been realizing that the model should not have to be the system.

A model can be excellent at reasoning and still be the wrong place to keep durable company state. A tool can be technically accessible and still not be authorized for a particular action. An automation can report success and still leave you needing to verify whether the intended change actually happened.

Those distinctions became increasingly important as Eterna moved from individual AI-assisted tasks into real operating work.

The architecture in this graphic is the result.

Work enters the Eterna Engine from requests, files, events and connected systems. The Engine first resolves what the work actually is, then identifies the authority and current context that matter. From there it routes the task toward the simplest capable path.

Sometimes that is exact deterministic software.
Sometimes it is EternaAI / local intelligence.
Sometimes frontier intelligence is worth using.

But none of those reasoning paths silently become the authority for the company.

Execution happens through bounded capabilities and the correct owning route. Verification then checks evidence and actual state before a result is treated as real. If something genuinely changed and deserves to survive, finalization can return that durable delta to the system that naturally owns it.

The line that best explains why I care about this is still:

“I want to be able to change the intelligence without moving the company.”

Models will keep changing. Providers will keep changing. The useful challenge is to build the surrounding system so better intelligence can be adopted without making the work itself dependent on a single conversation or model.

Models reason. Owners hold truth. The system verifies effects.

Which layer do you think most AI systems underinvest in today: context, authority, execution, or verification?

A Product Is Not Finished When the Frontend Is Finished

Jesse Gamble — Wed, 02 Sep 2026 03:19:15 +0000

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.

Some of the most misleading moments in building software happen when the page looks finished. The button is there. The layout is polished. The flow works in a test account. The code has been merged. It is very easy to look at that and think the product has moved forward. Then production reminds you that a product is larger than its frontend.

I learned this repeatedly while building Eterna Clarity. A customer-facing change could depend on application code, a database function, authentication, storage rules, an email template, environment configuration and the way a demo account was isolated from real customer data. If one of those pieces stayed behind, the screenshot could be correct while the product was not. That changed the way I think about releases.

A release is not “the code shipped.” A release is the smallest complete set of owned systems that have to advance together for the accepted behavior to become true in production.

The browser can hide a lot of unfinished work

Frontend work is unusually visible. That makes it easy to use as a proxy for progress.

Back-end state is less visible. So are permissions, production configuration, storage policy, transactional email, tenant boundaries and data migrations. They tend to reveal themselves only when something goes wrong.

That asymmetry can create a strange kind of false confidence. A team can spend hours polishing the thing a customer sees while the systems underneath it still describe an older product. In Eterna, the correction was to stop treating the repository as the whole release.

Source code still matters. It is simply one owner among several.

If a new customer flow requires a database change, the production database has to advance. If it requires a new authentication behavior, the production auth configuration has to advance. If it depends on storage permissions, those permissions have to exist in the production environment. If a transactional email is part of the experience, that email has to match what the product now does. The visible feature is only truthful when the dependencies that make it real have moved with it.

Staging should be a rehearsal, not a different product

Eterna Clarity eventually settled on a simple product rule: Personal Clarity and Business Clarity are the two canonical dashboard implementations. Staging and production are environments around those products, not separate products themselves. That distinction prevented another form of drift.

It is tempting to create a special testing version, a special demo version, an admin version and a customer version, then patch each one until it behaves correctly in its own context. The immediate problem gets solved. The long-term cost is that the company now owns several slightly different products.

Eterna's adopted architecture goes the other direction. The accepted Personal implementation is promoted into production and serves the appropriate Personal demo and customer experiences. The Business implementation does the same for Business. Identity, data, permissions and access mode create the differences. The core product does not get copied for every audience. That matters because every independent copy creates another place a fix can be forgotten.

A demo should demonstrate the product a customer will actually receive. An admin inspection surface should inspect the real product, not become a privileged fork with its own design. A customer should not get a copied frontend that now needs a private maintenance branch. The fewer independent implementations you create, the fewer accidental products you have to run.

Environment isolation and product consistency are not opposites

Staging should resemble production closely enough to make its testing useful. It should not share production customer data simply to achieve that resemblance. Those are different requirements.

Eterna keeps staging and production isolated at the data and environment level. Test users, test uploads, synthetic records, sessions and credentials remain test-owned. Production customer state remains production-owned.

At the same time, the system definition needs to stay aligned. A feature accepted in staging should be promoted deliberately so the production application and the production services it relies on express the same accepted behavior.

This is a well-established deployment principle. The Twelve-Factor App describes the value of keeping development and production close enough that environment differences do not become a constant source of surprises. Microsoft similarly recommends staging environments that reflect production closely enough for meaningful validation while maintaining clear production boundaries. The useful tension is this: make the environments similar in definition and separate in state. That is much more precise than saying staging should “be like production.”

Demo mode deserves real architecture

Public demos exposed another lesson. A demo can be treated as marketing decoration: a fake account with a few neat records designed to make the screen look populated. That is easy to build and surprisingly dangerous.

If the demo is supposed to prove the product, it needs to obey the product's real constraints. The data can be synthetic, but the behavior should be authentic. Read-only mode has to be real. Customer information must stay isolated. Totals, scores and visible state should be possible under the actual backend. The demo should not quietly use a different application because that version is easier to make impressive.

This forced Eterna to care about things that do not normally show up in a screenshot. Does the backend support the volume being depicted? Does the score shown on the page come from the real score logic? Does “View all” have enough underlying data to mean anything? Can a public user accidentally mutate state? A good demo is a product test wearing marketing clothes.

Production acceptance has to follow the changed surface

I do not think every release needs a giant universal checklist. The acceptance should follow the actual change.

A copy edit does not need the same release proof as an authentication rewrite. A storage change may need security and tenant-isolation checks that a visual spacing fix does not. A new payment flow has owners and consequences that a dashboard label does not. What matters is identifying the affected systems before declaring success.

For an Eterna Clarity release, that may include source code, database definitions, storage, auth, serverless functions, transactional email or other provider configuration. The exact set changes with the feature.

Then the test needs to reach the real destination. If the feature is supposed to work for a customer in production, a local build passing is evidence about the local build. It is not evidence that the customer workflow works in production.

This sounds strict, but it actually prevents a lot of waste. The fastest way to create repeated release work is to discover dependencies one at a time after the frontend has already been called complete.

Shared products make later work cheaper

There is a business reason for this architecture beyond clean engineering. If every customer receives a copy of the product, every customer becomes a maintenance surface. If the demo is a separate app, the demo becomes a maintenance surface. If the admin experience reimplements customer screens, admin becomes another maintenance surface.

A shared implementation changes that economics. One accepted product improvement can reach current customers, future customers and the demo through the same controlled release path. Differences come from data and permissions rather than copied application code.

That is especially important for a small company. I do not want future growth to multiply the number of frontends Eterna has to remember to fix.

Ask what has to be true, not what has to be merged

The question I use now is: what has to be true for the customer to actually have this feature? That usually produces a better release boundary than asking which pull request contains it.

Maybe the answer is only code. Often it is not.

The database may need a new function. A permission may need to change. A provider setting may need to exist. A migration may need to run. An email may need to be updated. A test environment may need new synthetic state. A production path may need to be inspected with a real account.

Once those owners are visible, the release gets easier to reason about. You are no longer trying to make “deployment” mean everything. You are moving a set of real systems into one accepted product state.

The frontend still matters enormously. It is where the customer experiences the work. It just should not be allowed to declare the rest of the product finished on its behalf.

AI disclosure: This article is based on my own Eterna build notes and experience. I used AI as a drafting and editing partner; I reviewed the final piece and stand behind the technical substance and claims.

The AI Had an Authoritative Source. It Was Still Wrong.

Jesse Gamble — Wed, 02 Sep 2026 03:18:29 +0000

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it.

One of the most reassuring things an AI can do is show you where its answer came from. Search the web. Retrieve the document. Cite the source. Point to the record that supposedly supports the decision. That is a real improvement over asking a model to answer from memory and hoping it remembers correctly.

It also creates a failure mode I did not fully appreciate until Eterna produced one in front of me: the source can be real, trusted and authoritative, and the decision can still be wrong.

The simplest version is this. The AI had multiple candidates it could select. It chose one of them and cited authoritative evidence as support. The evidence really was authoritative. The problem was that it was authoritative about something else. The verifier knew the source was allowed to carry authority. It did not yet know whether that source actually supported the specific candidate the AI had selected. That is a very different problem from a fake citation.

A trustworthy source is not the same thing as relevant proof

Humans make this mistake too. A signed purchase order can be completely authentic without approving every purchase in the folder. A current company policy can be authoritative without proving that a specific proposal was adopted. A bank statement can be genuine without proving that a particular invoice was paid. The evidence is not false. The relationship is false.

That distinction matters enormously in AI systems because retrieval and citations can make an answer look grounded even when the grounding is weaker than it appears. There are really several questions hiding inside the word “evidence.” Is the source genuine? Is it authoritative for this kind of fact? Is it current enough to use? Does it actually support the claim or action being proposed?

Eterna already had a deterministic gate for one of those questions. If a model wanted to make a selection in a protected decision path, it had to cite authoritative evidence. Fresh relational tests exposed the missing question: authoritative for what? A stale or proposal-status candidate could still borrow an unrelated authoritative evidence reference and satisfy the general rule. The model had not fabricated the source. The verifier had not accepted an untrusted source. The failure lived in the relationship between the two.

The most important part: I did not fix the model

My first instinct earlier in this project would probably have been to think in model terms. Better prompt. Better training example. Another fine-tune. Teach the model more carefully that one kind of source should not justify another kind of decision. That would have been the wrong layer.

Once the system already knows which evidence belongs to which candidate, there is no reason to ask a probabilistic model to rediscover that relationship every time. It is exact state. Software can enforce exact state better than a language model can remember a rule about exact state.

So the fix went into the Engine instead. Evidence records gained an explicit relationship to the candidates they support. In the current implementation that relationship is represented as supportsCandidateRefs. When the strict gate is enabled, a selection now has to satisfy more than “some authoritative evidence was cited.” At least one cited authoritative evidence item has to be deterministically bound to the exact candidate being selected.

If an evidence record claims to support a candidate that was never supplied to the decision in the first place, the request is rejected before inference. The model does not get an opportunity to explain its way around the contradiction.

That correction passed 31 focused tests. The full Local PC regression rerun finished at 369 total tests: 368 passed, zero failed and one intentional skip. The live runtime was reloaded and the new input contract was exercised against the running system. No model weights were trained, and the local semantic runtime remained stopped. The AI behavior improved because I removed a problem from the AI.

This gave me a much cleaner definition of what AI should own

That failure helped sharpen one of the most important boundaries in Eterna. The model is extremely good at things that are hard to specify mechanically: interpreting messy language, comparing ambiguous evidence, understanding what a document appears to mean, synthesizing several signals, ranking plausible options and recognizing when more information is needed. Those are semantic problems. I want AI doing them.

Other things are not semantic problems once the system already knows the answer. Whether an evidence reference exists. Whether it was verified. Which authority role it has. Which exact candidate it is bound to. Whether a capability is currently permitted. Whether the expected prior state still matches. Whether an operation already happened. Whether a write produced a real receipt. Those are state and contract problems. I want software doing them.

The mistake is asking one layer to impersonate the other. If I hard-code a giant hierarchy for every possible meaning of every source, the software becomes brittle and starts pretending it understands semantics. If I ask the model to decide whether exact IDs, permissions, transaction state and known provenance relationships are valid, I am paying an intelligent guesser to do bookkeeping. Eterna's hybrid Engine is built around that separation: deterministic software owns truth and consequence; semantic models own interpretation and proposal.

The AI can propose an action. It cannot make the action true by describing it

That sounds like a small wording distinction until AI starts using tools. A model can propose a typed next transition. The Engine then checks the things that should not depend on persuasion: authority, current preconditions, capability visibility, parameter schema, protected decisions, idempotency, expected prior state, evidence freshness, consequence and reversibility. Only after those checks can deterministic execution occur.

The same rule applies after execution. Model text saying something was written, deleted, approved, adopted or completed is not accepted as evidence that it happened. The system needs the actual operation result and, where the consequence matters, observation of the resulting state. This is one reason I have become much less interested in an AI sounding certain. Certainty is a communication style. A receipt is evidence.

The more capable the model becomes, the more important that distinction gets. A weak chatbot being confidently wrong is irritating. A capable agent being confidently wrong while it can change files, operate systems and influence real company state is a systems-design problem.

Every AI turn now has a check-in and a check-out

The same thinking eventually reached the conversation itself. A substantive Eterna turn does not begin by assuming the chat already knows the company. It resolves the current intent against the systems that actually own the relevant state, compiles the smallest evidence-complete working context, applies the capabilities and operating rules that belong to that task, and issues a turn contract. Then the reasoning and work happen.

Before the turn is handed back as complete, the other side of the contract closes. Durable writes and real side effects are recorded as such. Founder decisions remain founder decisions. Work that produced no durable change is allowed to say so. The system does not need to manufacture a memory merely because a conversation occurred.

The exact mechanics have evolved, but the mental model is simple: check into reality before reasoning, then check back into reality before claiming completion. The chat is not allowed to become the place where truth exists simply because the AI said something convincingly inside it.

This is becoming a frontier agent problem, not an Eterna-only problem

When I compared what Eterna was doing against current agent research, the overlap was striking. OpenAI's recent work on trustworthy evaluations makes the point that agent performance depends on the harness around the model, not only the model itself. Anthropic describes trustworthy agent behavior as a combination of the model, harness, tools and environment rather than a property of the model in isolation.

Recent research is getting even closer to the exact failure I ran into. Work this summer on provenance sensitivity in LLM-agent action selection points out that evidence can be relevant without being authorized to determine a particular action. ToolGate formalizes tool execution around explicit trusted state plus preconditions and postconditions instead of letting natural-language reasoning alone decide what can be committed. Other current provenance work is pushing toward fine-grained links between claims, evidence and actions rather than treating the presence of a citation as the end of verification.

I did not invent provenance, transaction guards or formal verification. Those are old and powerful ideas. What interests me is what happens when you take those ideas seriously around modern AI instead of expecting the model to absorb every reliability requirement into its weights. The result starts looking less like a smarter chatbot and more like an operating system around a fallible but extremely capable reasoner.

The universal rule is embarrassingly simple

A true fact does not prove every conclusion you can place beside it. That is obvious when another person does it. Somebody quotes a real statistic that has nothing to do with the claim they are making and you immediately feel the gap. Somebody produces a real document that does not actually authorize the thing they say it authorizes. The source can be impeccable and the argument can still fail.

AI does not get a special exemption from that logic because it can retrieve the document automatically.

For systems that only answer low-stakes questions, a citation may be enough to help a human check the work. For systems that are expected to choose, act, write, approve, route or change state, I think the standard has to be higher. The evidence needs a relationship to the exact decision being made, and wherever that relationship can be known deterministically, it should not depend on the model's confidence.

That is the architecture I want around AI: let the model do the part that genuinely requires intelligence. Make software prove the parts that do not. The AI can be wrong sometimes; that is an unavoidable property of using a probabilistic system. The company does not have to turn every one of those mistakes into reality.