--- title: "Velacria Field Notes" url: "https://velacria.com/notes/" canonical: "https://velacria.com/notes/" author: "Julien Le Nestour" description: "Short notes, LinkedIn-origin observations, and area-based reading paths on marketing operating excellence in the AI era." --- ## AI operations need operating memory The difference between a useful AI workflow and a demo is whether it preserves judgment, context, and repeatable process. Most AI demos are impressive once. Operational AI has to be useful repeatedly. That means the hard part is not only prompting. It is operating memory: instructions, examples, edge cases, tool permissions, evaluation criteria, client context, known failure modes, and a way to improve the workflow after each run. Skills, MCPs, agents, and workflow harnesses are interesting because they can turn judgment into reusable operating infrastructure. Without that layer, the model is just improvising again. ## AI search still starts with SEO foundations AI optimization is not a clean break from SEO. It raises the bar on entity clarity, structure, and usefulness. AI optimization is not a magic new channel detached from SEO. If a model cannot understand what an entity is, what it is known for, what evidence supports it, and how it relates to adjacent concepts, it is unlikely to recommend it reliably. That means boring foundations still matter: crawlable pages, clear topic ownership, structured data, internal links, consistent naming, useful explanations, and enough public evidence for systems to connect the dots. The interface changes. The need for clarity does not. ## Compliance is an architecture problem The useful privacy work is not saying no to tracking. It is designing the version legal can approve and platforms can still learn from. The weak version of privacy work is treating compliance as a brake. The useful version is treating it as an architecture constraint. What data should be collected? Which platform should receive it? Under what consent state? At what granularity? From browser, server, CRM, or warehouse? With which matching fields? For which business objective? Those questions are technical, legal, and commercial at the same time. If they are answered separately, the result is either risky tracking or compliant underperformance. Good tracking architecture has to make those tradeoffs explicit. ## CRO starts before the test The useful CRO question is not which variant wins. It is whether the hypothesis reflects how people actually decide. A/B testing is often treated as the beginning of CRO. It is usually the middle. Before the test, there is a behavioral question: what is making this decision harder than it needs to be? Is the user uncertain, overloaded, unconvinced, distracted, or blocked by the wrong kind of friction? The test matters. But if the hypothesis is shallow, the test only gives a precise answer to an uninteresting question. ## Nobody owns the tracking stack Most tracking problems are ownership problems before they are technical problems. Most companies do not have one tracking stack. They have layers: old agency work, new agency work, campaign pixels, GTM changes, CMP settings, Meta and Google defaults, a bit of server-side tagging, and a few urgent fixes that nobody documented. The uncomfortable part is not that this is messy. It is that nobody can usually say, with confidence, what is live, why it exists, who owns it, and whether it still matches the current business model. That is why an outside-in scan is useful. It does not replace a proper audit. It creates the first shared object: here is what a public observer can see. Now marketing, legal, analytics, and agencies can talk about the same evidence.