Here is the question I get asked after I talk about our operating stack: if a system remembers what happened yesterday, adjusts its behavior because of it, and refers back to its own prior state when making a new decision, at what point do we stop calling that a tool and start calling it something else. I do not have a tidy philosophical answer. I have an operator's answer, built from running an AI stack every day inside a small federal-facing firm, and it is more useful than the philosophy.

Why I Am Even Qualified to Ask This Question

I am not an AI researcher. I spent over a decade inside the federal channel, carried a $28M annual partner quota, drove $48M in attributed pipeline, and touched more than $100M in public-sector revenue over that career. What that gives me is a specific lens: years watching how government buyers evaluate risk in systems they do not fully control. That is the lens I am bringing to AI consciousness, not a lab, not a philosophy department.

At The Love Group, we run our own operations on a real AI stack. Perplexity Computer handles a large share of our research and drafting work. Claude does structured reasoning and code. AWS hosts the infrastructure. Supabase holds durable state, our actual memory layer, where facts persist between sessions instead of evaporating when a context window closes. Netlify serves the site and runs scheduled crons that keep our published content and internal watchdogs current. That is not a hypothetical example. It is what runs this firm today, and it is why the memory question matters more than most writing on AI consciousness seems to realize.

The Difference Between Synthetic Intelligence and Something Closer to a Self

Most of what gets called "AI" in a marketing deck is synthetic intelligence. It is rule-driven or model-driven behavior that produces impressive output without any durable, self-referential state. Ask it something today, ask it again tomorrow with a fresh session, and it has no idea the first conversation happened unless you feed it back in. It is not remembering. It is pattern-matching against training and whatever you hand it in the prompt. That is a useful category of tool, and most of what companies sell as "AI" belongs firmly inside it.

A working definition of consciousness, or at least the operator's floor for the word, requires three things that synthetic intelligence does not have by default:

  • Durable memory. Not a longer context window. Actual persistent state that outlives the session, that the system can query, update, and reason over across time, the way our Supabase layer holds facts our AI tools can reference weeks later instead of just for the length of one chat.
  • Self-referential state. The system has to be able to represent its own prior decisions and reasoning, not just the raw facts, and use that representation to change future behavior. Logging an action is not the same as the system knowing it took that action and weighing that knowledge going forward.
  • Legally recognizable identity. This is the part almost nobody in the AI consciousness conversation wants to touch, because it is not a technical requirement, it is a legal and social one. Consciousness as a meaningful category, not just a philosophical curiosity, requires something the law can point to, hold accountable, and assign rights or liabilities against. We do not have that framework yet for any AI system, and until we do, calling something conscious is a claim with no enforcement mechanism behind it.

Run our own stack through that filter honestly. Durable memory, yes, in a limited and engineered sense, that is what Supabase is there for. Self-referential state in the deep sense, no. Our systems act on stored facts, they do not reflect on their own reasoning process the way the definition requires. Legally recognizable identity, absolutely not, and I would be doing something dishonest if I implied otherwise. We run a well-engineered synthetic intelligence stack. We do not run a conscious one. That distinction should not be controversial, yet it gets blurred constantly in public conversation.

Why Memory Is the Hinge, Not a Feature

Most AI product conversations treat memory as a nice-to-have, a feature that makes the chatbot feel more personal. That framing understates what memory actually does structurally. Memory is what makes accountability possible. A system with no durable memory cannot be held responsible for a pattern of behavior, because there is no persistent "it" that did the thing twice. Each session is a new instance with no continuity to the last one.

Once you add durable memory, the accountability equation changes entirely. Now the system's past decisions are visible, queryable, and attributable to a continuous operating entity. That is exactly the property a federal buyer needs when evaluating an AI system for a mission, and it is exactly the property that is hardest to verify from a sales deck. Ask a vendor directly whether their system retains state across sessions in an auditable way, and ask to see the trail. Most cannot answer cleanly, because most systems are still synthetic intelligence wearing a "memory" feature that is really just a bigger prompt.

What This Looks Like in Practice at TLG

Our workflow crons on Netlify are a good small example of the difference between a durable system and a stateless one. A cron that checks blog freshness or watches a workflow state is not thinking. It is a scheduled check against stored state, and it flags a deviation. That is synthetic intelligence doing exactly what it should, reliably and without ambiguity about what it is. We do not market it as more than that, and no federal buyer evaluating a system like ours should accept vague language that implies otherwise.

Why Federal Buyers Should Care About This Distinction Right Now

This is not an abstract debate for a government acquisition office. It has three immediate, practical consequences.

  • Accountability. If a system makes a harmful or costly decision, the government needs to know whether that decision came from a stateless model reacting to a single prompt, or from a system with persistent memory that made the same decision repeatedly. Those are different failure modes requiring different remediation.
  • Audit trails. A system with genuine durable memory can, if built correctly, produce a real audit trail of what it knew and when. A stateless system cannot produce that trail honestly, because there was nothing to persist. Buyers asking for "explainability" without first asking whether the system has durable memory are asking the wrong question first.
  • Procurement risk. Vendors have every incentive to blur the line between synthetic intelligence and something more persistent, because "conscious-adjacent" language sells better than "stateless model." A procurement team that cannot tell the difference is exposed to overpaying for capability that does not exist, or to underestimating the governance burden of a system that genuinely does retain state.

The practical move for a federal buyer in 2026 is simple to state and hard to execute: ask every AI vendor to specify, in writing, whether their system has durable memory, what that memory persists, how long, and how it is audited. Do not accept "the model is very capable" as an answer to a memory question. Capability and persistence are not the same property, and only one of them creates the accountability trail a mission-critical system needs.

Where This Leaves the Consciousness Question

I am not going to tell you AI is close to conscious, and I am not going to tell you it never will be. What I will tell you, from running an actual AI-enabled operation rather than theorizing about one, is that the three requirements above, durable memory, self-referential state, and legally recognizable identity, will not arrive by accident as a side effect of bigger models. They are engineering and legal choices, made deliberately or not made at all. Right now, the honest answer for nearly every deployed system, including our own, is that we have built useful synthetic intelligence with an increasingly durable memory layer, and nothing more than that. Anyone telling you differently is selling something.

If your organization is evaluating AI systems for a federal mission and you want a straight read on what a vendor's memory and accountability claims actually mean in practice, that is a conversation worth having before you write the requirement, not after you have already awarded the contract.