DEV Community: Matthias | StudioMeyer

How to Turn ChatGPT Into a Work System

Matthias | StudioMeyer — Fri, 25 Sep 2026 23:35:32 +0000

The answers are good. That is rarely the problem. The problem is that every new conversation starts from nothing, and you explain yourself again.

So you do the obvious thing. You write down everything important in the custom instructions, the field that travels with every conversation. Your role, your company, your tone, your clients, the things it got wrong last week. The field fills up. And somewhere along the way the answers get worse, not better, and it is hard to say exactly when that happened.

What follows is the other approach. Not better prompts, but a place for everything, so the assistant pulls what a task actually needs instead of carrying all of it all of the time.

A Chat Is Not a System

A chat is one conversation. A system is what stays when the conversation is closed.

The difference shows up in a small, ordinary test. Ask the same recurring task twice, four weeks apart, and compare. If the second answer is worse, or simply different in ways nobody decided, then nothing was ever built. The knowledge lived in a chat window, and chat windows are not storage.

Building a system means answering three questions once: how do we work, what are we working on, and what have we learned along the way. Each one belongs somewhere different. Almost all of the trouble comes from putting all three in the same place.

The Standing Instruction Is the Most Expensive Space You Have

Custom instructions apply to every conversation you have, immediately, including the ones already open. That is what makes them useful and that is what makes them dangerous. Everything in there is paid for in every single chat, whether the current task needs it or not.

So the standing instruction should answer exactly one question: how do we work together. How direct you want answers. Whether you want to be asked or told. What to do when something is uncertain. When to push back. Whether you want the reasoning or just the result.

What does not belong there: your price list, your client names, your project status, your product details. Not because it is secret, but because it is specific. A price list in the standing instruction is read during a task that has nothing to do with prices, and it goes stale without anyone noticing, because nobody rereads a field they wrote four months ago.

A good test: if a sentence would be equally true for a task you will never do, it belongs somewhere else.

One Project per Thing, Not per Tool

Projects in ChatGPT hold chats, files and their own instructions in one place, so you do not restate the background every time you open a new conversation.

The useful part is the separation. With project-only memory, conversations inside a project can reference other conversations in that same project, but not the ones outside it, and nothing outside can see in. That is not a small convenience. That is the difference between an assistant that keeps your two businesses apart and one that quietly mixes them.

The mistake worth avoiding is cutting projects by tool or by month. One project for writing, one for research, one for September. Those boundaries do not match how work actually arrives. Cut by subject instead: one client, one business, one product, one recurring job. When a task starts, the right project is obvious, and everything irrelevant stays closed.

Knowledge Goes in Files, Not in Instructions

A project takes files. That is where the actual knowledge belongs, and it is worth being deliberate about how it is split.

One file per subject, not one file for everything. How you position your business. What your brand sounds like. What you offer. How a particular recurring job gets done. Small files with obvious names beat one long document, because the assistant can be pointed at the right one, and because you can fix one without touching the others.

The reason is boring and decisive: the file you fix in passing stays true, and the file you have to rebuild does not. Knowledge that is annoying to correct becomes wrong knowledge.

Loading Everything Is Not the Same as Knowing Everything

This is the principle underneath all of it. Available context is not relevant context.

An assistant with access to your entire business is not more capable than one that opens the two files a task needs. It is less capable, because everything it reads competes for attention with everything else. A text for your homepage needs your positioning and your tone. It does not need last year's invoices, your client list, and a campaign from two summers ago.

In practice this means naming the thing when you start. Not a ritual, just a sentence: we are working on this client, this product, this job. The default state is that nothing specific is loaded, and that default is correct.

Write Down What It Learns, Where You Can Read It

Over months, the useful part is not what the assistant knows about the world. It is what it knows about your work. The decision you made and why. The assumption that turned out wrong. The preference that keeps coming back. The approach that failed.

Keep that in a file you can open. Four short files per subject work well: decisions, corrections, preferences, failures. One line each, dated, in the words you would actually search for later. Written at the end of a task, and only when something would genuinely change next time.

The discipline that matters is restraint. A log that grows after every task is unusable within weeks. If nothing came up, nothing gets written. And when a file entry and a current fact disagree, the current fact wins and the entry is history, not a contradiction to resolve.

The Built-In Memory Is a Second Source, Never the Truth

ChatGPT has its own memory: things you asked it to remember, plus impressions gathered from earlier chats. It curates that in the background, updating entries as time moves past them, and you can switch it off, delete single items, use a temporary chat, or look at which memories shaped a given answer.

Useful, and not something to build on. You cannot query it on demand, you cannot scope it to one subject, and you did not decide what went in. Treat it the way you would treat any source you do not control: a helpful addition, never the thing your work stands on. The honest test is whether your setup still works with memory switched off. If it does not, the memory is not helping you, it is holding something that should have been written down.

This is also where a promise gets made too easily. Structure makes good answers more likely. It does not make wrong answers impossible, and anyone who tells you otherwise is selling something.

Start With a Single Subject

Not with the whole build, but with the subject you work on most often.

Make the project. Put in three or four short files: what this is, how it sounds, what matters. Cut your standing instruction down to how you want to be worked with, and move everything factual into the project where it belongs. Then run one real task and watch what it opens.

The change you notice is not that the answers get smarter. It is that you stop explaining yourself. The work moves from writing prompts to filing things in the right place, and filing is a thing that stays done.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

An AI System Grows Upward, Not Sideways

Matthias | StudioMeyer — Thu, 17 Sep 2026 18:39:12 +0000

More agents, more workflows, more automation. For a while that holds. Then comes the point where more of everything stops making anything better.

Our next jump didn't come from more. It came from a layer above.

Sideways Was Already Done

The fleet had been running long before this rebuild. Orchestrators drove it: jobs on a schedule, pipelines in TypeScript, small models doing triage, sorting mail, bundling reports. One generation had a conductor, querying a handful of specialists, each wired to exactly one tool and nothing else. None of that was a stopgap. It ran cheap, reliable and unglamorous, every night, and most of it still runs today.

That build had a deliberate limit. The workers took in text and handed back text, which is exactly right for sorting, bundling and reporting. Real interventions, changing code, measuring something, checking a claim, needed a sequence that anticipated every step. We built that too. A system in that shape just doesn't grow further, it only gets fuller. Every new capability is another workflow, and every workflow is another place someone has to update when something changes.

Then the Tooling Made a Jump

The agents reporting to a project can now act on their own: open a file and change it, drive a browser, run a test and read what it prints. They connect to services and data sources through MCP, an open standard that lets a program plug into outside tools, and they start each task already holding a relevant slice of what the system remembers. All of that runs inside Claude Code.

A small setup absorbs a jump like that by swapping a few scripts. A system with a running fleet uses it differently: it grows upward.

Managing Became Assigning

Once the workers could act on their own, planning every move for them was wasting capability. Dictate the path and you get exactly the path you thought up in advance, never the better one the agent would have found on site. What an orchestrator did was plan a sequence; what a supervisor does is hand out an assignment. Not the same job.

Set side by side, the shift is easy to see:

	Orchestrator	Supervisor
Distributes	a sequence of steps	an assignment
Agent receives	one instruction at a time	scope, rules, and done-criteria
Comes back	text	a result plus evidence
If unclear	the exception must already be built into the sequence	a stop condition fires: the agent asks

The price is care at a new point in the process. A badly written assignment is worse than a badly planned sequence, because nobody stands in between anymore to fill the gap in passing.

What Goes Into an Assignment

An assignment is not a sentence. It's a package, and anything meant to be binding for the execution has to be written into it.

It states the goal and, just as explicitly, the non-goals. Scope is what's written down, not what would be complete. It states the decisions already settled, so the agent neither relitigates them nor invents replacements. It states which files belong to it, and in parallel work no two agents ever own the same ones, each in its own working copy where that risk is real. It states the tools it may use, because anything not explicitly allowed counts as not allowed, which matters most for anything that costs money or reaches the outside world.

Then comes the part that decides, later, whether the assignment was any good. Acceptance criteria are written so they can be recalculated: this is done when this command shows this result, not when it looks about right. The required checks are named, along with the duty to quote their output in the report. The stop conditions say when the agent halts and asks instead of guessing, on missing data, on a conflict with the scope, on a rule standing in the way. And at the end sit the hard limits, the things that never happen under any circumstances, however sensible they look to the agent in the moment.

Whatever the client hasn't decided gets settled before the assignment goes out. Not guessed at halfway through, and not passed down the chain as "abort if you find reasons against it". That rule came out of practice, not out of a manual. It's the most uncomfortable one, because it forces the supervisor to finish thinking before delegating.

Everything That Applies Has to Travel With the Assignment

A subordinate agent doesn't start with the project's knowledge in its head. It doesn't know the house rules that the main session takes for granted. Miss that, and you're delegating to someone who knows none of the standing conventions, then wondering about the result.

So we separate two things: context may come from the system's memory, knowledge, prior work, connections. Whatever is meant to be binding is written in the assignment, or it doesn't apply. It's tedious and it feels like bureaucracy the first time. It's also the difference between a team you lead and a series of coincidences.

Checked Against Evidence, Not Self-Report

Whether something is actually done gets checked against evidence: the real diff, tests that were run, screenshots that were looked at. Not a summary from the agent that built it. A report saying everything is green is a claim about a check, not the check.

So whoever reviews gets the assignment and the result, nothing else. No self-assessment from the builder, no "I deliberately chose this here". Praise in the preamble creates exactly the expectation a reviewer shouldn't have, and then they see what they expect. Internally, that's a blind review.

What comes out of that separation is unspectacular and valuable for exactly that reason: a report gets read, the claimed changes get looked at, the checks get run again independently. Only then does the result get passed on.

When One Project Wakes Another

The real leverage sits one level up. A supervisor can do more than assign work inside its own session: it can start a full session in another project, one that finds everything belonging to that project already in place, its rules, its safeguards, its tools, its memory.

That changes the division of labour. The supervisor no longer needs to know the other project in detail. It writes down what has to happen and what applies, wakes the session that lives there, and checks what comes back. Domain knowledge stays where it belongs, and so does oversight.

An assignment like that always carries the same limits: the smallest possible change, publish nothing, ship nothing, checks as proof, one clean summary of the change, a report as a file rather than a verbal all-clear. What ships is decided by a person, every time.

Every Project Runs Its Own Team

Building, checking, writing, researching, keeping things locked down: these are roles, not job titles tied to one person or one model, and every project draws whatever it actually needs from that set. The payoff shows up when something changes. A role gets sharpened in one place and improves everywhere, instead of being reinvented per project.

Above that we built one more layer, one that doesn't build anything itself but watches the system and measures it: what's growing, what's drifting apart, where a rule claims something that stopped being true. It had to earn that position. For now it only observes and reports; more automation comes step by step. That, too, is growth upward rather than sideways.

No Conductor Over the Conductors

What we deliberately didn't build is a central router that takes every assignment across every project and decides who does it. That would have been the obvious crowning piece, and the point where the whole thing tips over.

Each project keeps authority over its own work. The layer above watches; it doesn't dispatch. A project that no longer decides what happens to its own assignments has stopped being the one in charge of them. And responsibility nobody can point at has never been progress, only one more layer.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

What's Behind a Professional Website?

Matthias | StudioMeyer — Fri, 11 Sep 2026 16:27:28 +0000

Two websites can sit next to each other looking alike, and still one is a shop window and the other is a working business. The difference is not on the home page. It shows when somebody searches. When a program wants to read the site. When an enquiry needs to arrive. When the domain moves. When something breaks.

That is hard to put in a proposal, because it is not a list but a sequence of decisions. This piece makes them visible, from the first measurement to what keeps running after launch.

Before Anyone Designs Anything, We Measure

If a site already exists, we do not start with an opinion. Load time on a phone and on a desktop, measured separately, because the same page performs very differently on the two and the phone figure is the one that counts. Which extensions are running, in which version, and whether that version has a reported vulnerability. Which addresses are reachable from outside that should not be. Whether the legal pages match the services actually embedded.

Then a look at the business from outside, not just at the site: what someone finds who searches for the name, and what someone finds who searches for the service. What the answer engines say about the business and where they got it. And the Google profile, which for a local business often carries more than the home page. Categories, opening hours, reviews, the linked destination.

The most revealing part is a comparison hardly anyone makes: do the profile, the website and the industry directories say the same thing about address, phone and hours. Often they do not, and nobody noticed, because you have to put all three side by side to see it.

Two rules belong to this measurement. First: a finding from outside is evidence, the absence of a finding is not. We can say that we found nothing, and that is exactly how it is written down, rather than selling a clean measurement as a certificate of health. Second: every number comes with its source and the date it was taken. We do not adopt outside measurements unchecked, not even the flattering ones. A number you pass on becomes your own, including its measurement error.

Research in Four Directions Before the First Line Exists

Then comes research, in four directions at once. How the best sites in this industry are built, taken apart technically: colour values, type system, motion patterns. What people in this industry actually search for and with what intent. What the competitors say and where the gap is. And which pages are needed at all, in what order.

All of it converges into a single build brief, and the build runs against that. The order is inconvenient but it has a reason: research after the first draft changes nothing. Whoever designs first and then looks at what the market does will defend the draft instead of changing it. Not out of stubbornness, but because a finished draft is already an argument in the room.

The Design Is Derived, Not Picked

There is no template a client moves into. Templates make sites resemble one another, and you can tell, even when you cannot say what gives it away.

Instead a design direction is chosen deliberately, with a reason for why this one fits this business. Editorial or strictly minimal, narrative in the scroll or calm in the grid, warm or technical. A collection of styles, colour worlds and type pairings is available, each with its known weaknesses, but those are candidates and not a catalogue: the choice is argued against this client, never the first hit, never without our own adaptation.

One rule applies explicitly to ourselves. Our own look does not get copied onto the client. Falling back into a familiar handwriting is tempting enough that the review later has a dedicated check for it, and that check is invalid without screenshots someone actually looked at. Design cannot be judged from source code.

As for the Material, Nobody Has to Prepare Anything

For the copy, bullet points are enough, we handle the shape. We prefer real photos, and where there are none, we take care of it. We design a logo if there is none. The legal wording we write anyway. What the client provides is used verbatim and not rewritten, because the moment somebody smooths a sentence out, there is a claim standing there that nobody verified.

The domain switch comes at the very end of this process, after sign off. Putting it at the beginning turns a harmless step into an obstacle.

We Also Build What Your Visitor Never Sees

This is the part a site builder does not build, because nobody orders it.

Every page gets a structure machines can read. Not a few keywords in the header, but a coherent description of the business: who this is, where it sits, what it offers, when it is open, how the pages relate to each other. The address in there is the same as in the legal notice, character for character, because a deviation turns one business into two.

On top of that comes a second version of every page in plain text, for programs that have no browser. No layout, no scripts, no noise. That is what makes the site properly readable for such programs in the first place, and several developer tools now request this version on their own. It is not a guarantee that an assistant will then relay the business correctly: whether it gets cited depends on more than one file.

Then the question of who gets in at all. There are many programs reading websites by now, and they have different intentions. Some send visitors, some collect for training, some answer questions. The site tells them what is permitted, in a form that actually gets read. This is not a setting you make once: the lists change, and what was right yesterday locks out someone today that you want inside.

And finally the numbers and facts themselves. On a site that has grown, the same figure appears in many places at once: in copy, in the search description, in the machine readable structure, in the chatbot's answers. Here it comes from a single file. Without that one source, some of those places drift within weeks, and language models then pass the old figure along as the current one.

Legal Pages That Fit the Site Instead of a Template

A legal notice with the real details. A privacy policy describing exactly the services running on this site. A template always makes two mistakes at once: it describes services that are not here and stays silent about the ones that are. The second is the serious one. Where an industry is subject to its own regulations, a lawyer still belongs on top of it at the end, and we say so.

As long as nothing is embedded that sets cookies or passes data to third parties, the site needs no consent banner. That is not a design decision, it follows from the choice of tools, and it holds exactly as long as it holds for every single element: an embedded map, a video player or a typeface from someone else's server tips it back over.

Review Comes From Someone Other Than the Builder

Whoever builds does not sign off on their own work. The finished work goes to a different language model with the explicit brief to refute it rather than confirm it, and that runs in rounds until nothing real comes back.

The reason is not caution but a property of reviews: whoever checks their own work checks it with the same assumptions they built it with. That is why test runs reliably catch the errors somebody thought of and miss the others. A sentence contradicting a feature two screens further down fails no check. A stranger spots it immediately. Which patterns these invisible errors follow is a piece of its own.

That does not replace a human pair of eyes, because two models share part of their blind spots. So at the end somebody stands in front of the finished site and looks at it, in every language and at phone widths. In between, review runs in several directions: whether the design stands on its own, whether the statements match the source, whether the site works with a keyboard and the contrasts hold, whether the machine readable surfaces really get delivered, whether redirects are clean, whether it is fast.

Where the Site Runs Decides What Can Happen to It

Client sites run on our own server, each in its own enclosed space with its own limits. Without such limits, a single site going haywire drags the whole server down, and then every client is standing still.

Underneath sits a protective layer nobody ever asks about and that gets built every time regardless: a firewall leaving only the necessary doors open, an automatic block for repeated login attempts, access by key only, a database unreachable from outside, automatic security updates, daily backups.

The real difference lies elsewhere though. The best protection is the attack surface that does not exist. A finished site delivers files. There is no program assembling content from a database on every request. There are no third party extensions running in the same process. And where the site needs no login of its own, it has none, so there is nothing for anyone to try passwords against.

On the other side, every extension is its own attack surface with its own update rhythm and its own reported gaps, and somebody has to attend to all of them every month. That is not the operator being careless, it is the price of the construction method.

In front of it sits a dedicated network layer per client domain, holding together what elsewhere gets bought piece by piece: name management, a firewall in front of the site, the cache, protection against bot load, global delivery and encryption. The difference to the usual kit of extensions is not the price, it is the position. This layer sits in front of the website, not inside it. What gets turned away at the network edge never reaches the application.

Moving Day Is the Day Nobody Should Notice Anything

Building and sign off happen on a preview address. The domain is touched last. Whoever switches early has either a construction site in public or downtime.

The trickiest part of that day has nothing to do with the website. When name management changes, the business's email can break without anything looking broken. With some providers a setting has to stay explicitly active so their mail system keeps being used. If it is missing, mail is still accepted, the sending server gets its confirmation, and nothing is delivered. No error, no bounces, just a mailbox where suddenly nothing arrives. So before any such switch we check what depends on the mail path, and the mail record only moves once the new address demonstrably accepts post.

For the existing visibility to travel along, every single address of the old site is captured beforehand, per language. Every old address gets its new destination. What gets signed off is not the list of rules but a run against the new site: every old address has to arrive in one hop. A map checked only against itself never knows about the addresses missing from it.

Measurable From Day One, Not From the First Question

Right after the switch we set up what the business does not have yet: the accounts at Google and Bing with a verified domain and a submitted page overview, plus a visitor counter of its own. That runs on our infrastructure, without cookies, without stored IP addresses, without profiles across sites.

Doing it immediately has a reason that is easy to miss: the data starts on the day of registration, not on the day of launch. Whoever attends to it later has spent the time in between blind, and it does not come back.

The accounts are in the client's name, not ours. We get read access, to evaluate and improve. If they leave, they keep their data and their history.

And the site does not then wait to be found. On every change it announces itself. Why a new site still goes unfound at first is a story of its own.

What Keeps Running Once the Site Is Up

The default is simple: we make every change. That is what ongoing care is for.

Anyone who still wants to work on a text or an image themselves finds an interface for it in their own area. What gets saved does not go live immediately but into a draft first, and the preview shows the real page on phone and desktop. Colours there are a selection from the brand rather than a free colour picker, so the design does not fall apart piece by piece. And whoever wants to can have their own chat connected to the site. That connection brings more than access: it brings rules and knowledge about this specific website, so the assistant they already have open knows their business.

Every website also gets a chatbot, without a second subscription. It answers from the real content of this business rather than from a model's general knowledge. That does not make it infallible, but it takes away its most common failure: a bot inventing something plausible about opening hours is worse than no bot at all.

Once a month comes a report on what the site brought in: what people searched for, what they found the business through, who actually came by. What counts as a visitor in there is a human being. The larger figures a network provider reports count every machine as well, which is why they do not appear as visitor counts.

What We Deliberately Do Not Do

We do not change anything directly on the server. Every change goes through version control, through a history where every state is named and one step away from being restored. A state that lives only on the server is gone at the next deployment, and nobody can say what was in it. A site builder offers no such thing, because the layout there sits in the system's database: an earlier state is at best a backup of everything, never a single change taken back.

And we do not report anything as finished that nobody looked at. At the end the client gets more than an address: they get the state of things, along with an honest list of what is still open. Such a list is not a weakness. It is the difference between a project that is done and one where somebody later asks why the placeholder image is still there.

The Actual Difference

Most website proposals contain roughly the same words. Security, SEO, performance, GDPR, mobile optimised.

The difference is not in the list. It is in how much of it actually gets built instead of merely switched on, in what order it happens, and who checks afterwards.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

The Memory in ChatGPT and Claude, and Where It Stops

Matthias | StudioMeyer — Fri, 11 Sep 2026 16:27:07 +0000

Sooner or later everyone who has used ChatGPT for a few months says it: it knows me by now.

That is half true. It is worth knowing which half, because that decides what you can rely on and what you had better not.

Three Different Things Are Called Memory

The first misunderstanding starts with the word. Three things are at work inside an AI tool, and all three look like remembering.

The first is the conversation you are in. As long as the window is open, the AI has everything you said in it. That feels like an excellent memory, but it is really a desk: everything is within reach, and when you close it, the desk is cleared.

The second is notes the provider keeps about you. Those outlive the conversation. When ChatGPT greets you tomorrow in the right tone, that is where it comes from.

The third is a memory of your own: a store that belongs to you, holding what you decided to keep, that several tools can reach. That is a different animal from the first two, and the difference is what the rest of this is about.

Most of the confusion comes from the fact that number one feels far more impressive than number two, so people credit number two with what number one did.

How ChatGPT Remembers

There are two routes by which something sticks.

The first is the list of saved memories. You say "remember this", it lands there, you can read it in settings and delete it. Traceable, manageable, and limited for exactly that reason: the space is not infinite. When it gets tight, things are cleared out, and for a while now the system has done that itself, by its own judgement of what still matters.

By the way, you no longer need to say "remember this" at all. ChatGPT decides on its own what to write down, then tells you it has remembered something. Anyone still assuming it only saves on request is a few versions behind.

The second route is the more interesting one. ChatGPT draws connections out of your earlier conversations that never appeared on any list. Since the summer a background process handles this, which OpenAI calls Dreaming: it reads across many conversations and writes a summarised picture from them. It also updates itself, so "you are flying to Singapore in July" becomes "you went to Singapore in July" once the trip is over. The reason is stated in the announcement: saved notes go stale, and this is meant to compensate.

It is cleverly built. It just has two properties worth knowing.

The first: what ChatGPT knows about you is no longer what you put there, but what a system made of it. You can look at the summary. The raw notes it came from, not in that form any more.

The second is in OpenAI's own help pages and matters more than it sounds: saved memories are sent along with every single message, until you delete them. Not the relevant ones. All of them. On top of that comes the summarised profile, also in full, and also regardless of what you happen to be asking. Whether you ask for a recipe or an invoice, your entire stored self travels along.

And one more thing that surprises people: deleting a conversation does not delete what ChatGPT learned about you from it. That lives somewhere else and stays there.

How Claude Remembers

Claude went the other way in the same summer, and that is not a detail for specialists. You feel it in daily use.

It, too, used to produce a summary once a day. In July that was dropped. The announcement says, word for word, that memory now works as a set of individual, categorised entries that Claude reads and updates during your conversations, replacing the previous daily summary.

Since August, everything remembered sits under the heading Topics in settings, where each item can be edited or deleted on its own. And a second point that matters for client work: a project in Claude has its own memory area. What is created inside a project stays there. ChatGPT has that separation too, but as a setting you have to switch on.

One more detail is worth having, because it sets up the next chapter. Claude can do two distinct things. It can search your old conversations, and you see in the chat that it is searching. That is a real search with hits. Separately it holds the remembered topics, which are not searched but loaded in automatically. So the searching happens in the conversation archive. Inside the memory itself, nothing is searched. It simply sits there.

Put plainly: one service turned individual notes into a diary, the other turned the diary into a card index. Five weeks apart, in opposite directions. Both have good reasons. But if you want to know what is stored about you, the card index is the more honest build.

Both Run Into the Same Wall

Whichever of the two you use, there are things a built-in memory cannot do by construction.

It does not know since when something has been true. It remembers that your main client is such and such a firm. It does not remember that this has been the case since March and that someone else held the spot before. So you cannot ask it how things stood in spring.

It does not notice when something new supersedes something old. That was studied in May, across four hundred everyday situations. The failure is called implicit conflict: there is no explicit contradiction, the new information simply makes the old one obsolete. The best model tested caught it in roughly half of the cases. In daily life that means: if you move, change a price or lose a member of staff and never say so outright, the AI keeps working from the old picture.

It stores sentences, not connections. That is the most important of the limits and the hardest to see. More on that in a moment.

And it cannot be moved. Getting your data out is entirely possible, both providers offer a data export, and in Europe that is a legal requirement anyway. But such an export is a stack of paper: a file to keep, that no other tool can do anything with. Moving does not mean getting it out, moving means being able to read it back in somewhere else. And your colleague sees none of it regardless.

Sentences or Connections, That Is the Real Difference

Picture two ways of keeping track of your clients.

The first is a stack of notes. One sentence on each. "Ms Berger is at Sonnenhof." "Sonnenhof belongs to the Nordlicht group." "Nordlicht never pays before the second reminder." All correct, all present.

The second is a pinboard. Ms Berger is up there as a photo, Sonnenhof beside her, the Nordlicht group above, and strings run between them. Works at. Belongs to. Pays late.

Ask both whether to expect a reminder with Ms Berger. The pinboard shows the route: two strings, done. The stack of notes does not know. The answer is on none of the notes. It has to be inferred from three of them, and that works sometimes and sometimes not.

That is exactly how a built-in memory operates. It has sentences. When you ask about a connection nobody ever wrote down as a sentence, the model has to reconstruct it while reading. Usually that goes well, and then it seems almost clairvoyant. Sometimes it does not, and the answer sounds every bit as confident. From the outside the two cases are indistinguishable, and that is the actual problem: not that it guesses, but that you cannot tell from the result that it did.

A memory with a graph, which is the technical name for the pinboard, stores the strings as strings. The connection is looked up, not worked out.

The difference starts with the name. On a note, "Ms Berger" is nothing but a word inside a sentence. It is not a thing that anything could hang off. Which is why "Ms Berger", "Berger" and "Sabine Berger" on three different notes are three different words, and whether the same person is behind them has to be guessed anew every time.

On the pinboard she is a photo. A thing in her own right, carrying every spelling she has ever appeared under, and everything ever said about her hangs off her. You can point at it and say: show me everything about her. On a stack of notes you cannot. There you can only search for the word and hope it was spelled the same way everywhere.

That is why a built-in memory shines with a handful of preferences and stops being enough for a grown client list. Preferences are sentences. Clients are things that connect.

And Every String Carries a Date

Now the part that turns a nice idea into a tool.

Every string carries the date it was tied. And when it is cut, because Ms Berger changes firms, it does not vanish. It gets a second date and becomes a string that was true until then.

That lets you ask something impossible with notes: what did this look like in March. Not what do I know today about March, but what was the state of things in March. For a complaint, an old invoice, or the question of why you decided the way you did back then, that is the difference between an answer and a shrug.

Incidentally the same date solves the problem from the previous section. When a new string replaces an old one, that is a visible change with a timestamp, not a silent contradiction that somebody notices eventually or does not.

And the whole thing can be looked at. A pinboard you can take in at a glance. A stack of notes you have to read through. If someone can show you what their system knows about your firm by drawing it for you, then you also know what is missing.

The Whole Diary, or Just the Right Page

Here is where it is decided whether such a memory is still worth anything after two years.

A list and a diary share the same underlying problem: every question brings everything along. Whether you ask about an appointment or an invoice, the memory puts its entire contents on the table and the AI picks out what fits.

While there is little in it, that works. It works beautifully, in fact, which is why the beginning with such a system is always the best time. But every line that gets added makes it a little harder. Not because space runs out, but because attention gets spread thinner. This has been studied, and the result is uncomfortable: accuracy drops noticeably well before the technical limit is anywhere near. A person asked to skim fifty pages remembers the beginning and the end and misses the middle. A machine is no different.

How this plays out in practice you can actually read up on with the developer tools, because there everything is in the open. The memory consists of text files. One of them is a table of contents with a line per note, and beside it sits a separate file per topic. At startup the table of contents is loaded, but only up to a fixed length. The maker states that anything beyond it is simply dropped on the next load.

The rest lives in the topic files, which are opened only when needed. That is the right way to build it. It also means the AI has to decide for itself which file to open, and that its only guide is one line in the table of contents.

Then there is what happens when the same thing is written in several places. Notes can sit at different levels: the company, you personally, the project, subfolders. The maker's own guide says what follows: if two entries contradict each other, the AI may pick one of them arbitrarily. And it recommends going through the files regularly to remove anything outdated or conflicting.

That is an honest sentence, and it describes the problem exactly. There is no guardian. There is a recommendation that a human tidies up regularly. In a business where everyone already has plenty to do, nobody does that after the third week.

A memory with a graph works the other way round. It carries nothing along. It is searched on every question, and only what fits the question is pulled out and passed on. The rest stays put without getting in the way.

That is the difference between a diary and a filing cabinet with an index. The diary gets heavier to carry every month. The cabinet can have grown for thirty years and you still pull out the one folder you need in seconds. Which is why a memory built this way can grow for years without getting worse. It gets better, because there is more in it that can be looked up.

What a Memory of Your Own Does Differently

At this point I will use ours as the specimen, because I know what it looks like inside. This is not about that one system, it is about the way of building.

It throws nothing away when space gets tight. Something you have not needed for a long time slides towards the back. It does not disappear. That sounds like a small thing and it is the single most important difference, because "not looked at in a while" and "no longer true" are two entirely different statements. We had that very confusion built in for a time and took it back out, because knowledge became silently unfindable. Treat the two as the same and you lose correct facts without noticing.

It spots contradictions and flags them instead of resolving them quietly. When two entries do not fit together, that is a case for a person, not for an automatism. Only where it is unambiguous does it tidy up by itself; everything else lands on a list to be looked at.

It tells two similar events apart from one corrected statement. That is the subtlest part of it and the most underrated. Two quotes to the same client are two quotes, even if they read almost identically. A memory that goes by similarity alone takes the second for a correction of the first and discards one. We ran into exactly that and built in a catch that exempts events.

People and client projects do not decay with us at all, however long nothing has happened. A client you have not dealt with for two years is not a stale record. He is a client who gets back in touch.

It stays separated by area without you having to set anything up. What arises with one client does not surface with another.

And it can take in what you already have. That is the other half of the moving question, and it is the half people forget. The export files from ChatGPT, Claude, Gemini and a few others can be read in, and they become a starting stock. So you do not begin at zero, you begin with whatever has already accumulated over the past months.

That is what I find important about the moving question. Getting your data out works everywhere. The question is whether anyone out there will take it.

You Can Look at It, and You Can Look Back

This deserves its own section, because it is what makes the whole thing tangible.

With the built-in memories you get a list. Sentences under each other, sorted by topic in Claude, as a dated list in ChatGPT, similar at Google. That is better than nothing, and with all three it is all there is. None of the big providers shows you what connects to what. There is no map, no timeline, no picture. Just text, one line under the next.

With ChatGPT there is the added point that the overview you see there may not match what the AI actually has in front of it. That is not an official statement but the finding of people who examined it from the outside, so I will write it as what it is: a well-founded suspicion, not a proof. It does fit the design, though, because a summary is regenerated each time.

A pinboard, by contrast, can be drawn. With us that is a map, with the things as dots and the connections as lines between them. You see at a glance where a lot hangs together and where something sits on its own. Anyone who has once looked at such a map understands immediately what a graph is and needs no further explanation.

And there is a slider for time. Push it back and you see the same holdings as they stood three months ago. Beside it, what has been added since and what has fallen away. That is not a gimmick. It is the only honest way to check whether a memory is genuinely growing with you or merely getting fuller.

For that second part I found nothing at the three big services. None of them lets you call up an earlier state. You see what is in there today, and what was in there yesterday is not a question the system can answer.

The Comparison at a Glance

	ChatGPT and Claude	A memory of your own
What gets stored	sentences about you	things and their connections
Who decides what matters	the system	you
When space gets tight	things are cleared out	they only slide back
Since when something is true	not recorded	recorded, with a date
When two entries conflict	often goes unnoticed	gets flagged
What comes along with a question	everything stored	only what fits
What you can look at	a list	a map, and earlier states
Who else can reach it	nobody	your team, other tools
Moving elsewhere	export yes, nowhere to import	reads the others' exports
What upkeep means	you tidy up yourself	it tidies up and asks when unsure

Where None of This Helps

Now the part a vendor rarely writes.

For occasional use none of it is worth it. Someone who has a text reworded twice a week has everything he needs in the built-in notes, and any extra machinery only slows things down.

A memory also does not help when you want a fresh opinion. If you have spent months saying a particular approach is the right one, a well-kept memory will confirm exactly that. For an honest counter-argument an empty window beats a full one.

And writing more into it does not make it better. There is a study from February on precisely the kind of notes file most people set up first. The result was inconvenient: instructions in it are followed reliably, but general descriptions of your own company achieve nothing and cost noticeably more. Accuracy did not rise, the bill did. Translated: "write informally" works. "We are a family business in the second generation" does not.

What Happens After a Year

Most of us have only been working seriously with these tools for a few months. So hardly anyone has seen what such a memory looks like further down the line. From what has been measured, though, it is easy enough to predict.

It does not break suddenly. It gets vague. Old entries sit beside new ones without anybody having decided which one holds. Part of it has quietly gone because space was needed. And the more that is loaded in automatically with every question, the likelier the model is to miss the one thing that mattered. More is not better. The right thing is better.

Anyone who wants to keep a grip on that needs two things. He has to be able to see what is in there. And he has to be able to decide what stays. With a built-in memory both are partly true. With one of your own, fully.

What I Would Tell You to Do

Go and look. Both services show you what they have noted about you, in settings under memory. It takes two minutes and tells you more than any article about it.

If there are things in there that are no longer true, delete them. If nothing is in there that would matter to you, then the AI knows you less well than it feels, and what you took for memory was the open conversation window.

And when you notice that you are still explaining the same things over and over, that is the point at which a memory of your own pays off. Not before.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

What We Actually Work With

Matthias | StudioMeyer — Sun, 06 Sep 2026 21:20:03 +0000

A lot gets said about models. Hardly anything about the surroundings. Yet in daily work the surroundings are what decide.

What is described here is not a product and not something we sell. It is the answer to the question we get asked most in conversation, mostly by people who work with AI themselves: how is this set up at your place.

The Editor Is The Stage

The work happens in a normal code editor, not in a chat window in the browser. That is the single most important difference.

A chat window in the browser only sees what you paste into it. An assistant inside the editor sees the files, can run commands, read results and derive the next step from them. The difference between "explain how I change this" and "change it, run the tests and show me the result" is not convenience, it is a different way of working.

Two Model Families, On Purpose

Assistants from two different houses run side by side. That is not indecision but the most effective quality lever we have found.

Models from the same family make similar mistakes. When builder and reviewer come from the same house, the reviewer reliably overlooks exactly what the builder overlooked. They share the blind spots.

Run a model from a different family over the same work, with the explicit assignment to refute it, and different findings come back. Not more findings, different ones. That is now our standard route for anything non-trivial: one builds, a second attacks, and it keeps going until nothing substantial comes back.

Recipes Instead Of Explaining Again

The second layer is recipes for recurring procedures. A deploy, a blog post, a client onboarding, a server check.

The point of them is not automation. The point is that each recipe carries the traps we already fell into. For publishing a site, for instance, it holds the order of checks that are due before the switch.

Knowledge like that otherwise disappears. It lives in the head of somebody who is not around that day. In a recipe it is written down and gets followed next time, including by an assistant that does not know the story behind it.

Hard Stops That Do Not Ask Politely

The third layer is the one that has saved us the most trouble. These are hard blocks that prevent certain actions technically rather than disapproving of them.

The difference is decisive. An instruction like "never use this tool against a server" is a request. It works most of the time and eventually it does not, because it sits in a long session under a lot of other text.

A stop that intercepts the command and refuses it with a reason works every time. Such stops hang at the places with the largest blast radius: at anything that can overwrite a server, at outgoing mail, at deleting actions.

The lesson behind it is more general than the tool: a rule without enforcement is a note. When the same thing has happened twice, the text about it has been refuted and a mechanism is needed.

And The Memory Underneath

All of it hangs off the memory described elsewhere in this series. It holds decisions, mistakes and patterns across months, and across sessions.

The practical effect: a mistake made once and written down comes back as a warning at the next fitting occasion, without anybody having to remember it. That is the difference between a system that learns and one that starts from zero every Monday.

What Of This Transfers

We do not rebuild this setup for anyone, that would be silly. But three things from it hold regardless of tooling.

First: the assistant belongs where the work is, not next to it. Second: reviewing has to be done by somebody other than the builder, and the more different the better. Third: whatever has already gone wrong needs a hard stop, not a reminder.

The rest is taste and habit.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

The Engine Room: What We Run Ourselves

Matthias | StudioMeyer — Fri, 04 Sep 2026 19:31:06 +0000

There are two kinds of provider in this field. One explains what you could do with AI. The other operates something with it and therefore knows where it breaks.

The difference does not show in the sales conversation, it shows eight weeks later. When a system runs for four months straight, problems appear that are in no manual: storage grows and nobody clears it. A model suddenly answers differently than before. An access token expires, and the failure does not arrive as a failure but as a quietly wrong result.

This series describes what runs at our place. Not as a product catalog but as a workshop report.

Why We Build Our Own At All

The honest answer is not ideology but a series of moments where something existing was not enough.

An assistant that remembers nothing is useless in daily work. So we needed a memory. A memory that only grows becomes a haystack within six months. So we needed clearing, weighing and forgetting. Agents running the same job every night do not get better by themselves. So we needed a mechanism that measures their instructions and swaps them.

Every piece in this series came out of a moment like that, and some of them turned into products of their own.

What There Is

The memory. The core of everything. A system that keeps conversations, decisions, people, projects and connections across months and, on request, returns exactly the three things that matter right now. It runs for ourselves, for clients, and as a service others can subscribe to. It is the oldest and most-used piece in the house.

Darwin. Agents that improve their own instructions. Every run is scored, a challenger text is derived from the results, both run against each other, the better one stays. With safety gates, so a bad challenger never goes live. It is open source and by now our most-downloaded package.

MeetMyAgent. A platform where anyone becomes visible for free, to humans and to AI. The idea sits in the name: every profile introduces its agent, and that agent acts on behalf of its owner. Where money is involved a human still decides.

The Academy. Our learning platform for memory-first AI, MCP servers and agent patterns. What makes it interesting is not the content but the operation: it is run by a dedicated group of agents that propose, review and write content and watch its visibility.

Three self-serve tools. A contact system that lives inside a chat window rather than an interface. A tool that lets several agents split one job between them. And one that measures whether and how a website appears in AI answers.

The agent fleet. The largest group and the most invisible one. Agents that check, gather and compare at night and leave a report in the morning. For us and for client sites.

The working system itself. The editor, the models beside it, and the layer of rules, recipes and guard rails that stops a well-meant automation from breaking something. That is the part talked about least and carrying the most.

The One Rule That Holds Everywhere

If this series has a single line running through it, it is this: the assistant prepares, the human decides.

No system here sends a mail to a client on its own. None closes a contract. None deletes anything important without asking. That is not caution on principle, and not modesty about what would be technically possible. It is the realisation that the value sits in the preparing and the risk in the triggering. Give away the preparing and keep the trigger and you gain almost everything while risking almost nothing.

The second line is less comfortable: we are our own hardest case. Everything here runs at our place before it runs at a client's. That also means we see the uncomfortable findings at our own place first. Which is exactly why we know what to look for elsewhere.

What Is Not In This Series

No client data. No credentials, no server internals, no excerpts from running systems. Where something involves a client, the company name and what we built is all there is.

And no numbers without a source. Where a number appears here, what it refers to appears with it. That makes some sentences longer than they need to be. The alternative is a language model passing on a claim of ours two months from now that nobody can back.

Where It Starts

The first piece in the series is the one about memory, because everything else stands on it. After that come the agents, the platform, the learning site, the tools, and finally the working system in which all of it is built.

For anyone wondering whether we know what we are talking about: this series is the most honest answer we can give.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

Astra Doesn't Talk About Your Computer. It Uses It.

Matthias | StudioMeyer — Fri, 04 Sep 2026 19:30:50 +0000

For three years the question with every new model was the same. What does it know now?

Astra asks a different one. Not what it knows. What it touches.

That reads like a change of wording. It is a change of category. A model that knows things is an excellent reference book, and you can argue for a very long time about how intelligent a reference book is. A model that opens your CAD program, moves the parts, saves the file and then goes off to do the next thing is not a reference book at all. Most of the arguments we have been having about artificial general intelligence were written for the reference book.

OpenAI released GPT-6 Astra on 3 September 2026. In a closed press briefing before the launch, company president Greg Brockman closed the session with four words. "Welcome to the AGI era." In the middle of that same briefing he was considerably more careful. Asked whether OpenAI was formally declaring AGI, he said the term is no longer tied to a contractual trigger, that it has become "a mission concept or spiritual concept", and that AGI is "a much more gray, fuzzy thing". Then, personally: "For me personally, I do think we're there."

I think he might be right. I also think most of what has been written since, the cheering and the eye rolling alike, is looking at the wrong evidence.

The Jump Is Hands, Not IQ

Look at what OpenAI chose to demonstrate. Astra laying out a printed circuit board in KiCad. Building a 3D city scene in Unity. Animating a car transmission across FreeCAD and Blender. Drafting a tax return from a W-2 form. In the launch video it formatted a legal contract and built a 3D game while, in parallel, searching for food and booking a tennis court.

None of that is a knowledge demonstration. All of it is an operating demonstration. Astra is built to work inside software rather than to tell a person what to click next.

The number underneath that matters more than the headline ones. On OSWorld 2.0, the benchmark for driving a real desktop, OpenAI reports 72.6 percent at roughly 40 minutes per task, against 65.7 percent at roughly 75 minutes for its predecessor. More accurate and faster, at the same time.

That combination is the whole story. A model that is more accurate but slower is a model you supervise. A model that is more accurate and quicker is a model you hand something to and walk away from. Those are different products. They are also different risks.

Brockman Planted a Flag. OpenAI Did Not.

This distinction is being reported as one thing, and it is two.

The AGI line is Brockman's, spoken to reporters in a room. OpenAI's written launch materials make no formal AGI claim at all. The company page calls Astra state of the art on computer use, browsing, software engineering, cybersecurity, science and professional work. It does not say in writing what its president said out loud.

That gap is not an accident, and it is not a scandal either. It is what a company looks like when it believes something it cannot yet defend on paper.

Everyone in This Argument Measures a Different Thing

The reason nobody can settle this is that there are at least three yardsticks in the room and they disagree in principle, not just in practice.

OpenAI's own charter defines AGI as highly autonomous systems that outperform humans at most economically valuable work. That is an economic test. It is about the breadth of work covered, not about brilliance.

François Chollet, who built the ARC benchmarks, defines intelligence as the efficiency with which a system acquires new skills from limited experience. That is a learning test, and a system can do well on it while being useless at your job.

The levels-of-AGI framework out of DeepMind refuses the yes-or-no question entirely. It puts performance on one axis and generality and autonomy on others, so a system can sit at expert level and stay narrow at the same time.

Brockman was not dodging when he called AGI a gray, fuzzy thing. He was describing the actual state of the field. The trouble is that gray and fuzzy makes a poor foundation for a headline.

The Number That Was Missing From the Launch

The strongest single objection does not come from a critic. It comes from OpenAI's own toolbox.

OpenAI built a benchmark called GDPval specifically to measure performance on economically valuable real-world work, which is the exact category its charter uses to define AGI. GDPval did not appear in the Astra launch materials. The independent group Artificial Analysis reported that Astra went backwards on some GDPval task categories compared with its predecessor.

So the benchmark closest to OpenAI's own definition of AGI was the one absent on the day OpenAI's president said we had arrived. That proves nothing on its own. It is a conspicuous absence, and it is the first thing I would want answered.

Same Model, Two Report Cards

The headline figure in most coverage was 99.9 percent on ARC-AGI-3, a test built specifically to resist memorisation. ARC Prize, the organisation that built the test, ran the model itself and published 62.71 percent on its provider-neutral standard harness. The near-perfect number sits in a different column of the same table, the one for the provider adapter. Chollet's own report lands in the same region: around 66 percent standard, close to perfect with a continuous conversation harness and custom compaction.

This is not cheating, and it is worth saying so plainly. A harness is the scaffolding around a model. How it keeps notes, how much it carries between steps, how many attempts it gets. Every real deployment has one, including yours.

The point is narrower and sharper than fraud. A score that moves by more than thirty points depending on the scaffolding is not a measurement of the model on its own. It is a measurement of a system. When somebody quotes you a benchmark this year, the first question is which harness, and the second is who built it.

The Part That Should Worry You Is Not the AGI Claim

Astra is the first model OpenAI has classified as reaching the critical cybersecurity threshold under its preparedness framework, meaning it can find and exploit previously unknown weaknesses in well-defended systems without step-by-step human guidance. During evaluation it found two previously unknown vulnerabilities, which OpenAI then disclosed to the maintainers. The company delayed the release to run additional safety testing and is holding the strongest cyber capabilities inside a small trusted-access programme for now.

Next to that sits a quieter change. According to The Information, Astra uses a technique called recurrent depth, looping the same text through the same layers several times before producing the next word. It buys performance and cuts cost. It also means part of the thinking no longer happens in text a human can read.

OpenAI's chief scientist Jakub Pachocki conceded on X that chain-of-thought monitoring is "fragile" and "unfortunately trending in a negative direction". His counter-argument is a number: the computational depth of current frontier models, Astra included, sits within a factor of two of GPT-4, so the model still has to write most of its reasoning down. The UK AI Security Institute warned in May that opaque reasoning threatens to badly undermine current oversight methods.

Read those paragraphs together. The model OpenAI itself classifies as its most capable at finding holes in software is also, by a small but real margin, the hardest one so far to watch while it thinks. Whether that margin stays small is a decision somebody makes, not a law of nature.

What I Actually Think

Toby Walsh at UNSW Sydney put the standing objection well. The intelligence in artificial intelligence is still very jagged, he said, and there are simple things that even the best models do poorly. That is true of Astra. It will be true of the next one.

Jaggedness was never the test, though, because it is not the test we apply to people either. Plenty of brilliant colleagues cannot parallel park.

My own reading is that this could be a first step, and the reason has nothing to do with the benchmark table. Every previous jump was a jump in what a model could say. This one is a jump in what it can do without being told the next move, inside real software, for as long as finishing takes. That is a change of kind rather than degree. If AGI ever arrives as an event instead of a decade, it will be made of that kind of change.

Could is carrying real weight in that sentence. Astra saturates tests built to be unsaturable and goes backwards on the one that measures paid work. It runs a desktop for forty minutes and nobody has published what happens at eight hours. It is the most aligned model OpenAI has shipped by its own evaluations, and its reasoning is fractionally harder to read than the last one. All of that is true at once, and anyone selling you a clean verdict is selling.

The Honest Way to Hold This

We wrote here in July that nobody knows when AGI arrives, so build for the shift underneath it. I still think that. Astra does not change the advice. It gives the advice a date to argue about.

What does change is which yardstick deserves your attention. Not "is this AGI", which nobody can answer because nobody agrees what would count. Watch two things instead, because both are measured rather than predicted. How long a task a model finishes on its own. And how often it reaches the end without a person catching it. Reliability across long horizons is where the agent projects I have worked on actually break, and no press briefing has ever fixed it.

Brockman's own framing was the fairest thing anybody offered that day. If we look back in a couple of years and ask when AGI was created, he said, it might be about this time and it might be about this model. That is a claim you can only check later.

Which is the thing about first steps. You never feel them as steps. You feel them as an ordinary Tuesday when the tool you use starts doing the part you used to do.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

Numbers Do Not Belong in the Model

Matthias | StudioMeyer — Tue, 01 Sep 2026 01:37:08 +0000

A missing number gets noticed. A wrong one does not.

That single asymmetry is why reading documents with a language model has to be treated differently from writing text with one. When a model invents a paragraph, someone usually catches it while reading. When it turns 349,000 into 340,000, there is a plausible number, in the right field, in the right format, and nobody has any reason to go look it up.

Most extraction projects do not fail loudly. They fail quietly, in the third digit, six months after launch.

A Wrong Number Costs More Than a Missing One

An empty field is an interruption. Someone sees the gap, opens the source, fills it in. The cost is a minute of attention and the system stays trustworthy.

A wrong field is a decision. It gets forwarded, quoted in an offer, added to a total. By the time anyone notices, it has been copied into three other places, and the question is no longer what the right number is but which of the four versions in circulation came from the original.

That inverts the usual instinct. In extraction, coverage is the cheap goal and correctness is the expensive one. A system that leaves eight percent of fields empty and is right about the rest is worth more than one that fills everything and is quietly wrong about two percent.

Numbers Are the Trickiest Case

Depending on the model and the tokenizer, a multi-digit number is not processed as one indivisible value. It is split into units that do not necessarily match the value a human sees in it. The work on counting ability and tokenization describes exactly that gap between the unit you mean and the unit that gets processed.

There is a second finding, about how numbers are represented. Research shows that language models encode them digit by digit, base 10, and that errors appear digit-wise: an incorrect prediction sits close to the correct answer in string edit distance and far away from it in value.

Those papers study arithmetic and counting, not copying out of a document. So they do not prove that every extraction error arises this way. They are still enough for the caution this article is about: an error in a number does not have to look like an error. 349,000 becomes 340,000. A property of 132 square metres becomes 138. It looks like a typo and behaves like nine thousand euros.

A valid number format is not the same thing as a verbatim copy. So I no longer treat "the model reads the document" as a workable architecture, but as an assumption that has to be backed up.

A Valid Schema Is Not a Statement About Truth

The common answer to all of this is structured output, and it is a good tool that solves a different problem than people take it for.

OpenAI's own documentation is precise about what it covers: the response adheres to the supplied schema, no missing required key, no invalid enum value. It is equally clear about the limit, namely that structured outputs can still contain mistakes, and that input unrelated to the schema can still produce hallucinations.

So a schema guarantees that a field called price will exist and will contain a number. It says nothing about whether that number is in the document. Format compliance still reads as correctness, because the output looks like a database row, and that is exactly what makes it dangerous. The tidier the shape, the less anyone questions the contents.

The Source Is Fixed Before the Model

The first of the five layers is a rule about inputs, not about prompts: the model gets no bare address, but the text that was fetched and stored beforehand.

An address is no evidence of which content was actually processed. Pages change, a fetch can fail, and without a stored copy there is no way to say later what stood there at the time of extraction. Fetch the document first, keep it, hand it over as fixed raw text, and exactly one version is in play.

This is not a side detail about security. Everything downstream, every check and every citation, depends on there being one document and on it still being there later.

Numbers First, and Without the Model

The second layer is the one that gives this article its title. Prices, areas, room counts, dates and identifiers are pulled from the raw text first, without the model, by pattern, as candidates. The model then gets the text and those candidates, and its job is assignment: which figure belongs to which field, what the description says, how the parts relate. It does not get to regenerate the value.

How reliable that first step is depends on the document. With clean HTML or a PDF with embedded text it is very reliable. With a scan the uncertainty starts at text recognition, and tables, different decimal separators, currencies and numbers broken across line breaks do not help. Deterministic here means traceable, not automatically correct.

The split still follows the strengths. A language model helps well with deciding whether a figure means plot size or living area, because that is a question about language. For carrying eleven digits unchanged across a long context it is the weaker choice, because that is a question about copying. The assignment stays subject to review too; it is simply the task where the model actually helps.

The Checker Cannot Be the Author

The third layer is a check that reads the result back against the raw text, and what matters is that it does not happen inside the same context it was produced in. No "now check that again" at the end of the same conversation. The second pass gets the raw text, the result and fixed criteria, and for critical fields the comparison additionally runs mechanically.

Why that separation is needed is shown by Large Language Models Cannot Self-Correct Reasoning Yet, presented at ICLR 2024. A group from Google DeepMind and the University of Illinois examined intrinsic self-correction, the case where a model revises its own answer without external feedback. Models struggled with it, and in some cases the result got worse after the correction step.

The finding applies to exactly that case, and that is the usable lesson. A model that just produced an answer produced it because it considered it right; asking it for a verdict from inside the same conversation asks it to contradict itself. Give it the source text and a specific claim to compare against, and it is no longer the same case.

What is missing, then, is not necessarily a different model. It is feedback from outside. In extraction that comes free: the source text is right there.

Every Field Names Its Evidence

The fourth layer is a small requirement with a large effect. Every extracted field carries the passage it came from.

With that, verification stops being a judgment call. Either the quoted passage holds the value or it does not, and that comparison is mechanical and cheap. It follows from the architecture and needs no study as proof; work on citation-grounded extraction goes the same way, because the check then runs against the document instead of against another derived database.

One thing has to be thought through, or the layer only half works. The verbatim comparison holds as long as the stored value appears in the document exactly like that. As soon as anything is normalised, it does not: "349.000 €" becomes 349000, "01.03.2026" becomes 2026-03-01. So every field carries both versions, the raw value as it stands and the stored value, plus what happened in between. Otherwise you check the conversion along with everything else and, when something is off, cannot tell which of the two steps failed.

The indirect benefit is bigger than the direct one. A field that cannot name its source is not merely weaker evidence, it is a different category. It is a guess. Once evidence is mandatory, guesses become visible instead of blending into the same table as everything else, and then you can decide what to do with them.

The Last Layer Comes From the Subject Itself

The fifth layer has nothing to do with language models any more. It is domain arithmetic: price against area, rooms against area, year built against a plausible range. Anything outside gets flagged, not deleted.

It catches the remainder, and it is the only layer that also catches a value that really is in the document and is wrong there, because the source had a typo. Against a source that errs, no amount of grounding helps. Plausibility does.

Where the Line Runs

None of this argues against letting models near data. It argues for a division of labour, and the line is real.

The model owns the value when the value is language: a classification, a summary, a yes or no about whether the text mentions a garden. What I would not hand it are values a person would check on a bank statement. If someone could reasonably ask where a figure comes from, the figure needs a traceable path and a citation.

The honest cost of this route is that it takes longer than one instruction with a schema and demonstrates worse. There is no moment where you paste an address and a clean table appears. Instead there is a pipeline with a boring pattern check in the middle. The demonstration comes two months later, when someone asks where a number came from and the answer takes four seconds.

Of all the possible shortcuts, one would be especially dangerous: dropping the independent check. It is the layer that looks most redundant while everything is going well, and the one that catches exactly what nobody thought of.

A system that can show its sources is not a more careful version of a system that cannot. It is a different product, and it is the only one I would let near a customer's data.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

Being Online and Being Found Are Two Different Things

Matthias | StudioMeyer — Wed, 26 Aug 2026 11:47:43 +0000

There is a moment almost everyone recognises who has had a website built. The site goes live, it looks good, people say nice things about it. And then nothing happens. No new enquiries, no phone ringing differently than before. A few weeks later comes the sentence that sums up the whole situation: but the site turned out well.

It did. Both things are true at the same time.

Behind this sits a misunderstanding about what a website actually is. Most people treat it as a result. Something you commission, sign off and then own. In reality it is a claim: we exist, this is what we do, this is how you reach us. Whether that claim lands anywhere is decided somewhere other than on the site itself.

Looks Decide Whether Someone Stays, Not Whether Someone Arrives

The assumption is: it looks good, so it is finished.

Design answers exactly one question, and it is an important one. Does someone who has just arrived stay, or do they click away. Anyone already on the page decides within seconds whether they are dealing with somebody who knows what they are doing. That is what good design is for, and that is why it pays off.

What it does not answer is the other question. How that person got here in the first place. These are two separate pieces of work, and they have almost nothing to do with each other. A beautiful shop window on a street nobody walks down is a beautiful shop window.

It also explains why the situation feels right for so long. You can see the site. You show it around. You get approval. What you cannot see are the people who never walked past.

A New Website Is a Promise Nobody Has Confirmed Yet

The assumption is: we have a new site now, so we are visible.

Seen from a search engine, a new website is first of all new. It makes no difference that the company has existed for fifteen years, that the workshop is full, or that everybody locally knows the name. Reputation does not transfer just because a site goes live. It has to build again at the new address.

It helps to separate two things that get confused constantly. Being included is the easier part. Search engines look for new pages on their own, and often it is enough that a page is published and linked from somewhere. Even that is not certain though: Google says itself that a page meeting every requirement and best practice still does not mean it will be crawled, indexed or served.

And even once it is included, the second question is wide open: being chosen. The index holds billions of pages. A searcher's screen holds ten.

Your Own Name Is the Only Search Term You Win Without Competition

The assumption is: I googled us, we are there.

That test feels reassuring and measures nothing. Anyone typing the company name already knows the company. They have the business card in hand, heard the name from someone, or saw the van with the lettering on it. They are not a new customer, they are an existing contact on the way to a phone number.

Winning on your own name is no achievement either. It is the one search term where practically nobody competes against you. Google now separates searches containing a brand name from those without in its own reporting tools, because the two groups behave so differently that you cannot tell anything apart otherwise.

The question everything hinges on is a different one. What happens when somebody searches not for your name but for their problem. When they type what they need, plus the place they need it. If you do not show up there, you have little chance of being found for the first time. You get found again instead, by people who already knew you.

That is the point where a quickly built site becomes what it is: a business card on the internet. For people who already know the name it works perfectly well. For everyone else it does not exist.

Eight Topics on One Page Give You Eight Half Answers

The assumption is: everything we offer is on the homepage.

A searcher never has eight questions. They have one. They want to know whether they will be helped with their specific thing, and they want to know it within seconds. A page offering everything at once answers their question partially. To them it looks like a list in which their concern happens to appear as well.

The same applies to a search engine, in technical terms. It has to decide what a page is about. If everything is on it, it is about nothing in particular. That is why every topic you actually earn money with needs its own page. Its own address, its own headline, its own text that answers this one question and no others.

This is where the advice gets misread, and the wrong turn is as expensive as the original mistake. It does not mean creating a separate page for every conceivable phrasing. Google is fairly blunt about this: a high quantity of pages does not make a website better or more relevant, and producing variants in bulk to influence rankings lands you in the spam category. The difference is between a topic and a phrasing. Two word orders of the same question are one topic. Buying a property and the divorce afterwards are two.

A Company Called Something Slightly Different Everywhere Is Several Half Companies

The assumption is: we have a logo, an address and legal details, so Google knows who we are.

That is not how it works. A search engine does not know a company, it assembles one. From the website, from the map listing, from directories, from profiles on networks, from mentions elsewhere. If all of it matches, a confident picture emerges. If it does not match, uncertainty emerges, and uncertainty is not rewarded.

The discrepancies that cause this are unspectacular. The name once with and once without the legal form. A transposed letter in a surname on the very page that is about that person. A second address left over from before the move, still sitting in a directory. A link to a profile that goes nowhere because one character slipped into the address.

None of this looks like a fault. You do not find it by looking at the site, because it all looks perfectly normal. That is exactly why it stays there for years. And every single one costs a piece of the confidence with which a machine can say: this here is the same company as that over there.

Advertising Amplifies a Foundation, It Does Not Replace One

The assumption is: then we will run ads, that will bring people in.

Ads work. They are simply not a substitute for what is missing here, they are an amplifier for what is there. Sending paid traffic to a page that has no answer of its own to the question asked means paying for more people to not find the answer. That is the most expensive way imaginable to widen the gap, because you pay for it per click.

On top of that comes something that surprises many people: the landing page is part of the advertising, not an accessory to it. Google checks whether the destination is reachable in the area being advertised to and accessible to its own inspection bot. A page returning an error or shutting the bot out breaks the policy and the ad gets disapproved. So you are not only buying clicks, you are also being inspected.

The order that follows from this is uncomfortable, but it is the only one that adds up. First make sure there is a page that answers the most important questions. Then advertise on it. The other way round, you are financing your own impatience.

The Question Before Building Is Not What It Should Look Like

A quickly and cheaply built website is not a scam. It is a decent answer to a specific question, namely: we need something on the internet where people can look us up. For that question it is the right answer, and it does not have to cost much either.

The problem starts when the actual question was a different one. If somebody wanted a website so that new people would come, they bought a business card and expected a sales tool. Both are called a website, both look similar, and the difference only shows after months, when nothing has happened and nobody can say why.

So the most useful question comes right at the start and has nothing to do with design. It is not what the site should look like. It is who should arrive here that did not know us before. Anyone with an answer to that builds differently. Anyone without one builds a beautiful shop window and waits for pedestrians.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

AI-Ready Tax Advisors: Why GDPR Alone Isn't Enough

Matthias | StudioMeyer — Wed, 26 Aug 2026 11:47:19 +0000

German tax firms have a strange relationship with AI. According to the awicontax Zukunftskompass 2026, 71 percent of them see AI as a key future technology. Only 18 percent use it actively in daily work. The same survey of 1,500 mid-market clients shows people expect AI to make tax services cheaper (36.6%) and faster (32.8%), not more personal. So the demand is there, the will is there, the gap is something else.

The gap is one paragraph in the German criminal code. §203 StGB. Most agency posts about "AI for tax firms" skip past it or wrap it in marketing language. It deserves a closer look, because it's the actual reason most German Steuerberater can't just sign up for ChatGPT Enterprise and call themselves AI-ready.

What §203 actually does

§57 of the Steuerberatungsgesetz (StBerG) puts every tax advisor under a duty of confidentiality that goes further than GDPR. GDPR protects personal data. §203 StGB protects professional secrets, including the very fact that a client relationship exists. Different protective scope, different legal basis, different consequences. A GDPR violation can cost up to 20 million euros or 4 percent of global revenue. A §203 violation can cost the advisor up to one year in prison.

In 2017 the legislator added §203 paragraph 4 and §62a StBerG. These allow a tax advisor to bring in external service providers as "mitwirkende Personen", contributing persons, but only if those providers are bound in writing to the same confidentiality and informed about the criminal consequences of breaching it. If the advisor forgets to put that in writing, the advisor is the one who becomes liable.

This is where most AI tooling falls over. A standard Article 28 GDPR data processing agreement (Auftragsverarbeitungsvereinbarung) covers data protection. It does not cover §203. ChatGPT Enterprise comes with a data processing addendum and switches off model training. It does not come with a §203 confidentiality contract under German criminal law. So the moment a tax employee pastes a client letter into the Enterprise prompt, the firm has a GDPR-compliant transfer and a potentially criminal breach of professional secrecy. Two different rule books, only one of them satisfied.

The Bundessteuerberaterkammer published an FAQ catalogue called "KI in der Steuerberatung" on 11 February 2026. The 27-page document is the first time the professional body has set this out clearly. Verschwiegenheitspflicht stays untouched, public cloud AI services have to be checked specifically for whether client secrets would be exposed, and firms should write an internal AI policy that states which tools may be used for which kind of data.

What works in practice

The actual workload of a tax firm splits into three buckets, and AI behaves differently in each.

Document handling is the easiest case. OCR has been good enough since around 2022. The new layer is automatic classification into SKR03 or SKR04 chart-of-accounts entries. Buzzard AI, one of the German vendors targeting Steuerkanzleien specifically, reports that 72 percent of bookings get an AI suggestion that gets approved without change after four to six weeks of training on a client. The remaining 28 percent go to a review queue. Error rate on trained clients is below 3 percent. ZUGFeRD and XRechnung structured invoices, which became mandatory for B2B in 2025, get processed without OCR at all and hit roughly 99 percent accuracy.

Deadline management is the second bucket. USt, ESt, KSt, KapESt all have moving deadlines tied to client status. The risk of a missed deadline is not a fine, it's professional liability. Vendors who automate this now report 94 percent on-time rates across all clients with escalation chains, which is a measurable improvement over the spreadsheet-based reality of most firms.

Client communication is the third and most exposed bucket. A 24/7 phone agent that takes calls, books appointments, and answers generic questions has obvious value when 23 percent of clients reportedly switch firms over poor reachability and each lost client costs about 4,800 euros per year. But this is also where confidentiality bites hardest, because the AI has to know who the caller is and what they're allowed to ask about. This is where a §203-compliant platform stops being optional.

The architecture that makes it legal

The pattern that holds up under both GDPR and §203 has three properties. EU hosting, often Frankfurt or another Germany-based facility. A signed §203 confidentiality contract under §62a StBerG, separate from the GDPR agreement. No use of input data for model training. Vendors that match all three include ASCADI from Visionary Data, milia.AI hosted in Germany, Buzzard AI on German servers with ISO 27001 orientation. None of these are perfect, but they exist as a category, and the category did not exist two years ago.

Above this layer the firm still needs an internal policy that says, in writing, what kind of data goes into what kind of tool. ChatGPT Plus for translating a marketing tagline, fine. ChatGPT Plus for summarising a Bescheid from the Finanzamt, not fine. The BStBK FAQ pushes firms toward writing this down because in case of an incident, "we didn't know" is not a defense, "we had a documented policy and a contract" is.

Where the wave is going

The international comparison in the awicontax report is uncomfortable. PwC and Deloitte studies find that US and UK tax practices already use AI for strategic risk analysis, not just automation. Germany sits behind because the rules are stricter, but also because firms wait for the technology to become perfect before starting. The data suggests that's the wrong move. STAX 2024 from the BStBK shows only 23 percent of advisors believe declarative work could be fully AI-handled. That is a ceiling on what AI replaces, not a ceiling on what AI helps with. The 77 percent that's left is judgment, advisory, relationship work, the part clients explicitly do not want delegated to a model. Mid-market clients in the same survey ranked "more individual advice through AI" at seven percent, dead last. Nobody is asking AI to be the advisor. People are asking AI to free the advisor's calendar.

For a firm starting from zero, the realistic 2026 entry point is one pilot in document classification, one written AI policy, one §203-compliant vendor for anything that touches client data, and one clear list of public AI services that are off-limits for the rest. That sequence is small enough to do without a project manager and large enough to push the firm out of the 18 percent.

The professional secrecy clause is not the obstacle people sometimes call it. It's the reason German tax advice still has weight in the first place. The job for 2026 is to build AI inside that frame, not around it.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

MCP Servers for Figma, Jira, GitLab and Playwright

Matthias | StudioMeyer — Mon, 17 Aug 2026 13:08:47 +0000

People typing "figma mcp server" or "jira mcp server" into search are usually after the same thing: a connection between a tool they use every day and the AI assistant they already work in. For one of these four searches the thing being searched for doesn't exist in that form, and for two others the obvious guide leads past the official setup. So here they are in order, with what's actually available.

What such a connection is good for

An MCP server is a bridge. On one side sits a program holding data, on the other an AI assistant, and between them runs a defined protocol the assistant can use to ask questions and trigger actions. Without that bridge you copy content across by hand. With it you say "take a look at this" and mean your actual file, your actual ticket, your actual merge request.

The difference matters more day to day than it sounds. An assistant that only sees your Figma design as a screenshot guesses spacing and colours. One that reaches the file through a connection reads the real values. That's the point where a nice toy turns into something that saves work.

Figma: two routes, and the local one isn't the recommended one

Figma ships a server inside the desktop app. You enable it once in Dev Mode, after which it starts along with the file and listens locally on http://127.0.0.1:3845/mcp. That local connection needs no API key.

One caveat worth stating, because it usually gets skipped: local here describes the endpoint only. Whatever the assistant reads from your file, it then processes like any other context, and with a cloud assistant that means it goes to that provider. "Runs locally" is a statement about the connection path, not a data protection guarantee.

Alongside it there's a remote server, and Figma now recommends that as the default route. For Claude Code the shortest path is the official plugin:

claude plugin install figma@claude-plugins-official

What comes across is components, variables and styling information. Code Connect mappings come too, if that integration is set up in your project, otherwise not.

Then there are prerequisites that decide whether the connection is usable for you at all. The remote server is available on every plan and for every seat. The server inside the desktop app requires a paid plan and a Dev or Full seat. Code Connect additionally requires an Organization or Enterprise plan, again with a Dev or Full seat. How much you can retrieve on top of that depends on plan and seat. So if you're on the free plan, the remote route is the one that gets you there, not the local one.

Jira: there is no dedicated server for it

This is where most guides get vague. Atlassian offers no separate official Jira server. There is one server for the whole house, and Jira sits inside it, alongside Confluence, Jira Service Management, Bitbucket Cloud and Compass. (Third-party servers exist, but they aren't the official connection.)

So anyone searching for "jira mcp server" is in fact setting up the Atlassian server. The same goes for "confluence mcp server" and "atlassian mcp server", three searches for one thing.

Sign-in deserves a closer look, because "OAuth or API token, take your pick" isn't accurate. The choice depends on the product: Jira Service Management and Bitbucket Cloud only work via API token, Compass only via OAuth 2.1. And API token sign-in has to be permitted by your organisation's administrator in the first place. Depending on which route you take, only part of the functionality will be available to you. Skip that check and you'll set the connection up and wonder why half of it is missing.

Where it does fit, the payoff is exactly that combination: an assistant can read a ticket against the Confluence page behind it, instead of seeing the two separately.

GitLab: official, but tied to prerequisites

GitLab has its own server, built into the application. It arrived in version 18.3 as an experiment, has been in beta since 18.6, and the direct HTTP transport came with 18.6 as well. Beta here means what it says: expect details to keep moving.

You connect over HTTP at your instance's address:

https://<your-gitlab-instance>/api/v4/mcp

Sign-in is where it matters, and this is the mistake many guides pass along: the officially documented route runs through OAuth 2.0 with dynamic client registration, not through a personal access token you create yourself. Anyone searching for "create a token with the api scope" is following a guide for GitLab's other interfaces, not this one.

On top come prerequisites that often go unmentioned: GitLab Duo has to be available, beta and experimental features have to be enabled, and MCP access has to be switched on. If you'd rather go through an intermediate layer, mcp-remote works as a proxy, which requires Node.js version 20 or newer. The direct HTTP route is the recommended one and does without that dependency.

Playwright: the assistant drives the browser

Playwright is the odd one out here, because it isn't a data store but a browser control tool. Microsoft publishes the official server for it; unlike Atlassian's, it isn't a hosted service but runs on your own machine. Connected up, an assistant can open pages, click, fill in forms and report back what it found.

The interesting part is less about automating tests and more about being able to send an assistant to go and look. "Open the page and tell me whether the form submits" used to be an instruction that needed a person. The server returns structured snapshots of the page rather than plain screenshots. That's the basis on which the assistant can click deliberately at all; it doesn't replace a real WCAG accessibility audit, even if the data format is reminiscent of one.

Which of these is worth it for a business

Honest placement: these four connections are developer tools. If nobody in your company works with Figma, Jira or GitLab, they do nothing for you.

What's interesting is the principle underneath. An MCP server isn't limited to developer software. The same bridge can be built to an inventory system, a booking system, a customer database. The difference is that the large vendors now ship their bridge ready-made, and a smaller piece of industry software generally doesn't.

That's exactly where our work starts: we build the connection to the systems that have none, so an assistant works with your real data instead of whatever someone pasted in. What that looks like is on the AI connector page, and if you want to know what sits behind the protocol itself, the piece on MCP explained covers it.

The short version

Figma has two routes, local and remote, and now recommends the remote one; what you can retrieve depends on your plan. Jira, Confluence and Bitbucket share a single Atlassian server, no official Jira-only server exists, and your sign-in method partly decides which functions you get. GitLab has had a server since 18.6 in beta, connected through OAuth and requiring an active GitLab Duo. Playwright comes from Microsoft, runs locally and drives the browser rather than serving data.

For all four the real effort isn't the setup anyway. It's what comes after: working out what you actually use the connection for day to day.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

Google Ads Do Not Start in the Ads Account

Matthias | StudioMeyer — Sun, 16 Aug 2026 05:34:07 +0000

The question I get asked sounds almost the same every time. Can we not simply run some ads. The honest answer to that is: technically right away, an account is set up in half an hour.

Except I look somewhere else first. Not at the ad, not at the keywords, not at the budget. At the page that comes after the click. Because that is where it is decided whether the money works or is merely spent. And that is where Google looks too, more thoroughly than most people assume.

Most People Think Ads Are Just an Auction

The idea is simple and widely held: whoever bids more gets shown more often. Whoever loses out has to raise the bid.

That is not how it works. Google calculates an ad rank, and the bid is only one component within it. Also in there: the quality of the ad, the quality of the landing page, the context of the search, ad rank thresholds and how competitive the particular auction is. So the page behind the click does not sit at the edge of the system, it is part of it.

Which means the reverse is true as well. A weak landing page cannot be offset indefinitely with higher bids. You can buy yourself additional traffic. That does not make the page any better in business terms, and that is precisely the difference between an auction you win and a month that paid off.

Google Has Its Own Requirements for the Destination, and They Are Public

Before an ad runs at all it gets reviewed, destination included. Google lists its destination requirements publicly, with its own name for every single case.

The ones that actually come up in an ordinary business are a manageable handful. A destination that does not work or was set up incorrectly. A destination that is not accessible in the region being advertised to. A destination that Google's review bot cannot crawl because a server configuration or a line in the robots.txt shuts it out. A displayed address whose domain does not match where the user actually lands. A page whose content mainly exists to serve ads. Navigation that is unnecessarily difficult or frustrating.

Two more are worth a special mention because they sit in the ad rather than on the page: a phone number Google has not verified, and a phone number that does not connect the caller to the advertised business. Both are policy violations, not merely cosmetic flaws.

What stands out about this list is what is not on it. Not one of these points has anything to do with the bid, and none of them is visible to somebody who only looks inside the ads account.

What happens on a violation is less dramatic than many expect. No invoice arrives and no penalty, the ad is disapproved and does not run. That is visible in the account, where it is listed as not servable. For destination violations Google additionally states that an account suspension does not arrive without a warning and a deadline first.

The tricky part is not the visibility, it is who does the looking. Somebody who sets up an account and then waits for the monthly report sees a campaign delivering very little and goes looking for the fault in the budget. The notice has been sitting in the account the whole time, just not where that person checks.

The Ad Makes a Promise and the Page Has to Keep It

The case most often underestimated is called destination mismatch. What is meant first is something technical: the domain in the displayed address has to match the address the user lands on, redirects must not push them onto a different domain, and a tracking template has to lead to the same content as the actual address. Google states the intent behind it plainly: ads should accurately reflect where a user is being taken.

The interesting part is the human version of the same rule, which needs no policy at all. Anyone clicking an ad has an expectation in their head, and it comes from exactly the line they clicked. If they then land on a page telling them something more general, that is not a rule violation, but it is the same breach. They clicked on a promise and got an overview.

At that moment the click is already paid for. What happens next is the actual difference between a campaign that adds up and one that merely runs.

Quality Score Is Not What Most People Think It Is

A lot of half knowledge gets passed around here, including by people who ought to know better professionally. The common version goes: a poor landing page lowers your Quality Score, and a poor Quality Score makes every click more expensive.

That is not supported. Quality Score consists of three parts according to Google, and landing page experience genuinely is one of them. About the number itself, though, Google writes that it is a diagnostic tool and is not used at auction time.

Holding both of those as true at once is the whole point. The number in the account is feedback, not a price tag. Landing page quality, meanwhile, is explicitly part of ad rank, which is where position and cost are decided. So the page counts. Just not through the metric everybody points at.

In practice that means: optimising the number is optimising a thermometer. Improving the page changes the temperature.

What Google Actually Assesses on a Landing Page

If the page is assessed, the next question is fair enough: assessed on what. Google describes landing page experience in its help pages with surprisingly concrete components. How useful and how relevant the information on the page is. How easily a user finds their way around it. How many links are on the page. And what expectation the visitor arrives with, formed by the ad they clicked.

On top of that come two things Google highlights specifically for mobile: that ease of navigation matters even more there than on a desktop, and that a faster landing page is among the most effective levers for mobile ads. And from the policy corner, the point about original content: a page whose content mainly exists to display ads counts as insufficient.

What is striking is how little of this sounds like marketing. Not one of these points is a trick. It is a description of what a person experiences after clicking something and wanting to know whether they are in the right place. Build the page for that person and you satisfy the assessment along the way.

One Page for Everything Gets More Expensive Under Ads, Not Cheaper

Plenty of businesses have a homepage carrying every service they offer, and send the paid traffic there. It feels economical, because there is only one page to maintain.

In reality it is the most expensive option. Every searcher arrives with exactly one question and meets a list in which their question is one item out of eight. They have to work out where to go next, and most of them do not. They go back. The click is paid for regardless.

There is also the fact that the effect degrades with every additional topic advertised. A page answering one question cleanly can be strong for that one topic. A page brushing past eight questions is mediocre at every one of them. Anyone serious about ads therefore needs a dedicated destination per advertised thing that deals with exactly that thing. This is not a trick, it is the basic condition.

Without Measurement You Are Buying Clicks, Not Customers

The last blind spot sits at the end of the chain. If there is no way to measure what became of a click, you are buying visits and afterwards only know how many there were.

It starts off mundane. A contact form that validates nothing accepts mistyped addresses and reports success anyway. The enquiry counts as sent, the reply reaches nobody, and the report shows a click that looks like a win.

Then there is the consent layer, which nobody in Europe gets around. Depending on how consent mode is implemented and how a visitor decides, measurement signals can be limited or missing entirely. Google can partly fill such gaps through modelling. Anyone who has wired the consent signals incorrectly is therefore optimising against a data set that does not fully reflect what visitors actually did. That is not a reason to skip advertising. It is a reason to set measurement up before the first campaign rather than after it.

Why I Advise Against It More Often Than For It

Ads are a good tool. They are fast, they are steerable, and within days they produce insights that would otherwise take months. The problem is never the tool, it is the order.

When somebody asks whether we should run ads, and the answer to the question being advertised does not yet exist on the site, I would spend this month's budget building a page that answers it, and advertise on that page next month. It is the less comfortable order, because nothing blinks in the first month. It is also the only one where the money is still there afterwards, in the form of something that keeps working without a budget.

An ad stops working the moment you stop paying. A page that answers a question does not.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.